VirtualApp拆解之二：Activity启动流程
一、第一次启动插件中Activity的流程
这是指从九宫格点击第一次进入插件时的Activity启动流程。点此链接可查看高清svg图：startActivityFromLaunch
过程分拆：
1、获取插件启动的launch intent
VirtualCore的getLaunchIntent方法通过VPackageManager调用远程（:x进程）的VPackageManagerService的queryIntentActivities方法查询launch intent。
2、发送启动LoadingActivity的请求
请求参数里包含了要启动插件的包名、第一步获取的launch intent、以及由哪个用户启动的（再次申明，VirtualApp是支持多用户的）
3、在LoadingActivity的onCreate回调里做真正启动插件的工作
这个过程包含了以下几步工作
（1）、对插件做dex优化。
（2）、调用VirtualCore的resolveActivityInfo方法解析ActivityInfo，其内部还是要依赖VPackageManager调用远程（:x）进程的VPackageManagerService的相应方法。
（3）、调用VActivityManager的public int startActivity(Intent intent, ActivityInfo info, IBinder resultTo, Bundle options, String resultWho,intrequestCode,intuserId)方法，其实最终是调用了:x进程的VActivityManagerService的对应方法。
4、ActivityStack处理工作
（1）、ActivityStack会向VActivityManagerService查询可用的Stub（坑），然后调用其performStartProcessLocked方法，该方法内部又是去访问可用进程的StubContentProvider的call方法，传递的methodName为initProcess
（2）、调用VClientImpl的initProcess方法初始化该进程相关信息，如ProcessRecord和插件的vuid，其中vuid的获取参看如下代码：
/**
* Returns the vuid that is composed from the userId and the appId.
*@hide
*/
public static intgetUid(intuserId,intappId) {
if(MU_ENABLED) {
returnuserId *PER_USER_RANGE+ (appId %PER_USER_RANGE);
}else{
returnappId;
}
}
（3）、StubContentProvider的initProcess方法处理完成会返回一个Bundle，其中包含了VClientImpl的Binder对象和插件进程的pid，VActivityManagerService则会从Binder中拿到新插件进程的ApplicationThread对象并记录（为了后续处理插件Service）。
（4）、查询可用的StubActivity（占位坑），新建对应的targetIntent，并将要启动的intent信息填入targetIntent中。
5、Hook工作
（1）、启动targetIntent，会进入hooked StartActivity方法（为什么呢？只可意会），该方法发现这是要启动StubActivity，不进行特殊处理。
（2）、真正的AMS会调用插件进程的ApplicationThread的scheduleLaunchActivity方法，然后交由ActivityThread接管，它会利用注入到H的HCallbackStub解析真正要启动的Activity，并上报给VActivityManagerService。
（3）、代理ActivityThread的默认Instrumentation，重写其callActivityOnCreate方法，在这里hack真正启动起来的Activity，如ContextFixer.fixContext、ActivityFixer.fixActivity等等。
二、从插件中启动同进程的standard模式的Activity的流程
这是指在插件启动后，从插件内的Activity跳转到同进程的另一个Activity的过程。点此链接可查看高清svg图：startActivityStandardInSameProcess
过程分拆：
1、第一次Hook
在插件内启动Activity，会进入hooked StartActivity方法，该方法发现这是要启动插件内部的Activity，将解析对应的ActivityInfo，然后交由VActivityManager的public intstartActivity(Intent intent, ActivityInfo info, IBinder resultTo, Bundle options, String resultWho,intrequestCode,intuserId)方法，当然，其实最终是调用了:x进程的VActivityManagerService的对应方法。
2、ActivityStack处理工作
ActivityStack发现要启动的Activity不需要开启新进程，那么它做的事情仅是查询可用的StubActivity（占位坑），新建对应的targetIntent，并将要启动的intent信息填入targetIntent中。最后，重新调用ActivityManagerNative.getDefault.call()的startActivity方法。注意：这里的ActivityManagerNative.getDefault.call()是已经被hook的对象。
3、第二次Hook
（1）、启动第二步建立的targetIntent，会进入hooked StartActivity方法（为什么呢？只可意会），该方法发现这是要启动StubActivity，不进行特殊处理。
（2）、真正的AMS会调用插件进程的ApplicationThread的scheduleLaunchActivity方法，然后交由ActivityThread接管，它会利用注入到H的HCallbackStub解析真正要启动的Activity，并上报给VActivityManagerService。
（3）、代理ActivityThread的默认Instrumentation，重写其callActivityOnCreate方法，在这里hack真正启动起来的Activity，如ContextFixer.fixContext、ActivityFixer.fixActivity等等。
