在本篇中，主要介紹Android平臺應用程式的執行原理，在閱讀了SDK文件中“Application Fundamentals”一篇的內容後，根據自己的理解繪製了下面的示意圖：

      每個應用程式安裝後，系統便會為其分配一個獨立的儲存空間，所謂的“Security Sandbox”，用於存放位元組碼檔案、資原始檔及配置檔案等，同時，系統會為每一個應用程式分配唯一的ID，用以標識該應用程式的相關檔案和資源，系統通過設定許可權從而實現一個應用程式在一般情況下只能訪問該應用程式的檔案和資源。當應用程式或者它的某個元件需要執行時，系統便為其建立一個Linux程序，每個程序中例項化一個Dalvik虛擬機器用以執行程式的位元組碼。程式執行中根據給自己設定的許可權來訪問相應的資源。這樣的設計保證了應用程式間的獨立性和安全性，但是，應用程式常常要訪問其他應用程式的資料或者訪問系統資源，為此，Android平臺提供了兩種方式來實現這一目的：
（1）可以安排兩個應用程式共享一個ID，從而可以彼此訪問對方的檔案；還可以安排兩個應用程式在一個程序中執行，並共享一個虛擬機器
（2）應用程式在安裝時，可以通過使用者來設定許可權，根據設定的許可權應用程式可以發起訪問系統資源和資料的請求。

---------------------------------------------------------------------------------------------------------------------------------------------------

瞭解應用程式執行原理的目的是為了構建應用程式，因此瞭解上述內容是遠遠不夠的，如果把上述內容理解成物理結構，那麼下面所講的便是以構成應用程式的基本元件為主的邏輯結構。

Android應用程式主要由四種不同型別的元件組成，分別是Activity（活動）、Service（服務）、Content Provider（內容提供者）和Broadcast Receiver（廣播接收者）：

◆Activity是一個顯示在裝置螢幕上的使用者介面元件，有點兒類似檢視（View）。一個應用程式可以包含多個Activity來呈現其不同的功能介面。在某一個程式允許的前提下，另一個程式可以啟動該程式中的一個Activity來完成相應的功能。

◆Service是一個在後臺執行的，沒有使用者介面，用以執行執行週期較長的操作或者執行遠端程序的任務的元件。Activity可以啟動一個Service並與其繫結用以實現二者之間的互動。

◆Content Provider是一個用於資料共享的元件。無論應用程式是以何種資料持久化形式儲存的資料，通過Content Provider元件，其他應用程式可以訪問或修改該應用程式的資料。

◆Broadcast Receiver是一個相應系統範圍內的廣播訊息的元件。廣播以Intent物件的形式傳送，Broadcast Receiver接收後根據其內容作出相應操作。

Android系統這樣設計的目的就是凸顯元件的複用性，當一個程式需要使用另一個程式的元件時，首先需要向系統傳送一個Intent來表明你的意圖，系統根據許可權設定，在允許的條件下，將元件所在的應用程式的程序啟動，元件對應的類被例項化，元件執行完需要的功能後，將結果返回到呼叫該元件的應用程式，所以，Android應用程式與其他系統的應用程式不同，即沒有單一的入口（例如Main函式）。對於元件啟用的方式，不同的元件有不同的方式。其中，Activity、Service和Broadcast Receiver是被所謂“Intent”的非同步訊息啟用的，Intent將獨立的元件進行繫結；Content Provider是被來自Content Resolver的請求啟用的。

      根據上述內容，結合自己的理解，將Android應用程式建立和執行的過程用下圖描繪：