Application,Activity,Service的建立流程（1）

Context的中文意思是上下文，可以簡單的理解為執行環境，提供一些非常Base的介面，例如獲取資源管理器，App快取目錄等

從Context原始碼中得出Context是個抽象類，其功能的實現應該交給了其子類，那麼我們就看看Context的繼承關係

此圖源自自郭霖大神的Blog

從原始碼可以看出，Context有兩個直接的子類ContextWrapper和ContextImpl，並且Application,Service,Activity都繼承ContextWrapper，下面我們看看ContextWrapper的原始碼:

從原始碼可以看出，ContextWrapper把功能都委託給mBase來做（代理模式）

讓我們再來Context的另外一個實現類ContextImpl的原始碼：

從原始碼可以看出，ContextImpl實現了Context的所有功能。綜上我們可以推斷ContextWrapper中的mBase應該是ContextImpl物件，下面通過Application，Activity，Service的建立流程來證實這個推斷。

這張圖主要展示了啟動Activity，Service的簡要過程，在啟動Activity，Service的同時也會建立Application

a. ActivityThread就是我們常說的UI執行緒，它負責Activity，Service，Application的排程等工作，感興趣的朋友可以閱讀下他的原始碼.

b. ApplicationThread是ActivityThread的一個內部類，本質上是一個IBinder物件，他的主要作用是用於AMS(ActivityManagerService的簡稱)與ActivityThread通訊，例如AMS在處理完Server端ActivityRecord的建立，棧管理後通過ApplicationThread來通知ActivityThread可以建立對應的Activity和執行Activity的生命週期了。

下面我們從AMS回撥啟動Activity的流程來看下Application的建立流程

1. AMS會通過呼叫ApplicationThread的scheduleLaunchActivity(...)來告訴ActivityThread它可以建立Activity了

   

2. 然後傳送LAUNCH_ACTIVITY訊息出去

   

3. 接著呼叫 handleLaunchActivity(...)

   

4. 然後呼叫performLauncherActivity(...)

   

   我們關注下createBaseContextForActivity(...)，他建立了CotnextImpl物件，接著呼叫Activity的attach(...)，把ContextImpl物件傳了進去，從而證明了Activity內部對應的mBase就是ContextImpl。

5. 然後呼叫了LoadedApk的makeApplication（...）

   

   如果mApplication不為null則直接返回它，mApplication是LoadedApk中的一個全域性物件，一個APP程序只會建立一次。然後建立ContextImpl物件，並且在呼叫Intrumentation的newApplication(...)的時候傳了進去，接著呼叫了Intrmentation的callApplicationOnCreate(...)

   接下來我們看看Intrumentation的newApplication(...)和callApplicationOnCreate(...)做了什麼

   
   從程式碼中我們可以看出，Application建立後，呼叫了attach(...)，把ContextImpl物件傳了進去，也就證明了Application內部對應的mBase就是ContextImpl，同時在attach方法中呼叫了執行了Application的生命週期方法attachBaseContext(...)
   
   

   從程式碼中可以看出，callApplicationOnCreate執行了Application生命週期方法onCreate(...)