本文主要是介绍滴滴插件化框架VirtualAPK原理解析（一）之插件Activity管理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
上周末，滴滴与360都开源了各自的插件化框架，VirtualAPK与RePlugin,作为一个插件化方面的狂热研究者，在周末就迫不及待的下载了Virtualapk框架来进行研究，本篇博客带来的是VirtualAPK原理解析的第一篇Activity管理，博客只是自己的理解，小弟才疏学浅，可能有很多理解不对的地方，欢迎各位大神指出。（看博客之前，请大家先下载VirtualVirtualAPKapk的项目，https://github.com/didi/VirtualAPK）
Freedom框架，我个人手写的0反射插件化框架
Hook ActivityManagerService
在解释VirtualAPK是如何对Activity进行管理之前，有必要说一下ActivityManagerService，Android的四大组件都需要与它打交道，它主要为四大组件做了这些事情：
1.startActivity最终调用了AMS的startActivity方法，实现了Activity的启动；Activity的生命周期回调，也在AMS中完成；
//ActivityManagerService.java@Overridepublic final int startActivity(IApplicationThread caller, String callingPackage,Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,int startFlags, ProfilerInfo profilerInfo, Bundle options) {return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,resultWho, requestCode, startFlags, profilerInfo, options,UserHandle.getCallingUserId());}
2.startService,bindService最终调用到AMS的startService和bindService方法；
//ActivityManagerService.javapublic int bindService(IApplicationThread caller, IBinder token,Intent service, String resolvedType,IServiceConnection connection, int flags, int userId) {enforceNotIsolatedCaller("bindService");// Refuse possible leaked file descriptorsif (service != null && service.hasFileDescriptors() == true) {throw new IllegalArgumentException("File descriptors passed in Intent");}synchronized(this) {return mServices.bindServiceLocked(caller, token, service, resolvedType,connection, flags, userId);}}
3.动态广播的注册和接收在AMS中完成（静态广播在PMS中完成）
public Intent registerReceiver(IApplicationThread caller, String callerPackage,IIntentReceiver receiver, IntentFilter filter, String permission, int userId) {enforceNotIsolatedCaller("registerReceiver");int callingUid;int callingPid;synchronized(this) {ProcessRecord callerApp = null;if (caller != null) {callerApp = getRecordForAppLocked(caller);if (callerApp == null) {throw new SecurityException("Unable to find app for caller " + caller+ " (pid=" + Binder.getCallingPid()+ ") when registering receiver " + receiver);}if (callerApp.info.uid != Process.SYSTEM_UID &&!callerApp.pkgList.containsKey(callerPackage) &&!"android".equals(callerPackage)) {throw new SecurityException("Given caller package " + callerPackage+ " is not running in process " + callerApp);}callingUid = callerApp.info.uid;callingPid = callerApp.pid;} else {callerPackage = null;callingUid = Binder.getCallingUid();callingPid = Binder.getCallingPid();}userId = this.handleIncomingUser(callingPid, callingUid, userId,true, ALLOW_FULL_ONLY, "registerReceiver", callerPackage);List allSticky = null;// Look for any matching sticky broadcasts...Iterator actions = filter.actionsIterator();if (actions != null) {while (actions.hasNext()) {String action = (String)actions.next();allSticky = getStickiesLocked(action, filter, allSticky,UserHandle.USER_ALL);allSticky = getStickiesLocked(action, filter, allSticky,UserHandle.getUserId(callingUid));}} else {allSticky = getStickiesLocked(null, filter, allSticky,UserHandle.USER_ALL);allSticky = getStickiesLocked(null, filter, allSticky,UserHandle.getUserId(callingUid));}// The first sticky in the list is returned directly back to// the client.Intent sticky = allSticky != null ? (Intent)allSticky.get(0) : null;if (DEBUG_BROADCAST) Slog.v(TAG, "Register receiver " + filter+ ": " + sticky);if (receiver == null) {return sticky;}ReceiverList rl= (ReceiverList)mRegisteredReceivers.get(receiver.asBinder());
...........
4.getContentResolver最终从AMS的getContentProvider获取到ContentProvider
@Overridepublic final ContentProviderHolder getContentProvider(IApplicationThread caller, String name, int userId, boolean stable) {enforceNotIsolatedCaller("getContentProvider");if (caller == null) {String msg = "null IApplicationThread when getting content provider "+ name;Slog.w(TAG, msg);throw new SecurityException(msg);}// The incoming user check is now handled in checkContentProviderPermissionLocked() to deal// with cross-user grant.return getContentProviderImpl(caller, name, null, stable, userId);}
AMS以Binder方式提供给应用程序使用的系统服务,所以我们要处理插件中的四大组件，必须要Hook掉AMS进行相应的处理。
startActivity与AMS的关系
前面我们说过Activity的启动最终会调用到了AMS的方法进行启动，接下来我们就先分析这一个过程。
在开发中，我们使用startActivity有两种形式：
1.直接使用Context类的startActivity方法；这种方式启动的Activity没有Activity栈，因此不能以standard方式启动，必须加上FLAG_ACTIVITY_NEW_TASK这个Flag。
2.调用被Activity类重载过的startActivity方法，通常在我们的Activity中直接调用这个方法就是这种形式；
context的startActivity
先来分析第一种情况，context的startActivity是一个抽象方法
public abstract void startActivity(Intent intent);
Activity，Service等并没有直接继承Context，而是继承了ContextWrapper，所以我们需要看ContextWrapper里面的startActivity方法
@Overridepublic void startActivity(Intent intent) {mBase.startActivity(intent);}我们可以得知，startActivity方法最终会通过mBase来完成，它的真正实现是ContextImpl类
@Overridepublic void startActivity(Intent intent) {warnIfCallingFromSystemProcess();startActivity(intent, null);}在继续往下追寻，会看到如下代码：
@Overridepublic void startActivity(Intent intent, Bundle options) {warnIfCallingFromSystemProcess();if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {throw new AndroidRuntimeException("Calling startActivity() from outside of an Activity "+ " context requires the FLAG_ACTIVITY_NEW_TASK flag."+ " Is this really what you want?");}mMainThread.getInstrumentation().execStartActivity(getOuterContext(), mMainThread.getApplicationThread(), null,(Activity)null, intent, -1, options);}
看到这里，你是不是突然恍然大悟，为什么平常在使用非Activity的Context来startActivity的时候会需要添加FLAG_ACTIVITY_NEW_TASK；
我们还可以得出结论，真正的startActivity使用了Instrumentation类的execStartActivity方法；
public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target,Intent intent, int requestCode, Bundle options) {// ... 省略无关代码try {intent.migrateExtraStreamToClipData();intent.prepareToLeaveProcess();int result = ActivityManagerNative.getDefault().startActivity(whoThread, who.getBasePackageName(), intent,intent.resolveTypeIfNeeded(who.getContentResolver()),token, target != null ? target.mEmbeddedID : null,requestCode, 0, null, null, options);checkStartActivityResult(result, intent);} catch (RemoteException e) {}return null;
}
到这里我们发现真正调用的是ActivityManagerNative的startActivity方法，至于ActivityManagerNative是啥，请自行查资料
Activity的startActivity
Activity类的startActivity方法相比Context而言直观了很多；这个startActivity通过若干次调用辗转到达startActivityForResult这个方法，在这个方法内部有如下代码：
Instrumentation.ActivityResult ar =mInstrumentation.execStartActivity(this, mMainThread.getApplicationThread(), mToken, this,intent, requestCode, options);if (ar != null) {mMainThread.sendActivityResult(mToken, mEmbeddedID, requestCode, ar.getResultCode(),ar.getResultData());}
可以得知，通过Activity和ContextImpl类启动Activity是一样的，他们都通过Instrumentation这个辅助类调用到了ActivityManagerNative的方法。
Hook AMS
前面说过，startActivity最终通过ActivityManagerNative这个方法远程调用了AMS的startActivity方法，ActivityManagerNative实际上就是ActivityManagerService这个远程对象的Binder代理对象；每次需要与AMS打交道的时候，需要借助这个代理对象通过驱动进而完成IPC调用。
ActivityManagerNative中有一个getDefault()方法
/*** Retrieve the system's default/global activity manager.*/static public IActivityManager getDefault() {return gDefault.get();}
gDefault这个静态变量的定义如下：
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {protected IActivityManager create() {IBinder b = ServiceManager.getService("activity");if (false) {Log.v("ActivityManager", "default service binder = " + b);}IActivityManager am = asInterface(b);if (false) {Log.v("ActivityManager", "default service = " + am);}return am;}};
framework使用了一个单例把这个AMS的代理对象保存了起来；这样只要需要与AMS进行IPC调用，获取这个单例即可，所以我们需要Hook掉这个单例，就可以达到Hook AMS的效果，在Virtualapk中我们就可以看到如下一段代码：
//PluginManager.java
/*** hookSystemServices, but need to compatible with Android O in future.*/private void hookSystemServices() {try {Singleton<IActivityManager> defaultSingleton = (Singleton<IActivityManager>) ReflectUtil.getField(ActivityManagerNative.class, null, "gDefault");IActivityManager activityManagerProxy = ActivityManagerProxy.newInstance(this, defaultSingleton.get());// Hook IActivityManager from ActivityManagerNativeReflectUtil.setField(defaultSingleton.getClass().getSuperclass(), defaultSingleton, "mInstance", activityManagerProxy);if (defaultSingleton.get() == activityManagerProxy) {this.mActivityManager = activityManagerProxy;}} catch (Exception e) {e.printStackTrace();}}
可以看到在VirtualAPK中PluginManager类里，就是替换掉了ActivityManagerNative为VirtualAPK中自己的ActivityManagerProxy，而这个ActivityManagerProxy其实是一个动态代理，所有ActivityManagerNative中的方法都会经过这个代理
public static IActivityManager newInstance(PluginManager pluginManager, IActivityManager activityManager) {return (IActivityManager) Proxy.newProxyInstance(activityManager.getClass().getClassLoader(), new Class[] { IActivityManager.class }, new ActivityManagerProxy(pluginManager, activityManager));}
我们可以看到在ActivityManagerProxy的invoke方法，针对一些方法进行了处理
@Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable {if ("startService".equals(method.getName())) {try {return startService(proxy, method, args);} catch (Throwable e) {Log.e(TAG, "Start service error", e);}} else if ("stopService".equals(method.getName())) {try {return stopService(proxy, method, args);} catch (Throwable e) {Log.e(TAG, "Stop Service error", e);}} else if ("stopServiceToken".equals(method.getName())) {try {return stopServiceToken(proxy, method, args);} catch (Throwable e) {Log.e(TAG, "Stop service token error", e);}} else if ("bindService".equals(method.getName())) {try {return bindService(proxy, method, args);} catch (Throwable e) {e.printStackTrace();}} else if ("unbindService".equals(method.getName())) {try {return unbindService(proxy, method, args);} catch (Throwable e) {e.printStackTrace();}} else if ("getIntentSender".equals(method.getName())) {try {getIntentSender(method, args);} catch (Exception e) {e.printStackTrace();}} else if ("overridePendingTransition".equals(method.getName())){try {overridePendingTransition(method, args);} catch (Exception e){e.printStackTrace();}}try {// sometimes system binder has problems.return method.invoke(this.mActivityManager, args);} catch (Throwable th) {Throwable c = th.getCause();if (c != null && c instanceof DeadObjectException) {// retry connect to system binderIBinder ams = ServiceManager.getService(Context.ACTIVITY_SERVICE);if (ams != null) {IActivityManager am = ActivityManagerNative.asInterface(ams);mActivityManager = am;}}Throwable cause = th;do {if (cause instanceof RemoteException) {throw cause;}} while ((cause = cause.getCause()) != null);throw c != null ? c : th;}}
上述关于startService等方法的处理，我们在后面说道service时再详细说明，这里我们只要知道VirtualAPK中是如何Hook AMS的
启动插件Activity会遇到什么限制？
在Android中启动Activity有一个限制：必须在AndroidManifest.xml中显示声明使用的Activity；否则会遇到下面这种异常：
Process: com.example.dldemo, PID: 3600java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.dldemo/com.example.dldemo.MainActivity}: android.content.ActivityNotFoundException: Unable to find explicit activity class {com.example.dldemo/com.example.dldemo.TestActivity1}; have you declared this activity in your AndroidManifest.xml?at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2416)at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2476)at android.app.ActivityThread.-wrap11(ActivityThread.java)at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1344)at android.os.Handler.dispatchMessage(Handler.java:102)at android.os.Looper.loop(Looper.java:148)at android.app.ActivityThread.main(ActivityThread.java:5417)at java.lang.reflect.Method.invoke(Native Method)at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
必须在AndroidManifest.xml中显示声明使用的Activity，这个硬性要求很大程度上限制了插件系统的发挥：因为插件的Activity必定不会在宿主程序中进行声明
如何绕过这个限制呢？既然AndroidManifest文件中必须声明，那么我就声明一个（或者有限个）替身Activity好了，当需要启动插件的某个Activity的时候，先让系统以为启动的是AndroidManifest中声明的那个替身，暂时骗过系统；然后到合适的时候又替换回我们需要启动的真正的Activity；我们打开Virtualapk的Library,查看清单文件中，声明了各种启动模式的Activity
<!-- Stub Activities --><activity android:name=".A$1" android:launchMode="standard"/><activity android:name=".A$2" android:launchMode="standard"android:theme="@android:style/Theme.Translucent" /><!-- Stub Activities --><activity android:name=".B$1" android:launchMode="singleTop"/><activity android:name=".B$2" android:launchMode="singleTop"/><activity android:name=".B$3" android:launchMode="singleTop"/><activity android:name=".B$4" android:launchMode="singleTop"/><activity android:name=".B$5" android:launchMode="singleTop"/><activity android:name=".B$6" android:launchMode="singleTop"/><activity android:name=".B$7" android:launchMode="singleTop"/><activity android:name=".B$8" android:launchMode="singleTop"/><!-- Stub Activities --><activity android:name=".C$1" android:launchMode="singleTask"/><activity android:name=".C$2" android:launchMode="singleTask"/><activity android:name=".C$3" android:launchMode="singleTask"/><activity android:name=".C$4" android:launchMode="singleTask"/><activity android:name=".C$5" android:launchMode="singleTask"/><activity android:name=".C$6" android:launchMode="singleTask"/><activity android:name=".C$7" android:launchMode="singleTask"/><activity android:name=".C$8" android:launchMode="singleTask"/><!-- Stub Activities --><activity android:name=".D$1" android:launchMode="singleInstance"/><activity android:name=".D$2" android:launchMode="singleInstance"/><activity android:name=".D$3" android:launchMode="singleInstance"/><activity android:name=".D$4" android:launchMode="singleInstance"/><activity android:name=".D$5" android:launchMode="singleInstance"/><activity android:name=".D$6" android:launchMode="singleInstance"/><activity android:name=".D$7" android:launchMode="singleInstance"/><activity android:name=".D$8" android:launchMode="singleInstance"/>
可以发现，Virtualapk采用的正是我上面说的暂坑的模式，那我们到底要如何进行偷梁换柱呢，这就必须从Activity启动过程来进行分析
Activity启动过程
这里简单描述一下Activity的启动过程，想了解详细启动过程，后面我会用一篇博客进行讲解
在前面分析AMS的时候，我们知道Activity的startActivity最终会来到ActivityManagerNative类的startActivity方法，接下来会通过Binder IPC到AMS所在进程调用AMS的startActivity方法；Android系统的组件生命周期管理就是在AMS里面完成的
ActivityManagerService的startActivity方法如下：
@Overridepublic final int startActivity(IApplicationThread caller, String callingPackage,Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,int startFlags, ProfilerInfo profilerInfo, Bundle options) {return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,resultWho, requestCode, startFlags, profilerInfo, options,UserHandle.getCallingUserId());}
直接调用了startActivityAsUser这个方法；接着是ActivityStackSupervisor类的startActivityMayWait方法。
startActivityMayWait这个方法前面对参数进行了一系列处理，在这个方法内部对传进来的Intent进行了解析，并尝试从中取出关于启动Activity的信息。
然后这个方法调用了startActivityLocked方法；在startActivityLocked方法内部进行了一系列重要的检查：比如权限检查，Activity的exported属性检查等等；前面所述的，启动没有在Manifestfest中显示声明的Activity抛异常也是这里发生的：
if (err == ActivityManager.START_SUCCESS && intent.getComponent() == null) {// We couldn't find a class that can handle the given Intent.// That's the end of that!err = ActivityManager.START_INTENT_NOT_RESOLVED;}
这里返回ActivityManager.START_CLASS_NOT_FOUND之后，在Instrument的execStartActivity返回之后会检查这个值，然后抛出异常：
case ActivityManager.START_CLASS_NOT_FOUND:if (intent instanceof Intent && ((Intent)intent).getComponent() != null)throw new ActivityNotFoundException("Unable to find explicit activity class "+ ((Intent)intent).getComponent().toShortString()+ "; have you declared this activity in your AndroidManifest.xml?");throw new ActivityNotFoundException("No Activity found to handle " + intent);
从这里，我们明白了必须在AndroidManifest.xml中显示声明使用的Activity的原因；然而这个校检过程发生在AMS所在的进程system_server，我们是不能更改system_server进程的东西的。
startActivityLocked之后处理的都是Activity任务栈相关内容
声明：图片来源于网络
这一系列调用最终到达了ActivityStackSupervisor的realStartActivityLocked方法；这个方法开始了真正的“启动Activity”：它调用了ApplicationThread的scheduleLaunchActivity方法，开始了真正的Activity对象创建以及启动过程。
ApplicationThread实际上是一个Binder对象，是App所在的进程与AMS所在进程system_server通信的桥梁：
1.App进程会委托AMS进程完成Activity生命周期的管理以及任务栈的管理；这个通信过程AMS是Server端，App进程通过持有AMS的client代理ActivityManagerNative完成通信过程；
2.AMS进程完成生命周期管理以及任务栈管理后，会把控制权交给App进程，让App进程完成Activity类对象的创建，以及生命周期回调；这个通信过程也是通过Binder完成的，App所在server端的Binder对象存在于ActivityThread的内部类ApplicationThread；AMS所在client通过持有IApplicationThread的代理对象完成对于App进程的通信。
App进程内部的ApplicationThread与App主线程并不在同一个线程内，他们通过Handler完成通信，这个Handler存在于ActivityThread类，它的名字很简单就叫H
ApplicationThread的scheduleLaunchActivity方法，正式包装了参数最终使用Handler发了一个消息。然后在ActivityThread中对消息进行处理
case LAUNCH_ACTIVITY: {Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");final ActivityClientRecord r = (ActivityClientRecord) msg.obj;r.packageInfo = getPackageInfoNoCheck(r.activityInfo.applicationInfo, r.compatInfo);handleLaunchActivity(r, null);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
直接调用了ActivityThread的handleLaunchActivity方法
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {//.....省略代码// Initialize before creating the activityWindowManagerGlobal.initialize();Activity a = performLaunchActivity(r, customIntent);
performLaunchActivity方法中主要做了两件事情
1.使用ClassLoader加载并通过反射创建Activity对象
try {java.lang.ClassLoader cl = r.packageInfo.getClassLoader();activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);StrictMode.incrementExpectedActivityCount(activity.getClass());r.intent.setExtrasClassLoader(cl);r.intent.prepareToEnterProcess();if (r.state != null) {r.state.setClassLoader(cl);}} catch (Exception e) {if (!mInstrumentation.onException(activity, e)) {throw new RuntimeException("Unable to instantiate activity " + component+ ": " + e.toString(), e);}}2.如果Application还没有创建，那么创建Application对象并回调相应的生命周期方法；
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
整个系统的Activity堆栈，Activity生命周期回调都是由AMS所在的系统进程system_server帮开发者完成的；Android的Framework层帮忙完成了诸如生命周期管理等繁琐复杂的过程，简化了应用层的开发。
启动插件中声明的Activity
通过上面的描述，相信你已经大致了解了Activity的启动过程，之前我们说过，启动插件中的Activity会遇到的问题是必须在清单文件中进行声明，我们也说了解决的思路是在AndroidManifest.xml里面声明一个替身Activity，然后在合适的时候把这个假的替换成我们真正需要启动的Activity
我们可以先启动一个已经在AndroidManifest.xml里面声明过的替身Activity，让这个Activity进入AMS进程接受检验；最后在换成我们真正需要启动的Activity；这样就成功欺骗了AMS进程
使用StubActivity绕过AMS
启动Activity的控制权转移到AMS进程之前，我们需要想办法临时把TargetActivity替换成替身StubActivity,我们来看一下Virtualapk里面是如何做的
1.代理系统Instrumentation
前面分析Activity的启动流程的时候，我们知道无论是通过Context还是Activity的startActivity方法最终都会经过Instrumentation
我们在Virtualapk中看到如下代码：
private void hookInstrumentationAndHandler() {try {Instrumentation baseInstrumentation = ReflectUtil.getInstrumentation(this.mContext);if (baseInstrumentation.getClass().getName().contains("lbe")) {// reject executing in paralell space, for example, lbe.System.exit(0);}final VAInstrumentation instrumentation = new VAInstrumentation(this, baseInstrumentation);Object activityThread = ReflectUtil.getActivityThread(this.mContext);ReflectUtil.setInstrumentation(activityThread, instrumentation);ReflectUtil.setHandlerCallback(this.mContext, instrumentation);this.mInstrumentation = instrumentation;} catch (Exception e) {e.printStackTrace();}}
首先通过反射获取了ActivityThread中的instrumentation,并通过
VAInstrumentation 类对系统的instrumentation进行了封装，我们来看一看VAInstrumentation 类里面到底做了什么，其实VAInstrumentation 就是系统instrumentation的一个代理，然后将这个VAInstrumentation 替换掉原来系统ActivityThread中的instrumentation，VAInstrumentation 里面重写了execStartActivity,realExecStartActivity等方法，为什么要重写这些方法？没关系，我们一个个来进行分析
首先是execStartActivity方法的分析
public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target,Intent intent, int requestCode, Bundle options) {mPluginManager.getComponentsHandler().transformIntentToExplicitAsNeeded(intent);// null component is an implicitly intentif (intent.getComponent() != null) {Log.i(TAG, String.format("execStartActivity[%s : %s]", intent.getComponent().getPackageName(),intent.getComponent().getClassName()));// resolve intent with Stub Activity if neededthis.mPluginManager.getComponentsHandler().markIntentIfNeeded(intent);}ActivityResult result = realExecStartActivity(who, contextThread, token, target,intent, requestCode, options);return result;}
execStartActivity方法主要做了以下这些事情：
1.将隐试启动插件里activity的意图转化为显示启动，因为在宿主通过隐式启动插件activity，是无法启动的，原因很简单，插件的activity并不在宿主apk中
mPluginManager.getComponentsHandler().transformIntentToExplicitAsNeeded(intent);
ComponentsHandler的transformIntentToExplicitAsNeeded做的就是这个事情，里面会通过mPluginManager.resolveActivity方法查找插件里面第一个符合隐式条件的第一个ResolveInfo，然后new component 设置进intent,大家可以追着代码进去看，这里不再贴出
public Intent transformIntentToExplicitAsNeeded(Intent intent) {ComponentName component = intent.getComponent();if (component == null) {ResolveInfo info = mPluginManager.resolveActivity(intent);if (info != null && info.activityInfo != null) {component = new ComponentName(info.activityInfo.packageName, info.activityInfo.name);intent.setComponent(component);}}return intent;}
2.临时把TargetActivity替换成替身StubActivity
我们前面说过，要进行偷梁换柱，而这个地方就是在execStartActivity的以下的代码中
if (intent.getComponent() != null) {Log.i(TAG, String.format("execStartActivity[%s : %s]", intent.getComponent().getPackageName(),intent.getComponent().getClassName()));// resolve intent with Stub Activity if neededthis.mPluginManager.getComponentsHandler().markIntentIfNeeded(intent);}可以发现，关键代码在markIntentIfNeeded方法中
//ComponentsHandler.java
public void markIntentIfNeeded(Intent intent) {if (intent.getComponent() == null) {return;}String targetPackageName = intent.getComponent().getPackageName();String targetClassName = intent.getComponent().getClassName();// search map and return specific launchmode stub activityif (!targetPackageName.equals(mContext.getPackageName()) && mPluginManager.getLoadedPlugin(targetPackageName) != null) {intent.putExtra(Constants.KEY_IS_PLUGIN, true);intent.putExtra(Constants.KEY_TARGET_PACKAGE, targetPackageName);intent.putExtra(Constants.KEY_TARGET_ACTIVITY, targetClassName);dispatchStubActivity(intent);}}
我们可以发现，会判断启动的Activity是不是插件里的，如果是，则将目标Activity的包名和TargetActivity的名字存储到intent中，接着通过dispatchStubActivity方法，根据要启动的TargetActivity是什么启动模式的来启动相应的代理StubActivity
private void dispatchStubActivity(Intent intent) {ComponentName component = intent.getComponent();String targetClassName = intent.getComponent().getClassName();LoadedPlugin loadedPlugin = mPluginManager.getLoadedPlugin(intent);ActivityInfo info = loadedPlugin.getActivityInfo(component);if (info == null) {throw new RuntimeException("can not find " + component);}int launchMode = info.launchMode;Resources.Theme themeObj = loadedPlugin.getResources().newTheme();themeObj.applyStyle(info.theme, true);String stubActivity = mStubActivityInfo.getStubActivity(targetClassName, launchMode, themeObj);Log.i(TAG, String.format("dispatchStubActivity,[%s -> %s]", targetClassName, stubActivity));intent.setClassName(mContext, stubActivity);}dispatchStubActivity方法里面会通过TargetActivity是什么启动模式的来获取相应的代理StubActivity的类名并设置进intent中，这里就完成了偷梁换柱的过程。
3.调用系统Instrumentation的execStartActivity方法，进入正常启动Activity的流程
ActivityResult result = realExecStartActivity(who, contextThread, token, target,intent, requestCode, options); private ActivityResult realExecStartActivity(Context who, IBinder contextThread, IBinder token, Activity target,Intent intent, int requestCode, Bundle options) {ActivityResult result = null;try {Class[] parameterTypes = {Context.class, IBinder.class, IBinder.class, Activity.class, Intent.class,int.class, Bundle.class};result = (ActivityResult)ReflectUtil.invoke(Instrumentation.class, mBase,"execStartActivity", parameterTypes,who, contextThread, token, target, intent, requestCode, options);} catch (Exception e) {e.printStackTrace();}return result;}
这里是通过反射调用系统Instrumentation的execStartActivity方法
通过这个替换过程，在ActivityManagerNative的startActivity调用之后，system_server端收到Binder驱动的消息，开始执行ActivityManagerService里面真正的startActivity方法；这时候AMS看到的intent参数里面的组件已经是StubActivity了，因此可以成功绕过检查
将StubActivity替换回TargetActivity
好了，接下来就是进行跨进程通信，system_server管理Activity的生命周期，之前我们用替身StubActivity临时换了TargetActivity，肯定需要在合适的时候替换回来，Virtualapk替换的回来的地方是哪里呢？
在AMS进程里面我们是没有办法换回来的，因此我们要等AMS把控制权交给App所在进程，还记得前面我们说ApplicationThread所在的Binder线程池通过Handler与ActivityThread进行通信么？
于是乎，我们是不是可以有一种思路，在这个Handler的handleMessage时做处理呢？我们简单看一下Handler的代码
public void dispatchMessage(Message msg) {if (msg.callback != null) {handleCallback(msg);} else {if (mCallback != null) {if (mCallback.handleMessage(msg)) {return;}}handleMessage(msg);}
}
Handler类消息分发的过程：
1.如果传递的Message本身就有callback，那么直接使用Message对象的callback方法；
2.如果Handler类的成员变量mCallback存在，那么首先执行这个mCallback回调；
3.如果mCallback的回调返回true，那么表示消息已经成功处理；直接结束。
4.如果mCallback的回调返回false，那么表示消息没有处理完毕，会继续使用Handler类的handleMessage方法处理消息。
ActivityThread中的Handler类H重载了handleMessage方法：
public void handleMessage(Message msg) {if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));switch (msg.what) {case LAUNCH_ACTIVITY: {Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");ActivityClientRecord r = (ActivityClientRecord)msg.obj;r.packageInfo = getPackageInfoNoCheck(r.activityInfo.applicationInfo, r.compatInfo);handleLaunchActivity(r, null);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);} break;case RELAUNCH_ACTIVITY: {Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityRestart");ActivityClientRecord r = (ActivityClientRecord)msg.obj;handleRelaunchActivity(r);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);// 省略一万行代码。。。。}
}
从dispathMessage方法中，我们可以得出思路：我们可以拦截这一过程：把这个H类的mCallback替换为我们的自定义实现，这样dispathMessage就会首先使用这个自定义的mCallback，然后看情况使用H重载的handleMessage。
这个Handler.Callback是一个接口，我们可以使用动态代理或者普通代理完成Hook，在Virtualapk中使用普通的静态代理方式，还记得前面的VAInstrumentation类么？它不仅继承了系统的Instrumentation，同时还实现了 Handler.Callback 接口
再次贴出前面PluginManager初始化的时候hookInstrumentationAndHandler的代码
private void hookInstrumentationAndHandler() {try {Instrumentation baseInstrumentation = ReflectUtil.getInstrumentation(this.mContext);if (baseInstrumentation.getClass().getName().contains("lbe")) {// reject executing in paralell space, for example, lbe.System.exit(0);}final VAInstrumentation instrumentation = new VAInstrumentation(this, baseInstrumentation);Object activityThread = ReflectUtil.getActivityThread(this.mContext);ReflectUtil.setInstrumentation(activityThread, instrumentation);ReflectUtil.setHandlerCallback(this.mContext, instrumentation);this.mInstrumentation = instrumentation;} catch (Exception e) {e.printStackTrace();}}
可以很明显的发现setHandlerCallback方法中对Callback进行了处理
public static void setHandlerCallback(Context base, Handler.Callback callback) {try {Object activityThread = getActivityThread(base);Handler mainHandler = (Handler) ReflectUtil.invoke(activityThread.getClass(), activityThread, "getHandler", (Object[])null);ReflectUtil.setField(Handler.class, mainHandler, "mCallback", callback);} catch (Exception e) {e.printStackTrace();}}
果不其然，替换了ActivityThread中的Handler的mCallback为VAInstrumentation ，所以当ActivityThread的H进行dispathMessage的时候，必定会走到VAInstrumentation 的handleMessage方法
//VAInstrumentation.java@Overridepublic boolean handleMessage(Message msg) {if (msg.what == LAUNCH_ACTIVITY) {// ActivityClientRecord rObject r = msg.obj;try {Intent intent = (Intent) ReflectUtil.getField(r.getClass(), r, "intent");intent.setExtrasClassLoader(VAInstrumentation.class.getClassLoader());ActivityInfo activityInfo = (ActivityInfo) ReflectUtil.getField(r.getClass(), r, "activityInfo");if (PluginUtil.isIntentFromPlugin(intent)) {int theme = PluginUtil.getTheme(mPluginManager.getHostContext(), intent);if (theme != 0) {Log.i(TAG, "resolve theme, current theme:" + activityInfo.theme + " after :0x" + Integer.toHexString(theme));activityInfo.theme = theme;}}} catch (Exception e) {e.printStackTrace();}}return false;}
可以看到在VAInstrumentation 的handleMessage方法只是拦截了LAUNCH_ACTIVITY的处理，在里面将intent中的activityInfo.theme替换为插件的theme，并给intent设置了ClassLoader,这里为什么要设置一个ClassLoader？我想是因为在ActivityThread的performLaunchActivity方法会将其取出，然后设置进mInstrumentation.newActivity方法中
//ActivityThread.javaActivity activity = null;try {java.lang.ClassLoader cl = r.packageInfo.getClassLoader();activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);StrictMode.incrementExpectedActivityCount(activity.getClass());r.intent.setExtrasClassLoader(cl);r.intent.prepareToEnterProcess();if (r.state != null) {r.state.setClassLoader(cl);}}
经过上面的调用，又会进入到VAInstrumentation 的newActivity
@Overridepublic Activity newActivity(ClassLoader cl, String className, Intent intent) throws InstantiationException, IllegalAccessException, ClassNotFoundException {try {cl.loadClass(className);} catch (ClassNotFoundException e) {LoadedPlugin plugin = this.mPluginManager.getLoadedPlugin(intent);String targetClassName = PluginUtil.getTargetActivity(intent);Log.i(TAG, String.format("newActivity[%s : %s]", className, targetClassName));if (targetClassName != null) {Activity activity = mBase.newActivity(plugin.getClassLoader(), targetClassName, intent);activity.setIntent(intent);try {// for 4.1+ReflectUtil.setField(ContextThemeWrapper.class, activity, "mResources", plugin.getResources());} catch (Exception ignored) {// ignored.}return activity;}}return mBase.newActivity(cl, className, intent);}
首先是cl.loadClass(className)，注意，我使用的demo,这里的className为com.didi.virtualapk.core.A$1，还有可能是其他的，但都会是在清单文件声明的stubActivity的名字
调用cl.loadClass(className)去加载这些类，肯定是会爆出ClassNotFoundException异常的，因为这些类并不存在，他们只是在清单文件中起到占坑的作用，用来欺骗系统的，这里的设计确实非常巧妙，接下来自然走到catch里，catch里自然是去构建真正需要加载的TargetActivity
Activity activity = mBase.newActivity(plugin.getClassLoader(), targetClassName, intent);activity.setIntent(intent);
传入newActivity方法的是LoadedPlugin中的ClassLoader，这个ClassLoader已经是修改过的，可以加载插件和宿主里的类，关羽ClassLoader不懂的，可以看《Android插件化学习之路（二）之ClassLoader完全解析》
然后将intent设置进插件Activity 中，注意，这里的intent里的className还是com.didi.virtualapk.core.A$1
接下来会调用到ActivityThread中的performLaunchActivity 中的如下代码
if (r.isPersistable()) {mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);} else {mInstrumentation.callActivityOnCreate(activity, r.state);}
然后又进入到VAInstrumentation 的callActivityOnCreate方法中
public void callActivityOnCreate(Activity activity, Bundle icicle) {final Intent intent = activity.getIntent();if (PluginUtil.isIntentFromPlugin(intent)) {Context base = activity.getBaseContext();try {LoadedPlugin plugin = this.mPluginManager.getLoadedPlugin(intent);ReflectUtil.setField(base.getClass(), base, "mResources", plugin.getResources());ReflectUtil.setField(ContextWrapper.class, activity, "mBase", plugin.getPluginContext());ReflectUtil.setField(Activity.class, activity, "mApplication", plugin.getApplication());ReflectUtil.setFieldNoException(ContextThemeWrapper.class, activity, "mBase", plugin.getPluginContext());// set screenOrientationActivityInfo activityInfo = plugin.getActivityInfo(PluginUtil.getComponent(intent));if (activityInfo.screenOrientation != ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED) {activity.setRequestedOrientation(activityInfo.screenOrientation);}} catch (Exception e) {e.printStackTrace();}}mBase.callActivityOnCreate(activity, icicle);}
最后这里就是进行一些替换的工作了，替换掉TargetActivity里的mResources，mBase，mApplication为LoadedPlugin中生成的可以用于加载插件资源的相应Resources和Context,为什么要进行这些替换工作？后续文章会进行详细讲解，最后就是调用系统Instrumentation的callActivityOnCreate其启动这个插件TargetActivity了，我们可以发现，到最后intent里的className还是com.didi.virtualapk.core.A$1，这是因为这个intent只是用来欺骗系统的作用
public void callActivityOnCreate(Activity activity, Bundle icicle,PersistableBundle persistentState) {prePerformCreate(activity);activity.performCreate(icicle, persistentState);postPerformCreate(activity);}
可以看见，接下来就是调用插件Activity的onCreate方法了，就完了加载插件Activity的过程
你可能会问通过上面的方式启动的插件TargetActivity就具有生命周期了吗？答案是肯定的，大家可以通过demo去验证这一点，我们以onDestroy为例分析一下这个过程：
Activity的finish方法最终会通过ActivityManagerNative到AMS然后接着通过ApplicationThread到ActivityThread，然后通过H转发消息到ActivityThread的handleDestroyActivity，接着这个方法把任务交给performDestroyActivity完成。
performDestroyActivity，关键代码如下：
ActivityClientRecord r = mActivities.get(token);// ......mInstrumentation.callActivityOnDestroy(r.activity);通过mActivities拿到了一个ActivityClientRecord，然后直接把这个record里面的Activity交给Instrument类完成了onDestroy的调用。
这里的r.activity是StubActivity为什么它能正确完成对TargetActivity生命周期的回调呢？
答案是token。AMS与ActivityThread之间对于Activity的生命周期的交互，并没有直接使用Activity对象进行交互，而是使用一个token来标识，这个token是binder对象，因此可以方便地跨进程传递。Activity里面有一个成员变量mToken代表的就是它，token可以唯一地标识一个Activity对象，它在Activity的attach方法里面初始化；
在AMS处理Activity的任务栈的时候，使用这个token标记Activity，因此在demo里面，AMS进程里面的token对应的是StubActivity，但是在App进程里面，token对应的却是TargetActivity！因此，在ActivityThread执行回调的时候，能正确地回调到TargetActivity相应的方法。
为什么App进程里面，token对应的是TargetActivity呢？
ActivityClientRecord是在mActivities里面取出来的，确实是根据token取；那么这个token是什么时候添加进去的呢？我们看performLaunchActivity就完成明白了：它通过classloader加载了TargetActivity，然后完成一切操作之后把这个activity添加进了mActivities！另外，在这个方法里面我们还能看到对Ativity.attach方法的调用，它传递给了新创建的Activity一个token对象，而这个token是在ActivityClientRecord构造函数里面初始化的。
至此，整个Virtualapk框架对于插件Activity的管理就到此结束了，接下来还会继续分析其他组件的原理，最后，如果小弟有分析偏差的地方，欢迎矫正。
这篇关于滴滴插件化框架VirtualAPK原理解析（一）之插件Activity管理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
