請支持原文作者 : 鴻洋
本篇來自 **WizardDragon **的投稿，分享了他對于四大組件啟動時一些方法的調(diào)用順序的研究結(jié)果，并且深入源碼去分析遇到的問題。文章篇幅不短，希望能對大家有所幫助。
WizardDragon 的博客地址：
http://blog.csdn.net/long117long
背景
在做一個項目時，我們想在應(yīng)用最早啟動時，先做一些判斷，然后根據(jù)判斷的結(jié)果再決定要不要對其他應(yīng)用提供服務(wù)。
對其他應(yīng)用提供服務(wù)指的是，我們的應(yīng)用中有 ContentProvider，第三方應(yīng)用通過 call 方法調(diào)用到我們提供的 ContentProvider，ContentProvider 執(zhí)行邏輯后并給調(diào)用的返回結(jié)果。當?shù)谌綉?yīng)用調(diào)用我們的應(yīng)用時，我們的應(yīng)用存在啟動和未啟動的兩種情況。
剛開始，我們將判斷邏輯寫在了自定義的 Application 的 onCreate 方法中，但等到測試時發(fā)現(xiàn)了很多意想不到的情況，比如：
邏輯判斷之后的結(jié)果是不給第三方應(yīng)用提供“服務(wù)”，但有時候第三方應(yīng)用能夠使用服務(wù)，而有時候第三方應(yīng)用不能使等等的問題。
于是我們跟蹤代碼，發(fā)現(xiàn)了 四大組件 以及 Application 的各個方法( attachBaseContext、onCreate、call 等)啟動順序，跟我們之前理解的稍稍不一樣。
在弄清楚了 四大組件 和 Application 在應(yīng)用冷啟動時的執(zhí)行順序后，我們才把遇到的問題徹底解決。
驗證試驗
為了測試 四大組件 和 Application 的各種方法( attachBaseContext、onCreate、call 等)被系統(tǒng)調(diào)用的順序，我們創(chuàng)建一個簡單的應(yīng)用，只包含這5個組件，不考慮一個應(yīng)用多進程的情況，代碼分別為：
[圖片上傳中。。。（1）]
MainApplication.java
[圖片上傳中。。。（2）]
MainActivity.java
[圖片上傳中。。。（3）]
MainService.java
[圖片上傳中。。。（4）]
MainReceiver.java
[圖片上傳中。。。（5）]
MainProvider.java
[圖片上傳中。。。（6）]
在以下幾個場景測試時，均已冷啟動的方式啟動應(yīng)用。
冷啟動，指的是在系統(tǒng)沒有創(chuàng)建apk這個進程時啟動apk。
注意在測試的手機上，不要讓測試的應(yīng)用被禁止關(guān)聯(lián)啟動或自啟動：
場景一，點擊桌面的圖標啟動應(yīng)用，日志如下：
[圖片上傳中。。。（7）]
場景二，通過另外一個應(yīng)用以啟動Service的形式啟動應(yīng)用，其中啟動 MainService 的代碼如下：
[圖片上傳中。。。（8）]
日志如下：
[圖片上傳中。。。（9）]
場景三，應(yīng)用通過接受開機廣播啟動的方式啟動，日志如下：
[圖片上傳中。。。（10）]
場景四，其他應(yīng)用調(diào)用 ContentProvider 的 call 方法啟動，其中，調(diào)用 MainProvider 的 call 代碼如下：
[圖片上傳中。。。（11）]
日志如下：
[圖片上傳中。。。（12）]
結(jié)論：
從上面四個場景可以看出：
**1. **Application 的 attachBaseContext 方法是優(yōu)先執(zhí)行的；
**2. **ContentProvider 的 onCreate 的方法比 Application 的 onCreate 的方法先執(zhí)行；
**3. **Activity、Service的 onCreate 方法以及 BroadcastReceiver 的 onReceive 方法，是在 MainApplication 的 onCreate 方法之后執(zhí)行的；
4. 調(diào)用流程為： Application 的 attachBaseContext ---> ContentProvider 的 onCreate ----> Application 的 onCreate ---> Activity、Service 等的 onCreate（Activity 和 Service 不分先后）；
問題
問題一：****ContentProvider 的 onCreate 一定是優(yōu)先于 Application 的 onCreate 執(zhí)行的嗎？
為了驗證這個問題，MainApplication 的代碼不變，我們將 MainProvider 的 onCreate 的代碼改為：
[圖片上傳中。。。（13）]
我們再在上面第四種場景上進行驗證，日志如下：
[圖片上傳中。。。（14）]
問題一結(jié)論：
確實是在 ContentProvider 的 onCreate 執(zhí)行完成之后，才會執(zhí)行 Application 的 onCreate 的。
問題二：****ContentProvider中 的 call方法 是在 Application 的 onCreate 執(zhí)行完之后才執(zhí)行的嗎？
為了驗證這個問題，我們將 MainProvider 和 MainApplication 的代碼改為：
[圖片上傳中。。。（15）]
[圖片上傳中。。。（16）]
我們還在第四個場景下驗證，日志如下：
[圖片上傳中。。。（17）]
從日志中可以發(fā)現(xiàn)，Application 的 onCreate 執(zhí)行時，ContentProvider 的 call方法 也在同時執(zhí)行。
問題二結(jié)論：
Application 的 onCreate方法 和 Provider 的 call方法** 不是順序執(zhí)行，而是會同時執(zhí)行**。
問題三：****有比 Application 的 attachBaseContext方法 更早執(zhí)行的方法嗎？
有，比如：Application所在類的構(gòu)造方法。為了驗證這個問題，將代碼改為：
[圖片上傳中。。。（18）]
程序啟動后，日志為：
[圖片上傳中。。。（19）]
問題三結(jié)論：
Application 的構(gòu)造方法早于 Application 的 attachBaseContext方法 調(diào)用。
那么有沒有比 Application 的構(gòu)造方法還早被調(diào)用的方法呢？有，自己可以再想想哦。
遇到的坑
好了，我們知道 attachBaseContext 的方法在“一般情況下是最早執(zhí)行的“，那么在項目中為了能”盡早“的提前初始化某些模塊、功能或者參數(shù)，那么我們會把代碼從 Application 的onCreate方法 提前到 attachBaseContext方法 中。嗯，一切感覺起來那么美好，直到你運行程序崩潰時...
好吧好吧，那些“坑”終于還是來了。
“坑”一：在 Application 的 attachBaseContext方法 中，使用了 getApplicationContext方法。
當我發(fā)現(xiàn)在 attachBaseContext方法 中使用 getApplicationContext方法 返回null時，內(nèi)心是崩潰。
所以，如果在 attachBaseContext方法 中要使用 context 的話，那么使用 **this **吧，別再使用 getApplicationContext() 方法了。下文有分析為什么。
“坑”二：這個其實不算很坑，也不會引起崩潰，但需要注意：
在 Application 的 attachBaseContext方法 中，去調(diào)用自身的 ContentProvider，那么這個 ContentProvider 會被初始化兩次，也就是說這個 ContentProvider 會被兩次調(diào)用到onCreate。如果你在 ContentProvider 的 onCreate 中有一些邏輯，那么一定要檢查是否會有影響。
做一下驗證，在 Application 中調(diào)用 Provider 的 call方法，并在 MainActivity 中的 onCreate方法 中調(diào)用 Provider 的 call方法，Application 的代碼，Provider 的代碼，Activity 的代碼分別如下：
[圖片上傳中。。。（20）]
啟動應(yīng)用后，日志如下：
[圖片上傳中。。。（21）]
可以看到，MainProvider 的 onCreate 的方法被調(diào)用了兩次（因為 MainProvider 的兩次 onCreate 打印出的自身對象不一樣），而在 MainActivity 中調(diào)用到 call方法 執(zhí)行的類，跟 MainApplication 在 attachBaseContext方法 執(zhí)行的類是同一個。
源碼分析
好了，現(xiàn)象、問題和“坑”都經(jīng)歷了一遍，那么 為什么 會是這樣呢？
我們通過看源碼，來跟蹤：
1. Application 的 attachBaseContext、ContentProvider 的 onCreate 以及 Application 的 onCreate 在源碼中的調(diào)用順序。
2. 為什么在 Application 的 attachBaseContext 中調(diào)用 getApplicationContext 得到的是null。
先看第一個問題，我們知道Java進程的入口方法一般都是在main中，而Android為了讓應(yīng)用開發(fā)者不需要關(guān)心應(yīng)用的創(chuàng)建，已經(jīng)幫我們進行封裝，其實應(yīng)用 main方法 是在 ActivityThread.java 中的。
我們查看 ActivityThread.java 的源碼，本文以下的源碼都以 6.0.1_r10 基礎(chǔ)。
a. ActivityThread.java 的 main方法：
[圖片上傳中。。。（22）]
b. ActivityThread.java 的 attach方法：
[圖片上傳中。。。（23）]
c. ActivityThread.java 的 handleBindApplication(AppBindData data)方法：
[圖片上傳中。。。（24）]
d. LoaderApk.java 的 makeApplication方法
[圖片上傳中。。。（25）]
e. Instrumentation.java的相關(guān)方法
[圖片上傳中。。。（26）]
f. Application.java 的 attach方法
[圖片上傳中。。。（27）]
g. ActivityThread.java 的 handleBindApplication方法：
[圖片上傳中。。。（28）]
h. 繼續(xù)跟蹤 installContentProviders 這個方法，而這個方法是會調(diào)用到 installProvider方法 中的，還是在 ActivityThread.java 中：
[圖片上傳中。。。（29）]
i. 看 ContentProvider.java 中的 attachInfo方法(frameworks/base/core/java/android/content/ContentProvider.java)
[圖片上傳中。。。（30）]
j. 關(guān)于 注釋7 的 mInstrumentation.callApplicationOnCreate(app) 調(diào)用到的 Instrumentation.java 中的方法
[圖片上傳中。。。（31）]
看第二問題，為什么在我們自定義 Application 中的 attachBaseContext方法 中，調(diào)用 getApplicationContext() 為 null 呢？
1. 跟蹤 getApplicationContext() 發(fā)現(xiàn)是在 ContextWrapper.java 中實現(xiàn)的：
[圖片上傳中。。。（32）]
2. 我們看 ContextImpl 的 getApplicationContext方法：
[圖片上傳中。。。（33）]
3. mPackageInfo 是什么時候賦值的呢？我們從 ContextImpl 實例化的地方入手，在注釋 5.1 之前的一行代碼看到了 ContextImpl 的實例化代碼，跟進代碼發(fā)現(xiàn)，果不其然，看到了 mPackageInfo 被賦值的地方：
[圖片上傳中。。。（34）]
4. 注釋b.1所在的流程 早于 注釋5.4 的（在注釋5.4時才調(diào)用到了Application的attachBaseContext方法），在我們自定義的Application中attachBaseContext調(diào)用getApplicationContext方法時，就到了注釋b，而此時mPackageInfo是不為空的，所以會執(zhí)行mPackageInfo.getApplication()，那么我們再看一下LoadedApk.java中的getApplication方法（正如前面所說，mPackageInfo是LoadedApk的實例），
[圖片上傳中。。。（35）]
[圖片上傳中。。。（36）]
看到這里找到原因所在了：
因為我們在 Application 的 attachBaseContext方法 中調(diào)用 getApplicationContext() 時， mApplication 還沒有被賦值，所以返回的是空，只有把 attachBaseContext方法 執(zhí)行完成后，mApplication 才會被賦值。
附圖一張：
[圖片上傳中。。。（37）]
參考
