插件以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的兩個問題。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持VEVB武林網。