內(nèi)容摘錄自《Android插件化開發(fā)指南》

以啟動(dòng)斗魚app為例子

• Launcher通知AMS，要啟動(dòng)斗魚App，而且指定要啟動(dòng)斗魚的哪個(gè)頁面（也就是首頁）。

• AMS通知Launcher，好了我知道了，沒你什么事了，同時(shí)，把要啟動(dòng)的首頁記下來。

• Launcher當(dāng)前頁面進(jìn)入Paused狀態(tài)，然后通知AMS，我睡了，你可以去找斗魚App了。

• AMS檢查斗魚App是否已經(jīng)啟動(dòng)了。是，則喚起斗魚App即可。否，就要啟動(dòng)一個(gè)新的進(jìn)程。AMS在新進(jìn)程中創(chuàng)建一個(gè)ActivityThread對象，啟動(dòng)其中的main函數(shù)。

• 斗魚App啟動(dòng)后，通知AMS，說我啟動(dòng)好了。

• AMS翻出之前在第二步存的值，告訴斗魚App，啟動(dòng)哪個(gè)頁面。

• 斗魚App啟動(dòng)首頁，創(chuàng)建Context并與首頁Activity關(guān)聯(lián)。然后調(diào)用首頁Activity的onCreate函數(shù)。

image.png

第一階段: Launcher通知AMS

image.png

對第五步做個(gè)解釋

ActivityManagerNative，簡稱AMN。這個(gè)類后面會(huì)反復(fù)用到。

AMN通過getDefault方法，從ServiceManager中取得一個(gè)名為activity的對象，然后把它包裝成一個(gè)ActivityManagerProxy對象（簡稱AMP），AMP就是AMS的代理對象。

備注1：ServiceManager是一個(gè)容器類。

備注2: AMN的getDefault方法返回類型為IActivityManager，而不是AMP。IActivityManager是一個(gè)實(shí)現(xiàn)了IInterface的接口，里面定義了四大組件所有的生命周期。

AMN和AMP都實(shí)現(xiàn)了IActivityManager接口，AMS繼承自AMN

image.png

第二階段：AMS處理Laucher傳過來的信息

• 首先Binder，也就是AMN/AMP，和AMS通信，肯定每次是做不同的事情，就比如說這次Launcher要啟動(dòng)斗魚App，那么會(huì)發(fā)送類型為START_ACTIVITY——TRANSACTION的請求給AMS，同時(shí)會(huì)告訴AMS要啟動(dòng)哪個(gè)Activity。

• AMS說，好，我知道了，然后它會(huì)干一件很有趣的事情，就是檢查斗魚App中的Manifest文件，是否存在要啟動(dòng)的Activity。如果不存在，就拋出Activity not found的錯(cuò)誤，各位做App的同學(xué)對這個(gè)異常應(yīng)該再熟悉不過了，經(jīng)常寫了個(gè)Activity而忘記在Manifest中聲明了，就報(bào)這個(gè)錯(cuò)，就是因?yàn)锳MS在這里做檢查。不管是新啟動(dòng)一個(gè)App的首頁，還是在App內(nèi)部跳轉(zhuǎn)到另一個(gè)Activity，都會(huì)做這個(gè)檢查。

• 但是Launcher還活著啊，所以接下來AMS會(huì)通知Launcher，哥們兒沒你什么事了，你洗洗睡吧。那么AMS是通過什么途徑告訴Launcher的呢？

image.png

結(jié)論是AMS通過ApplicationThreadProxy發(fā)送消息，而App端則通過ApplicationThread來接收這個(gè)消息。

第三階段：Launcher去休眠，然后通知AMS，“我真的已經(jīng)睡了”

image.png

ASM給Activity發(fā)送的所有消息，以及給其他三大組件發(fā)送的所有消息，都是從H這里經(jīng)過的。為什么要強(qiáng)調(diào)這一點(diǎn)呢？既然四大組件都走這條路，那么久可以從這里入手做插件化技術(shù)了。

第四階段：AMS啟動(dòng)新的進(jìn)程

AMS接下來要啟動(dòng)斗魚App的首頁，因?yàn)槎肤~App不在后臺(tái)進(jìn)程中，所以要啟動(dòng)一個(gè)新的進(jìn)程。這里指定了ActivityThread的main函數(shù)為入口函數(shù)。

int pid =Process.start("android.app.ActivityThread",mSimpleProcessManagement ? app.processName : gid , debugFlags, null);

第五階段：新的進(jìn)程啟動(dòng)，以ActivityThread的main函數(shù)作為入口

image.png

在啟動(dòng)新進(jìn)程的時(shí)候，為這個(gè)進(jìn)程創(chuàng)建ActivityThread對象，也就是UI線程。創(chuàng)建好UI線程后，立刻進(jìn)入ActivityThread的main函數(shù)，接下來要做兩件事：

1）創(chuàng)建一個(gè)主線程Looper，也就是MainLooper.

2. 創(chuàng)建Application

創(chuàng)建新App的最后就是告訴AMS"我啟動(dòng)好了"，同時(shí)把自己的ActivityThread對象發(fā)送給AMS.

第六階段：AMS告訴新App啟動(dòng)哪個(gè)Activity

在第一階段，Launcher通知AMS，要啟動(dòng)斗魚App的哪個(gè)Activity。在第二階段，這個(gè)信息被AMS存下來。在第六階段，AMS從過去的記錄中翻出來要啟動(dòng)哪個(gè)Activity，然后通過ApplicationThreadProxy告訴App

第七階段： 啟動(dòng)斗魚首頁Activity

在Binder的另一端，App通過ApplicationThread接收到了AMS的消息，仍然在H的handleMessage方法的switch語句中處理，只不過這次的消息類型是LAUNCH_ACTIVITY，回調(diào)ActivityThread的handleLaunchActivity方法。

handleLaunchActivity方法做了哪些事情呢 ？

• 通過Instrumentation的newActivity方法，創(chuàng)建要啟動(dòng)的Activity實(shí)例。

• 為這個(gè)Activity創(chuàng)建一個(gè)上下文Context對象，并與Activity進(jìn)行關(guān)聯(lián)

• 通過Instrumentation的callActivityOnCreate方法，執(zhí)行Activity的onCreate()方法，從而啟動(dòng)Activity.