本篇博文主要講解Android的系統架構。

對於Android開發者來說，有必要了解一下Android應用程式是如何執行的。

Android是一個移動作業系統，它大致分為四層，即Linux核心層，庫和執行時，Framework層和應用層。Android的體系架構鼓勵系統元件重用，共享元件資料，並且定義元件的訪問控制權限。可以說，這些層次結構即是相互獨立，又是相互關聯的。

一  Android系統架構

1.Linux層

Linux層，Android最底層的最核心的部分。每一個Android的應用程式都是執行在Dalvik虛擬機器中。每個App都會分配Dalvik虛擬機器來保證互相之間不受干擾。並保持獨立。它的特點是執行時編譯。而在Android 5.X版本開發，ART模式已經取代了Dalvik，ART採用的是安裝時就進行編譯，以後執行時就不用編譯了。當然，對在其虛擬機器內執行的大部分App來說，他們都執行著同樣的程式碼。

2.Framework

Framework層包含編寫Android應用程式所需要的各種框架類。比如 Activity Managet,window Manager,Content Providers,View System等等。

  3.標準庫

標準庫就是開發者在開源環境中可以使用的開發庫。

  4.Application

Android SDK App 包含 Android manifest,Dalvik classes,Resource bundle.Android NDK App 除了包含和Android SDK App同樣的內容外，還包含Libraries與JNI.

二  Android

元件架構

上面我們講了Android系統架構，而在應用層，Android的App元件架構，通常就是我們所說的Android四大元件。指的是Activity,BroadcastReiver,ContentProvider和Service,他們是組成Android App的最基本元素。

四大元件中，除了BroadcastReiver以外，其他三種元件都必須在Android manifest中註冊，對於BroadcastReiver既可以在manifest檔案中註冊，也可以通過程式碼來實現。在呼叫方式上，Activity,Service和阿里需要借用Intent,而ContentProvider則無需藉助Intent。

Activity 是一種 展示型組建，用於向用戶直接地展示一個介面，並且可以接受使用者的輸入資訊從而進行互動。Activity是最重要的一種元件，對於使用者來說，Activity就是一個Android應用的全部，這是因為其他三大元件對使用者來說都是不可感知的。Activity的啟動由Intent觸發，其中Intent可以分為顯示Intent和隱式Intent.顯示Intent可以明確地指向一個Activity元件，隱BroadcastReiverIntent則指向一個或多個目標Activity元件。當然，也可能沒有任何一個Activity元件可以處理這個隱BroadcastReiver的Intent。一個Activity元件可以具有特定的啟動模式。關於Activity的啟動模式與生命週期，我會在下一篇博文裡講述。同一個Activity元件在不同的啟動模式下會有不同的效果。Activity元件可以停止，在實際開發中通過Activity的finish方法來結束一個Activity的執行。由此看來，Activity元件的主要作用是展示一個介面並和使用者互動，塔扮演的是一種前臺介面的角色。

Service 是一種計算型元件，使用者在後臺執行一系列的計算任務。由於Service元件工作在後臺，因此使用者無法直接感受它的存在。Service 元件和Activity 元件略有不同，Activity元件只有一種執行模式，即Activity處於啟動模式，但是 Service元件卻有兩種狀態:啟動狀態與繫結狀態。當 Service元件處於啟動狀態，這個時候，Service內部可以做一些後臺計算，並且不需要和外界直接互動。儘管Service元件使用執行後臺計算的，但是它本身是執行在主執行緒中的，因此耗時的後臺計算仍然需要在單獨的執行緒中去完成。當Service元件處於繫結狀態時，這個時候，Service內部同樣可以進行後臺計算，但是處於這種狀態時，外界可以很方便地和Service元件進行通訊。Service元件也是可以停止的，停止一個Service稍微複雜，需要靈活採用stopService 和 unBindService這兩個方法才能完全停止一個Service元件。

BroadcastReiver 是一種訊息型元件，用於在不同的元件乃至不同的應用之間進行訊息傳遞，BroadcastReiver 同樣無法被使用者感知，因為它工作在系統內部。BroadcastReiver也叫廣播，廣播註冊有兩種方式: 靜態註冊和動態註冊。靜態註冊是指在AndroidManifest中註冊廣播，這種廣播在應用安裝時會被系統解析，此種形式的廣播不修要應用啟動就可以接收到廣播。動態註冊廣播需要通過Context.registerReceiver() 來實現，並且不需要的時候，要通過Context.unRegisterReceiver來解除廣播。此種形態的廣播必須要應用啟動才能住岑並接收廣播，因為應用不啟動就無法註冊廣播，無法註冊廣告，就無法接收到相應的廣播。在實際開發中通過Context的一系列send 方法來發送廣播，被髮送的廣播就會被系統傳送給感興趣的廣播接收者。傳送和接收過程的匹配時通過廣播接收者的<intent-filter>來描述的。可以發現，BroadcastReceiver 元件可以用來實現低耦合的觀察者模式，觀察者和被觀察者之間可以沒有任何耦合。由於BroadcastReceiver的特性，它不適合用來執行耗時的操作。BroadcastReceiver 元件一般來說，不需要停止，它也沒有停止的概念。

ContentProvider 是一種資料共享型元件，用於向其他元件乃至其他App共享資料。和BroadcastReceiver一樣，ContentProvider同樣無法被使用者感知。對於一個ContentProvider元件來說，她的內部需要實習增刪改查四種操作,在它的內部，維持著一份資料集合，這個資料集合既可以通過資料庫來實現，也可以通過採用任何其他型別實現，比如List和Map.ContentProvider 對資料集合的具體實現並沒有任何要求。需要注意的是，ContentProvider的內部insert,delete,update和query方法需要做好執行緒同步處理，因為這幾個方法是線上程池中呼叫的，另外ContentProvider元件也不需要手動停止。

今天講的主要都是理論，比較枯燥，但也讓我們從整體上認識了Android的系統結構。接下來的四篇博文，我會從每個元件的應用以及底層實現原理進行講解。第一次寫博文，肯定有缺憾，望海涵。