插件以APK的形式保存在SD卡上，通過startActivity方式啟動Activity需要首先將Activity注冊到AndroidManifest.xml，如果沒有注冊就會出現如下錯誤。
Instrymentation.checkStartActivityResult
要實現插件Activity的啟動需要解決以下問題：
1、插件的Activity需要在宿主的AndroidManifest.xml上注冊。
2、插件Activity需要具有生命周期，能夠響應onPause onResume onStart onDestroy等生命周期函數。
帶著這兩個問題，我們看下Activity的啟動過程。
Activity啟動流程
當調用startActivity后到調用Activity.onCreate會經過如下流程：
1、調用Instrumentation.execStartActivity
execStartActivity
該方法首先調用AMS.startActivity啟動對應的Activity，然后通過checkStartActivityResult來對啟動結果進行檢查，如果沒有在AndroidManifest.xml中注冊該Activity，就會報出ActivityNotFoundException的錯誤。調用AMS.startActivity其實就是通過binder方式調用遠程接口。
2、調用AMS.startActivity
AMS.startActivity會調用AcctivityStackSupervisor.startActivityMayWait函數；然后調用AcctivityStackSupervisor.startActivityLocked；接著調用AcctivityStackSupervisor.startActivityUncheckedLocked；最終調用了AcctivityStackSupervisor.startSpecificActivityLocked。
startSpecificActivityLocked
startSpecificActivityLocked中會判斷app是否為空，app實際類型是ProcessRecord，代表Activity所屬的進程信息。如果為空就調用AMS.startProcessLocked創建進程。
realStartActivityLocked中的實現
如果進程已經存在，就調用realStartActivityLocked函數，realStartActivityLocked會調用app.thread.scheduleLaunchActivity，app.thread時IApplicationThread，這到底是個是什么呢。
我們知道AMS運行在SystemServer進程，而要啟動的Activity運行在APP進程，SystemServer進程要啟動APP進程中的Activity就需要通過binder方式進行操作，這時AMS相當于Client，APP相當于Server，ApplicationThread就是AMS進程調用APP進程的橋梁。ApplicationThread是在APP進程啟動的時候創建的。
上面已經知道AMS.startProcessLocked會創建APP進程：
startProcessLocked
startProcessLocked中會調用Process.start來創建APP進程，
Process.start
Process.start最終通過Zygote來創建進程，并運行進程的入口類ActivityThread.main函數。ApplicationThread就是在這里創建的。
ActivityThread.main
main函數里面給主線程創建了Looper對象，thread.attach將ApplicationThread對象傳給了AMS。
ActivityThread.attach
mAppThread是ApplicationThread類型，mgr是AMS的本地代理，mgr.attachApplication將mAppThread傳給AMS，這樣AMS就可以和APP進程交互了。
ApplicationThread
ApplicationThread提供了眾多方法，包啟動Ativity Service等。
3、ApplicationThread.scheduleLaunchActivity
Activity的創建是在APP進程中完成的，scheduleLaunchActivity通過發送消息到H類型的Handler，最終調用了ActivityThread.performLaunchActivity
ActivityThread.performLaunchActivity
ActivityThread.performLaunchActivity完成Ativity實例的加載，和onCreate的調用。到這里，Activity就已經創建完成了。
文章一開始也提到啟動插件Activity的兩個問題。理解了Activity的啟動過程后，我們可以通過如下方式來解決ActivityNotFound的問題。
1、在宿主APP的AndroidManifest.xml注冊占坑Activity
2、Hook調ActivityThread的Instrumentation對象，當檢測到startActivity啟動的是插件Activity時，將目標Activity替換成宿主占坑的Activity，這樣就繞過了ActivityNotFound問題。
3、hook調ActivityThread的mInstrumentation對象的newActivity函數，這樣當發現啟動的是宿主占坑Activity時，在將宿主占坑Activity換成插件Activity，ClassLoader加載的實際上是插件的Activity對象。
實際上VirtualApk就是這么做的。
宿主占坑Activity
宿主AndroidManifest.xml中配置了各種啟動模式的占坑Activity。
PluginManager.hookInstrumentationAndHandler
PluginManager.hookInstrumentationAndHandler，hook掉APP進程的ActivityThread中的Instrumentation對象。
Instrumentation.execStartActivity
execStartActivity是ContextImpl.startActivity調用的第一個函數，VirtualApk通過hook這個函數，markIntentIfNeeded函數將啟動插件的Intent轉換成啟動占坑的Activity。
轉換Intent
dispatchStudActivity完成插件Activity和宿主Activity的轉換。
調用員來mInstrumentation.execStartActivity
轉換完成后就繼續調用原來mInstrumentation對象的execStartActivity函數，繼續調用AMS相關的方法。
newActivity
剛剛完成了貍貓換太子，繞過了ActivityNotFound的檢測，在newActivity創建Activity對象的時候需要再換回來，也就是將宿主占坑Activity的調用換回到實際插件Activity的加載。
callActivityOnCreate
newActivity加載完插件Activity會調用callActivityOnCreate，但此時插件Activity對象的resource資源、context都是宿主的，hook調callActivityOnCreate可以自己設置插件的Resources Context等信息。
到這里就解決了加載插件的第一個問題（ActivityNotFound），那么這樣創建的Activity具有生命周期么？能夠響應onPause onResume等生命周期方法么？
答案是肯定的，我們以onPause方法為例。
當要調用Activity.onPause時，調用流程如下：AMS.activityPause-->ActivityStack.activityPausedLocked-->....ApplicationThread.schedulePauseActivity-->ActivityThread.handlePauseActivity-->ActivityThread.performPauseActivity
ActivityThread.performPauseActivity
ActivityThread.performPauseActivity根據token來查找要pause的Activity，那么這個token是哪里來的呢？
ActivityThread.performLaunchActivity
跟蹤代碼發現ActivityThread.performLaunchActivity在創建Activity對象的時候做了mActivities的保存。r.token也就是ActiviyClientRecord中的token對象，是AMS傳過來的，該token和Activity類名無關，只要能找到token和Activity對應關系即可。因此不影響Activity的生命周期。
至此，就解決了啟動插件Activity的兩個問題。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://www.jianshu.com/p/a768810c3ff8
