系統對四大元件的過程進行了很大程度的封裝，日常開發中並不需要了解底層的工作原理，那麼研究這些原理的意義在哪裡呢？

如果你想在技術上更進一步，那麼瞭解一些系統的工作原理是十分必要的，也是開發人員日後成長為高階工程師所必備的技術能力。
Android作為一個優秀的基於Linux作業系統，其內部一定有很多值得我們學習的地方，通過對Android作業系統的學習對提高開發人員的內功有很大的好處。
如果你從事Android Rom開發，那就沒什麼好說的了，看原始碼吧。
本文側重於對四大元件工作過程的分析，通過分析他們的工作過程理解系統內部執行機制，加深我們對Android整體系統結構的認識。

本文中的UML圖來自@amurocrash，感謝amurocrash。
Android相關部分的原始碼實在是太多，全部貼上了太過繁瑣，所以借用了amurocrash同學的UML圖使得整個流程更加容易理解。

四大元件的執行狀態
Activity的主要作用是展示一個介面並和使用者互動，它扮演的是一種前臺介面的角色。
Service是一種計算型元件，用於在後臺執行一系列計算任務。Service有兩種狀態：啟動狀態和繫結狀態。啟動狀態時的Service不需要與外界互動，繫結狀態的Service可以方便的和Service元件進行通訊。Service是執行在主執行緒中的，因此耗時的後臺計算仍然需要在單獨的執行緒中去完成。靈活採用stopService和unBindService這兩個方法才能完全停止一個Service元件。
BroadcastReceiver是一種訊息型元件，用於在不同的元件乃至不同的應用之間傳遞訊息。廣播註冊有靜態和動態兩種方式，動態註冊通過Context.registerReceiver()來實現，不需要時通過Contex.unRegisterReceiver()來解除廣播，這種方式必須要應用啟動才能註冊；靜態註冊則在AndroidManifest檔案中進行，應用安裝時會被系統解析，不需要啟動應用就可接收廣播。匹配過程是通過來描述的。
ContentProvider是一種共享型元件，用於向其他元件乃至其他應用共享資料。它內部維持著一份資料集合，並需要實現增刪改查這四種操作，這個資料集合既可以通過資料庫來實現，也可以採用其他型別來實現，比如List，Map等。需要注意的是，增刪改查要處理好執行緒同步，這幾個方法是在Binder執行緒池中被呼叫的，另外，ContentProvider不需要手動停止。
Activity的工作過程
UML圖

注

啟動Activity的真實實現是由ActivityManagerNative.getDefault().startActivity方法來完成的。這個方法返回ActivityManagerService。
ActivityManagerService（AMS）繼承自ActivityManagerNative，而ActivityManagerNative繼承自Binder並實現了IActivityManager這個Binder介面，因此AMS也是一個Binder。
AMS這個Binder物件採用單例模式對外提供，第一次呼叫它的get方法時會通過create方法初始化，後續呼叫中直接返回之前建立的物件。
從makeApplication的實現可以看出，如果Application已經被建立過了，那麼就不會再重複建立，這也意味著一個應用只有一個Application物件。Application的建立也是通過Instrumentation來完成的，這個過程和Activity物件的建立過程一樣，都是通過類載入器來實現的。
ContextImpl是Context的具體實現，ContextImpl是通過Activity的attach方法來和Activity建立關聯的，在attach方法中Activity還會完成Window的建立並建立自己和Window的關聯，這樣當Activity接受到事件就可以傳遞給window了。
Service的工作過程
啟動過程

繫結過程

注

Service有兩種狀態：啟動狀態和繫結狀態，兩種狀態是可以共存的。
BroadcastReceiver的工作過程

BroadcastReceiver的工作過程包括廣播註冊過程、廣播發送和接收過程。

動態註冊

傳送和接收

注：

靜態註冊是由PackageManagerService（PMS）在應用安裝的時候完成整個註冊過程的，除廣播以外，其他三大元件也都是在應用安裝時由PMS解析並註冊的。
廣播的傳送有幾種型別：普通廣播、有序廣播和粘性廣播，有序廣播和粘性廣播與普通廣播相比具有不同的特性，但是傳送和接收過程是類似的。
FLAG_INCLUDE_STOPPED_PACKAGES:廣播會發送給已經停止的應用，FLAG_EXCLUDE_STOPPED_PACKAGES廣播不會發送給已經停止的應用
從Android 3.1開始，處於停止狀態的應用無法接受到開機廣播。

ContentProvider
啟動過程

啟動過程

當ContentProvider所在的程序啟動時，會同時被啟動並被髮布到AMS中，需要注意的是，這個時候它的onCreate要先去Application的onCreate執行，這在四大元件中是一個少有的現象。
用啟動的入口為ActivityThread的main方法，main方法會建立ActivityThread例項並建立主執行緒訊息佇列。
attach方法中遠端呼叫AMS的attachApplication方法，並提供ApplicationThread用於和AMS的通訊。
attachApplication方法會通過bindApplication方法和H來調回ActivityThread的handleBindApplication，這個方法會先建立Application，再載入ContentProvider，然後才會回撥Application的onCreate方法。
ContentProvider的multiprocess屬性決定了ContentProvider是否是單例（false時），一般都用單例。
ontentResolver的具體類是ApplicationContentResolver，當ContentProvider所在程序未啟動時，第一次訪問它會觸發ContentProvider的建立以及程序啟動。
Query流程

query

insert，delete和update方法類似，這裡就不在分析了。

本文標題:從原始碼的角度理解四大元件的工作過程
文章作者:Spark Yuan
釋出時間:2016年03月14日 - 22時35分
最後更新:2016年03月15日 - 10時19分
原始連結:http://sparkyuan.github.io/2016/03/14/四大元件的工作過程/
許可協議: “署名-非商用-相同方式共享 3.0” 轉載請保留原文連結及作者。