插件以APK的形式保存在SD卡上，通过startActivity方式启动Activity需要首先将Activity注册到AndroidManifest.xml，如果没有注册就会出现如下错误。

要实现插件Activity的启动需要解决以下问题：

1、插件的Activity需要在宿主的AndroidManifest.xml上注册。

2、插件Activity需要具有生命周期，能够响应onPause onResume onStart  onDestroy等生命周期函数。

带着这两个问题，我们看下Activity的启动过程。

当调用startActivity后到调用Activity.onCreate会经过如下流程：

1、调用Instrumentation.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中会判断app是否为空，app实际类型是ProcessRecord，代表Activity所属的进程信息。如果为空就调用AMS.startProcessLocked创建进程。

如果进程已经存在，就调用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中会调用Process.start来创建APP进程，

Process.start最终通过Zygote来创建进程，并运行进程的入口类ActivityThread.main函数。ApplicationThread就是在这里创建的。

main函数里面给主线程创建了Looper对象，thread.attach将ApplicationThread对象传给了AMS。

mAppThread是ApplicationThread类型，mgr是AMS的本地代理，mgr.attachApplication将mAppThread传给AMS，这样AMS就可以和APP进程交互了。

ApplicationThread提供了众多方法，包启动Ativity Service等。

3、ApplicationThread.scheduleLaunchActivity

Activity的创建是在APP进程中完成的，scheduleLaunchActivity通过发送消息到H类型的Handler，最终调用了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就是这么做的。

宿主AndroidManifest.xml中配置了各种启动模式的占坑Activity。

PluginManager.hookInstrumentationAndHandler，hook掉APP进程的ActivityThread中的Instrumentation对象。

execStartActivity是ContextImpl.startActivity调用的第一个函数，VirtualApk通过hook这个函数，markIntentIfNeeded函数将启动插件的Intent转换成启动占坑的Activity。

dispatchStudActivity完成插件Activity和宿主Activity的转换。

转换完成后就继续调用原来mInstrumentation对象的execStartActivity函数，继续调用AMS相关的方法。

刚刚完成了狸猫换太子，绕过了ActivityNotFound的检测，在newActivity创建Activity对象的时候需要再换回来，也就是将宿主占坑Activity的调用换回到实际插件Activity的加载。

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根据token来查找要pause的Activity，那么这个token是哪里来的呢？

跟踪代码发现ActivityThread.performLaunchActivity在创建Activity对象的时候做了mActivities的保存。r.token也就是ActiviyClientRecord中的token对象，是AMS传过来的，该token和Activity类名无关，只要能找到token和Activity对应关系即可。因此不影响Activity的生命周期。

至此，就解决了启动插件Activity的两个问题。