請支持原文作者 : 鴻洋
本篇來自 **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）]
參考
