（七）App啟動流程第2篇

書接上文，App啟動一共有七個階段，上篇文章篇幅所限，我們只看了第一階段，接下來講剩余的六個階段，仍然是拿斗魚App舉例子。

簡單回顧一下第一階段的流程，就是Launcher向AMS發送一個跨進程通信，通過AMN/AMP，告訴AMS，我要啟動斗魚App。

畫一個圖，描述一下啟動App所經歷的7個階段：

第2階段 AMS處理Launcher傳過來的信息

這個階段主要是Binder的Server端在做事情。因為我們是沒有機會修改Binder的Server端邏輯的，所以這個階段看起來非常枯燥，我盡量說的簡單些。

1. 首先Binder，也就是AMN/AMP，和AMS通信，肯定每次是做不同的事情，就比如說這次Launcher要啟動斗魚App，那么會發送類型為START_ACTIVITY——TRANSACTION的請求給AMS，同時會告訴AMS要啟動哪個Activity。
?2. AMS說，好，我知道了，然后它會干一件很有趣的事情，就是檢查斗魚App中的Manifest文件，是否存在要啟動的Activity。如果不存在，就拋出Activity not found的錯誤，各位做App的同學對這個異常應該再熟悉不過了，經常寫了個Activity而忘記在Manifest中聲明了，就報這個錯，就是因為AMS在這里做檢查。不管是新啟動一個App的首頁，還是在App內部跳轉到另一個Activity，都會做這個檢查。
?3. 但是Launcher還活著啊，所以接下來AMS會通知Launcher，哥們兒沒你什么事了，你"停薪留職"吧。那么AMS是通過什么途徑告訴Launcher的呢？

前面講過，Binder的雙方進行通信是平等的，誰發消息，誰就是Client，接收的一方就是Server。Client這邊會調用Server的代理對象。

對于從Launcher發來的消息，通過AMS的代理對象AMP，發送給AMS。

那么當AMS想給Launcher發消息，又該怎么辦呢？前面不是把Launcher以及它所在的進程給傳過來了嗎？它在AMS這邊保存為一個ActivityRecord對象，這個對象里面有一個ApplicationThreadProxy，單單從名字看就出賣了它，這就是一個Binder代理對象。它的Binder真身，也就是ApplicationThread。

站在AIDL的角度，來畫這張圖，是這樣的：

所以結論是，AMS通過ApplicationThreadProxy發送消息，而App端則是通過ApplicationThread來接收這個消息。

第3階段 Launcher去休眠，然后通知AMS，我真的已經"停薪留職"了，沒有吃空餉

ApplicationThread（簡稱APT），它和ApplicationThreadProxy（簡稱ATP）的關系，我們在第三階段已經介紹過了。

APT接收到來自AMS的消息后，就調用ActivityThread的sendMessage方法，向Launcher的主線程消息隊列發送一個PAUSE_ACTIVITY消息。

前面說過，ActivityThread就是主線程（UI線程）

看到下面的代碼是不是很親切？

發送消息是通過一個名為H的Handler類的完成的，這個H類的名字真特么有個性，想記不住都難。

做App的同學都知道，繼承自Handler類的子類，就要實現handleMessage方法，這里是一個switch…case語句，處理各種各樣的消息，PAUSE_ACTIVITY消息只是其中一種，由此也能預見到，AMS給Activity發送的所有消息，以及給其它三大組件發送的所有消息，都從H這里經過，為什么要強調這一點呢，既然四大組件都走這條路，那么這里就可以做點手腳，從而做插件化技術，這個我們以后介紹插件化技術的時候會講到。

H對于PAUSE_ACTIVITY消息的處理，如上面的代碼，是調用ActivityThread的handlePauseActivity方法。這個方法干兩件事：

• ActivityThread里面有一個mActivities集合，保存當前App也就是Launcher中所有打開的Activity，把它找出來，讓它休眠。
• 通過AMP通知AMS，我真的休眠了。

你可能會找不到H和APT這兩個類文件，那是因為它們都是ActivityThread的內嵌類。

至此，Launcher的工作完成了。你可以看到在這個過程中，各個類都起到了什么作用。蕓蕓眾生，粉墨登場：

• APT
• ActivityThread
• H

第4階段 AMS啟動新的進程

接下來又輪到AMS做事了，你們會發現我不太喜歡講解AMS的流程，甚至都不畫UML圖，因為這部分邏輯和App開發人員關系不是很大，我盡量說的簡單一些，把流程說清楚就好。

AMS接下來要啟動斗魚App的首頁，因為斗魚App不在后臺進程中，所以要啟動一個新的進程。這里調用的是Process.start方法，并且指定了ActivityThread的main函數為入口函數。

第5階段 新的進程啟動，以ActivityThread的main函數作為入口

啟動新進程，其實就是啟動一個新的App。

在啟動新進程的時候，為這個進程創建ActivityThread對象，這就是我們耳熟能詳的主線程（UI線程）。

創建好UI線程后，立刻進入ActivityThread的main函數，接下來要做2件具有重大意義的事情：

1）創建一個主線程Looper，也就是MainLooper。看見沒，MainLooper就是在這里創建的。

2）創建Application。記住，Application是在這里生成的。

- - - - - - - - - - - - - -華麗的分割線 開始- - - - - - - - - - - - - - -

App開發人員對Application非常熟悉，因為我們可以在其中寫代碼，進行一些全局的控制，所以我們通常認為Application是掌控全局的，其實Application的地位在App中并沒有那么重要，它就是一個Context上下文，僅此而已。

App中的靈魂是ActivityThread，也就是主線程，只是這個類對于App開發人員是訪問不到的——使用反射倒是可以修改這個類的一些行為。

- - - - - - - - - - - - - - -華麗的分割線 結束- - - - - - - - - - - - - - -

創建新App的最后，就是告訴AMS，我啟動好了，同時把自己的ActivityThread對象發送給AMS，從此以后，AMS的電話簿中就多了這個新的App的登記信息，AMS以后向這個App發送消息，就通過這個ActivityThread對象。

第6階段 AMS告訴新App啟動哪個Activity

AMS把傳入的ActivityThread對象，轉為一個ApplicationThread對象，用于以后和這個App跨進程通信。還記得APT和ATP的關系嗎？這就又回到第2階段的那張關系圖了。

還記得第1階段，Launcher發送給AMS要啟動斗魚App的哪個Activity嗎？這個信息被AMS存下來了。

那么在第6階段，AMS從過去的記錄中翻出來要啟動哪個Activity，然后通過ATP告訴App。

第7階段 啟動斗魚首頁Activity

畢其功于一役，盡在第7階段。這是最后一步。

App，這個Binder的另一端，通過APT接收到AMS的消息，仍然是在H的handleMessage方法的switch語句中處理，只不過，這次消息的類型是LAUNCH_ACTIVITY：

ActivityClientRecord是什么？這是AMS傳遞過來的要啟動的Activity。

還是這里，我們仔細看那個getPackageInfoNoCheck方法，這個方法會提取Apk中的所有資源，然后設置給r的packageInfo屬性。這個屬性的類型很有名，叫做LoadedApk。各位記住這里，這個地方可以干壞事，也是插件化技術滲入的一個點。

在H的這個分支中，又反過來回調ActivityThread的handleLaunchActivity方法，你要是覺得很繞那就對了。其實我一直覺得，ActivityThread和H合并成一個類也沒問題。

重新看一下這個過程，每次都是APT執行ActivityThread的sendMessage方法，在這個方法中，把消息拼裝一下，然后扔個H的swicth語句去分析，來決定要執行ActivityThread的那個方法。每次都是這樣，習慣就好了。

handleLaunchActivity方法都做哪些事呢？

1）通過Instrumentation的newActivity方法，創建出來要啟動的Activity實例。

2）為這個Activity創建一個上下文Context對象，并與Activity進行關聯。

3）通過Instrumentation的callActivityOnCreate方法，執行Activity的onCreate方法，從而啟動Activity。看到這里是不是很熟悉很親切？

至此，App啟動完畢。這個流程是經過了很多次握手， App和ASM，頻繁的向對方發送消息，而發送消息的機制，是建立在Binder的基礎之上的。

下一篇文章，我們講Context家族。