插件以APK的形式保存在SD卡上，通過startActivity方式啟動(dòng)Activity需要首先將Activity注冊(cè)到AndroidManifest.xml，如果沒有注冊(cè)就會(huì)出現(xiàn)如下錯(cuò)誤。

Instrymentation.checkStartActivityResult

要實(shí)現(xiàn)插件Activity的啟動(dòng)需要解決以下問題：

1、插件的Activity需要在宿主的AndroidManifest.xml上注冊(cè)。

2、插件Activity需要具有生命周期，能夠響應(yīng)onPause onResume onStart  onDestroy等生命周期函數(shù)。

帶著這兩個(gè)問題，我們看下Activity的啟動(dòng)過程。

Activity啟動(dòng)流程

當(dāng)調(diào)用startActivity后到調(diào)用Activity.onCreate會(huì)經(jīng)過如下流程：

1、調(diào)用Instrumentation.execStartActivity

execStartActivity

該方法首先調(diào)用AMS.startActivity啟動(dòng)對(duì)應(yīng)的Activity，然后通過checkStartActivityResult來對(duì)啟動(dòng)結(jié)果進(jìn)行檢查，如果沒有在AndroidManifest.xml中注冊(cè)該Activity，就會(huì)報(bào)出ActivityNotFoundException的錯(cuò)誤。調(diào)用AMS.startActivity其實(shí)就是通過binder方式調(diào)用遠(yuǎn)程接口。

2、調(diào)用AMS.startActivity

AMS.startActivity會(huì)調(diào)用AcctivityStackSupervisor.startActivityMayWait函數(shù)；然后調(diào)用AcctivityStackSupervisor.startActivityLocked；接著調(diào)用AcctivityStackSupervisor.startActivityUncheckedLocked；最終調(diào)用了AcctivityStackSupervisor.startSpecificActivityLocked。

startSpecificActivityLocked

startSpecificActivityLocked中會(huì)判斷app是否為空，app實(shí)際類型是ProcessRecord，代表Activity所屬的進(jìn)程信息。如果為空就調(diào)用AMS.startProcessLocked創(chuàng)建進(jìn)程。

realStartActivityLocked中的實(shí)現(xiàn)

如果進(jìn)程已經(jīng)存在，就調(diào)用realStartActivityLocked函數(shù)，realStartActivityLocked會(huì)調(diào)用app.thread.scheduleLaunchActivity，app.thread時(shí)IApplicationThread，這到底是個(gè)是什么呢。

我們知道AMS運(yùn)行在SystemServer進(jìn)程，而要啟動(dòng)的Activity運(yùn)行在APP進(jìn)程，SystemServer進(jìn)程要啟動(dòng)APP進(jìn)程中的Activity就需要通過binder方式進(jìn)行操作，這時(shí)AMS相當(dāng)于Client，APP相當(dāng)于Server，ApplicationThread就是AMS進(jìn)程調(diào)用APP進(jìn)程的橋梁。ApplicationThread是在APP進(jìn)程啟動(dòng)的時(shí)候創(chuàng)建的。

上面已經(jīng)知道AMS.startProcessLocked會(huì)創(chuàng)建APP進(jìn)程：

startProcessLocked

startProcessLocked中會(huì)調(diào)用Process.start來創(chuàng)建APP進(jìn)程，

Process.start

Process.start最終通過Zygote來創(chuàng)建進(jìn)程，并運(yùn)行進(jìn)程的入口類ActivityThread.main函數(shù)。ApplicationThread就是在這里創(chuàng)建的。

ActivityThread.main

main函數(shù)里面給主線程創(chuàng)建了Looper對(duì)象，thread.attach將ApplicationThread對(duì)象傳給了AMS。

ActivityThread.attach

mAppThread是ApplicationThread類型，mgr是AMS的本地代理，mgr.attachApplication將mAppThread傳給AMS，這樣AMS就可以和APP進(jìn)程交互了。

ApplicationThread

ApplicationThread提供了眾多方法，包啟動(dòng)Ativity Service等。

3、ApplicationThread.scheduleLaunchActivity

Activity的創(chuàng)建是在APP進(jìn)程中完成的，scheduleLaunchActivity通過發(fā)送消息到H類型的Handler，最終調(diào)用了ActivityThread.performLaunchActivity

ActivityThread.performLaunchActivity

ActivityThread.performLaunchActivity完成Ativity實(shí)例的加載，和onCreate的調(diào)用。到這里，Activity就已經(jīng)創(chuàng)建完成了。

文章一開始也提到啟動(dòng)插件Activity的兩個(gè)問題。理解了Activity的啟動(dòng)過程后，我們可以通過如下方式來解決ActivityNotFound的問題。

1、在宿主APP的AndroidManifest.xml注冊(cè)占坑Activity

2、Hook調(diào)ActivityThread的Instrumentation對(duì)象，當(dāng)檢測(cè)到startActivity啟動(dòng)的是插件Activity時(shí)，將目標(biāo)Activity替換成宿主占坑的Activity，這樣就繞過了ActivityNotFound問題。

3、hook調(diào)ActivityThread的mInstrumentation對(duì)象的newActivity函數(shù)，這樣當(dāng)發(fā)現(xiàn)啟動(dòng)的是宿主占坑Activity時(shí)，在將宿主占坑Activity換成插件Activity，ClassLoader加載的實(shí)際上是插件的Activity對(duì)象。

實(shí)際上VirtualApk就是這么做的。

宿主占坑Activity

宿主AndroidManifest.xml中配置了各種啟動(dòng)模式的占坑Activity。

PluginManager.hookInstrumentationAndHandler

PluginManager.hookInstrumentationAndHandler，hook掉APP進(jìn)程的ActivityThread中的Instrumentation對(duì)象。

Instrumentation.execStartActivity

execStartActivity是ContextImpl.startActivity調(diào)用的第一個(gè)函數(shù)，VirtualApk通過hook這個(gè)函數(shù)，markIntentIfNeeded函數(shù)將啟動(dòng)插件的Intent轉(zhuǎn)換成啟動(dòng)占坑的Activity。

轉(zhuǎn)換Intent

dispatchStudActivity完成插件Activity和宿主Activity的轉(zhuǎn)換。

調(diào)用員來mInstrumentation.execStartActivity

轉(zhuǎn)換完成后就繼續(xù)調(diào)用原來mInstrumentation對(duì)象的execStartActivity函數(shù)，繼續(xù)調(diào)用AMS相關(guān)的方法。

newActivity

剛剛完成了貍貓換太子，繞過了ActivityNotFound的檢測(cè)，在newActivity創(chuàng)建Activity對(duì)象的時(shí)候需要再換回來，也就是將宿主占坑Activity的調(diào)用換回到實(shí)際插件Activity的加載。

callActivityOnCreate

newActivity加載完插件Activity會(huì)調(diào)用callActivityOnCreate，但此時(shí)插件Activity對(duì)象的resource資源、context都是宿主的，hook調(diào)callActivityOnCreate可以自己設(shè)置插件的Resources Context等信息。

到這里就解決了加載插件的第一個(gè)問題（ActivityNotFound），那么這樣創(chuàng)建的Activity具有生命周期么？能夠響應(yīng)onPause onResume等生命周期方法么？

答案是肯定的，我們以onPause方法為例。

當(dāng)要調(diào)用Activity.onPause時(shí)，調(diào)用流程如下：AMS.activityPause-->ActivityStack.activityPausedLocked-->....ApplicationThread.schedulePauseActivity-->ActivityThread.handlePauseActivity-->ActivityThread.performPauseActivity

ActivityThread.performPauseActivity

ActivityThread.performPauseActivity根據(jù)token來查找要pause的Activity，那么這個(gè)token是哪里來的呢？

ActivityThread.performLaunchActivity

跟蹤代碼發(fā)現(xiàn)ActivityThread.performLaunchActivity在創(chuàng)建Activity對(duì)象的時(shí)候做了mActivities的保存。r.token也就是ActiviyClientRecord中的token對(duì)象，是AMS傳過來的，該token和Activity類名無關(guān)，只要能找到token和Activity對(duì)應(yīng)關(guān)系即可。因此不影響Activity的生命周期。

至此，就解決了啟動(dòng)插件Activity的兩個(gè)問題。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論