（五）AMS

如果站在四大元件的角度來看，AMS就是Binder中的Server。

      AMS全稱是ActivityManagerService，看字面意思是管理Activity的，但其實四大元件都歸它管。估計是Android底層開發人員先寫了ActivityManagerService用來管理Activity，後來寫Service、Receiver、CP的時候發現程式碼都差不多，於是就全都用ActivityManagerService，但是卻忘記改名字了——我也是猜的，純屬八卦。

由此而說到了外掛化，我記得16年和Lody、張勇、林光亮一起吃夜宵的時候，我當時問了困惑已久的兩個問題：

1）App的安裝過程，為什麼不把apk解壓縮到本地，這樣讀取圖片就不用每次從apk包中讀取了——這個問題，我們放到PMS那一節再詳細說。

2）為什麼Hook永遠是在Binder Client端，也就是四大元件這邊，而不是在AMS那一側進行Hook。

這裡要說清楚第二個問題。就拿Android剪下板舉例吧。前面說過，這也是個Binder服務。

      AMS要負責和所有App的四大元件進行通訊，也真夠他忙的。如果在一個App中，在AMS層面把剪下板功能給篡改了，那會導致Android系統所有的剪下板功能被篡改——這就是病毒了，如果是這樣的話，Android系統早就死翹翹了。所以Android系統不允許我們這麼做。

      我們只能在AMS的另一側，Client端，也就是四大元件這邊做篡改，這樣即使我們把剪下板功能篡改了，也隻影響篡改程式碼所在的App，在別的App中，剪下板功能還是正常的。

關於AMS我們就說這麼多，下面介紹四大元件時，會反覆提到四大元件和AMS的跨程序通訊。

（六）Activity 第1講

      對於做App的開發人員而言，Activity是四大元件中用的最多的，也是最複雜的，我這裡只講Activity的啟動和通訊原理。還有一些相關的概念，比如說View、Looper、Intent、Resource，我以後另起章節來介紹。

      注：我對四大元件的分析，都是基於羅昇陽的那本分析Android底層的書，我把其中羅列的大部分程式碼都刪掉了，只保留那些對App開發人員有用的一些程式碼片段和一些關鍵類名，並融入了我對四大元件的理解。

1）首先要搞清，App是怎麼啟動的。

      在手機螢幕上點選某個App的Icon，假設就是鬥魚App吧，這個App的首頁（或引導頁）就出現在我們面前了。這個看似簡單的操作，背後經歷了Activity和AMS的反反覆覆的通訊過程。

      首先要搞清楚，在手機螢幕上點選App的icon快捷圖示，此時手機螢幕就是一個Activity，而這個Activity所在的App，業界稱之為Launcher。Launcher是手機系統廠商提供的，類似小米華為這樣的手機，比拼的就是誰的Launcher絢麗和人性化。

      Launcher這個App，其實和我們做的各類應用類App沒有什麼不同，我們大家用過華為、小米之類的手機，預裝App以及我們下載的各種App，都顯示在Launcher上，每個App表現為一個Icon。Icon多了可以分頁，可以分組，此外，Launcher也會發起網路請求，呼叫天氣的資料，顯示在螢幕上，所謂的人性化介面。

還記得我們在開發一款App時，在Manifest檔案中是怎麼定義預設啟動Activity的麼？如下所示：

而Launcher中為每個App的icon提供了啟動這個App所需要的Intent資訊，如下所示（比如說鬥魚的包名是）：

action：android.intent.action.MAIN

category: android.intent.category.LAUNCHER

cmp: 鬥魚的包名+ 首頁Activity名

這些資訊是App安裝（或Android系統啟動）的時候，PackageManagerService從鬥魚的apk包的manifest檔案中讀取到的。

所以點選icon就啟動了鬥魚App中的首頁。

2）啟動App哪有那麼簡單

前面介紹的只是App啟動的一個最簡單的概述。

仔細看，我們會發現，Launcher和鬥魚是兩個不同的App，他們位於不同的程序中，它們之間的通訊是通過Binder完成的——這時候AMS出場了。

仍然以啟動鬥魚App為例子，整體流程是：

1. Launcher通知AMS，要啟動鬥魚App，而且指定要啟動鬥魚的哪個頁面（也就是首頁）。
2. AMS通知Launcher，好了我知道了，沒你什麼事了，同時，把要啟動的首頁記下來。
3. Launcher當前頁面進入Paused狀態，然後通知AMS，我睡了，你可以去找鬥魚App了。
4. AMS檢查鬥魚App是否已經啟動了。是，則喚起鬥魚App即可。否，就要啟動一個新的程序。AMS在新程序中建立一個ActivityThread物件，啟動其中的main函式。
5. 鬥魚App啟動後，通知AMS，說我啟動好了。
6. AMS翻出之前在第二步存的值，告訴鬥魚App，啟動哪個頁面。
7. 鬥魚App啟動首頁，建立Context並與首頁Activity關聯。然後呼叫首頁Activity的onCreate函式。

至此啟動流程完成，分成兩部分，1-3步，Launcher和AMS相互通訊，而後面幾步，鬥魚App和AMS相互通訊。

這會牽扯一堆類進來，列舉如下，在接下來的分析中，我們都會遇到：

•    Instrumentation
•    ActivityThread
•    H
•    LoadedApk
•    AMS
•    ActivityManagerNative和ActivityManagerProxy
•    ApplicationThread和ApplicationThreadProxy

第1階段 Launcher通知AMS

這是我根據老羅那本書中對Activity的分析，自己手繪的UML圖，一共七張，也就是Activity啟動所經歷的七個階段。建議各位讀者也親自手繪一遍，從而就加深理解。

•    第1步、第2步

      從上圖中我們看到，點選Launcher上的鬥魚App的icon快捷圖示，這時會呼叫Launcher的startActivitySafely方法，其實還是會呼叫Activity的startActivity方法，intent中帶著要啟動鬥魚App所需要的關鍵資訊，如下所示：

      action = “android.intent.action.MAIN”

      category = “android.intent.category.LAUNCHER”

      cmp = “com.douyu.activity.MainActivity”

      第3行程式碼是我猜的，就是鬥魚App在Mainfest檔案中指定為首頁的那個Activity。這樣，我們終於明白，為什麼在Mainfest中，給首頁指定action和category了。在app的安裝過程中，會把這個資訊“記錄”在Launcher的鬥魚啟動快捷圖示中。關於App的安裝過程，我會在後面的文章詳細介紹。

      startActivity這個方法，如果我們看它的實現，會發現它調來調去，經過一系列startActivity的過載方法，最後會走到startActivityForResult方法。

      我們知道startActivityForResult需要兩個引數，一個是intent，另一個是code，這裡code是-1，表示Launcher才不關心鬥魚的App是否啟動成功了呢。

      第3步： startActivityForResult

      Activity內部會保持一個對Instrumentation的引用，但凡是做過App單元測試的同學，對這個類都很熟悉，稱之為儀表盤。

      在startActivityForResult方法的實現中，會呼叫Instrumentation的execStartActivity方法。

看到這裡，我們發現有個mMainThread變數，這是一個ActivityThread型別的變數。

      這個傢伙的來頭可不小。

ActivityThread，就是主執行緒，也就是UI執行緒，它是在App啟動時建立的，它代表了App應用程式。

      啥？ActivityThread代表了App應用程式，那Application類豈不是被架空了？其實，Application對我們App開發人員來說也許很重要，但是在Android系統中還真的沒那麼重要，他就是個上下文。Activity不是有個Context上下文嗎？Application就是整個ActivityThread的上下文。

ActivityThread則沒有那麼簡單了。它裡面有main函式。

      我們知道大部分程式都有main函式，比如java、C#，遠了不說，iPhone App用到的Objective-C，也有main函式，那麼Android的main函式藏在哪裡？就在ActivityThread中，如下所示，程式碼太多，我只截取了一部分

      又有人會問？不是說誰寫的程式，誰就要提供main函式，作為入口嗎？但Android App卻不是這樣的。Android App的main函式，在ActivityThread裡面，而這個類是Android系統提供的底層類，不是我們提供的。

       所以這就是Andoid有趣的地方。Android App的入口是Mainifest中定義預設啟動Activity。這是由Android AMS與四大元件的通訊機制決定的。

       最近在看吳越版的西遊記，就發現這個西天取經為啥用了十幾年啊？因為這師徒四個取經路上愛管閒事，所以耽擱了很久。我這篇文章也是如此，經常講著講著就跑題了，再這麼寫下去，不知道要寫到啥時候，所以我們一路向西，徑直往前走，再遇到奇怪的類，先不要理它。

      在回到程式碼來，這裡要傳遞2個很重要的引數：

•    通過ActivityThread的getApplicationThread方法取到一個Binder物件，它的型別為ApplicationThread，它代表著Launcher所在的App程序。
•    mToken，這也是個Binder物件，它代表了Launcher這個Activity，這裡也通過Instrumentation傳給AMS，AMS一查電話簿，就知道是誰向AMS發起請求了。

      這兩個引數是伏筆，傳遞給AMS，以後AMS想反過來通知Launcher，就能通過這兩個引數，找到Launcher。

       第4步，Instrumentation的execStartActivity方法

       Instrumentation絕對是Adnroid測試團隊的最愛，因為它可以幫我們啟動Activity。

       回到我們的App啟動過程來，在Instrumentation的execStartActivity方法中，

我理解這就是一個透傳，Activity把資料藉助Instrumentation，傳遞給ActivityManagerNative，沒太多有趣的內容，就不多講了。

      第5步：AMN的getDefault方法

      ActivityManagerNative，簡稱AMN。這個類後面會反覆用到。

      AMN通過getDefault方法，從ServiceManager中取得一個名為activity的物件，然後把它包裝成一個ActivityManagerProxy物件（簡稱AMP），AMP就是AMS的代理物件。

      備註1：ServiceManager是一個容器類。

      備註2:  AMN的getDefault方法返回型別為IActivityManager，而不是AMP。IActivityManager是一個實現了IInterface的介面，裡面定義了四大元件所有的生命週期。

      AMN和AMP都實現了IActivityManager介面，AMS繼承自AMN（好亂），那麼對照著前面AIDL的UML，就不難理解了：

第6步，AMP的startActivity方法

看到這裡，你會發現AMP的startActivity方法，和AIDL的Proxy方法，是一模一樣的，寫入資料到另一個程序，也就是AMS，然後等待AMS返回結果。

至此，第一階段的工作就做完了。

後續流程請參加下一篇文章。