阿里P7移动互联网架构师进阶视频（每日更新中）免费学习请点击：https://space.bilibili.com/474380680
本文通过Activity调用原理来解读Replugin插件化技术
一、开启插件Activity流程
第1步
开启插件Activity的入口在Replugin.StartActivity(Context context, Intent intent)，其他intent内部一定要传入想要开启的插件名。
public static boolean startActivity(Context context, Intent intent) {
// TODO 先用旧的开启Activity方案，以后再优化
ComponentName cn = intent.getComponent();
if (cn == null) {
// TODO 需要支持Action方案
return false;
}
String plugin = cn.getPackageName();
String cls = cn.getClassName();
return Factory.startActivityWithNoInjectCN(context, intent, plugin, cls, IPluginManager.PROCESS_AUTO);
}
Factory.startActivityWithNoInjectCN内部调用sPluginManager.startActivity方法，那么sPluginManager是哪里传进去的？
PMF.java
Factory.sPluginManager = PMF.getLocal();
Factory2.sPluginManager = PMF.getInternal();
看下PMF.init的方法可以看到sPluginManager是PMF内部维护的sPluginMgr.mLocal，也就是Pmbase内部的PmLocalmpl mLocal对象，继续跟踪发现真正实现startActivity逻辑的是PmBase内部的PmInternalmpl.startActivity下面这个方法。
public boolean startActivity(Context context, Intent intent, String plugin, String activity, int process, boolean download) {
。。。
}
第2步
重点走读下上面startActivity方法，首先会判断要跳转的插件是否已经存在了，如果不存在则回调callback接口去提示用户下载等逻辑操作，如果插件状态不正确，则回调外部callback去提示用户插件不可用或者去升级，如果插件首次加载并且是大插件则异步加载并弹窗显示正在加载。然后在调用context.startActivity方法前会去通过下面的loadPluginActivity方法将目标插件Activity class替换为“坑位”Activity，这样其实传给AMS的还是宿主的坑位Activity。
PmInternalmpl.java
public boolean startActivity(Context context, Intent intent, String plugin, String activity, int process, boolean download) {
if (LOG) {
LogDebug.d(PLUGIN_TAG, "start activity: intent=" + intent + " plugin=" + plugin + " activity=" + activity + " process=" + process + " download=" + download);
}
// 1. 是否启动下载
// 若插件不可用（不存在或版本不匹配），则直接弹出“下载插件”对话框
// 因为已经打开UpdateActivity，故在这里返回True，告诉外界已经打开，无需处理
if (download) {
if (PluginTable.getPluginInfo(plugin) == null) {
if (LOG) {
LogDebug.d(PLUGIN_TAG, "plugin=" + plugin + " not found, start download ...");
}
// 如果用户在下载即将完成时突然点按“取消”，则有可能出现插件已下载成功，但没有及时加载进来的情况
// 因此我们会判断这种情况，如果是，则重新加载一次即可，反之则提示用户下载
// 原因：“取消”会触发Task.release方法，最终调用mDownloadTask.destroy，导致“下载服务”的Receiver被注销，即使文件下载了也没有回调回来
// NOTE isNeedToDownload方法会调用pluginDownloaded再次尝试加载
if (isNeedToDownload(context, plugin)) {
return RePlugin.getConfig().getCallbacks().onPluginNotExistsForActivity(context, plugin, intent, process);
}
}
}
...
// 2. 如果插件状态出现问题，则每次弹此插件的Activity都应提示无法使用，或提示升级（如有新版）
// Added by Jiongxuan Zhang
if (PluginStatusController.getStatus(plugin) < PluginStatusController.STATUS_OK) {
if (LOG) {
LogDebug.d(PLUGIN_TAG, "PmInternalImpl.startActivity(): Plugin Disabled. pn=" + plugin);
}
return RePlugin.getConfig().getCallbacks().onPluginNotExistsForActivity(context, plugin, intent, process);
}
// 3. 若为首次加载插件，且是“大插件”，则应异步加载，同时弹窗提示“加载中”
// Added by Jiongxuan Zhang
if (!RePlugin.isPluginDexExtracted(plugin)) {
PluginDesc pd = PluginDesc.get(plugin);
if (pd != null && pd.isLarge()) {
...
return RePlugin.getConfig().getCallbacks().onLoadLargePluginForActivity(context, plugin, intent, process);
}
}
// WARNING：千万不要修改intent内容，尤其不要修改其ComponentName
// 因为一旦分配坑位有误（或压根不是插件Activity），则外界还需要原封不动的startActivity到系统中
// 可防止出现“本来要打开宿主，结果被改成插件”，进而无法打开宿主Activity的问题
// 缓存打开前的Intent对象，里面将包括Action等内容
Intent from = new Intent(intent);
// 帮助填写打开前的Intent的ComponentName信息（如有。没有的情况如直接通过Action打开等）
if (!TextUtils.isEmpty(plugin) && !TextUtils.isEmpty(activity)) {
from.setComponent(new ComponentName(plugin, activity));
}
//4. 会去将目标Activity替换为坑位Activity
ComponentName cn = mPluginMgr.mLocal.loadPluginActivity(intent, plugin, activity, process);
if (cn == null) {
if (LOG) {
LogDebug.d(PLUGIN_TAG, "plugin cn not found: intent=" + intent + " plugin=" + plugin + " activity=" + activity + " process=" + process);
}
return false;
}
// 将Intent指向到“坑位”。这样：
// from：插件原Intent
// to：坑位Intent
intent.setComponent(cn);
//5. 调用系统startActivity方法
context.startActivity(intent);
// 6. 通知外界，已准备好要打开Activity了
// 其中：from为要打开的插件的Intent，to为坑位Intent
RePlugin.getConfig().getEventCallbacks().onPrepareStartPitActivity(context, from, intent);
return true;
}
坑位Activity的替换规格，逻辑是在PmLocalmpl.allocActivityContainer方法中执行，这个有兴趣的可以自己去跟踪下，坑位Activity替换规格，这里就不深入去分析了。
第3步
上述几步使用坑位Activity来替换目标Activity之后，AMS内部都是基于这个坑位Activity来实现对其合法性、生命周期进行回调啦，AMS一系列流程走完，然后AMS再通过宿主进程的ActivityThread提供的IApplicationThread Binder代理对象去实现宿主进程中类加载坑位Activity啦，并对其回调相关接口如onCreate。正常startActivity是这样没错，但是我们明明是希望调用的宿主的Activity啊，又不是坑位Activity？是的这里需要对坑位Activity进行恢复真身处理，恢复为目标插件Activity。在哪里恢复呢？没错，就是在我们唯一hook点：RePluginClassLoader中。
我们在《Replugin插件化技术解读之框架初始化、插件安装与加载（二）》一文中已经分析的很明白，从RePluginClassLoader的loadClass方法中会首先去使用PMF.loadClass去加载插件，去生成插件的Loader对象，
初始化好插件的DexClassLoader、Resource、PluginContext等资源，然后用插件的ClassLoader去尝试加载目标Activity。具体执行逻辑在PluginProcessPer.resolveActivityClass方法中。
/**
* 类加载器根据容器解析到目标的activity
* @param container
* @return
*/
final Class<?> resolveActivityClass(String container) {
String plugin = null;
String activity = null;
// 先找登记的，如果找不到，则用forward activity
PluginContainers.ActivityState state = mACM.lookupByContainer(container);
if (state == null) {
// PACM: loadActivityClass, not register, use forward activity, container=
if (LOGR) {
LogRelease.w(PLUGIN_TAG, "use f.a, c=" + container);
}
return ForwardActivity.class;
}
plugin = state.plugin;
activity = state.activity;
Plugin p = mPluginMgr.loadAppPlugin(plugin);
if (p == null) {
return null;
}
ClassLoader cl = p.getClassLoader();
if (LOG) {
Class<?> c = null;
try {
c = cl.loadClass(activity);
} catch (Throwable e) {
if (LOGR) {
LogRelease.e(PLUGIN_TAG, e.getMessage(), e);
}
}
return c;
}
这样我们插件目标Activity就恢复成功，目标Activity内部逻辑就能正常执行啦。
总结：
开启插件Activity的大致流程为：
插件Activity -> Replugin.startActivity -> 解析出插件Activity对应的pluginName -> 挑选坑位Activity替换 ->调用系统startActivity方法 -> AMS回调执行坑位Activity类加载 ->加载并初始化目标插件资源、上下文、类加载器(首次) ->Hook掉ClassLoader的类加载中恢复为插件Activity -> 插件Activity启动，并拥有完整生命周期。
二、插件内部startActivity流程
插件中startActiviy有两种场景：调用自己插件本身的Activity或者调用宿主的Activity。显然光凭插件自己是无法成功开启的。因为插件的Manifest根本就没有被AMS识别到呀，必须还是要用统一的Replugin.startActivity接口去按照上述分析的流程重走一遍才行的啊。
在《Replugin插件化技术解读之目录结构解读》一文中，我们了解到其实插件在动态编译过程中会在字节码层做适量修改，如插件的所有Activity都会被继承replugin-plugin-lib中的PluginActivity这样一个基类。所以我们插件内部其实Activity内部最后执行startActivity都会先走PluginActivity的此方法；
PluginActivity.java
static void initLocked(final ClassLoader classLoader) {
final String factory2 = "com.qihoo360.i.Factory2";
final String factory = "com.qihoo360.i.Factory";
// 初始化Factory2相关方法
createActivityContext = new MethodInvoker(classLoader, factory2, "createActivityContext", new Class<?>[]{Activity.class, Context.class});
handleActivityCreateBefore = new MethodInvoker(classLoader, factory2, "handleActivityCreateBefore", new Class<?>[]{Activity.class, Bundle.class});
handleActivityCreate = new MethodInvoker(classLoader, factory2, "handleActivityCreate", new Class<?>[]{Activity.class, Bundle.class});
handleActivityDestroy = new MethodInvoker(classLoader, factory2, "handleActivityDestroy", new Class<?>[]{Activity.class});
handleRestoreInstanceState = new MethodInvoker(classLoader, factory2, "handleRestoreInstanceState", new Class<?>[]{Activity.class, Bundle.class});
startActivity = new MethodInvoker(classLoader, factory2, "startActivity", new Class<?>[]{Activity.class, Intent.class});
startActivityForResult = new MethodInvoker(classLoader, factory2, "startActivityForResult", new Class<?>[]{Activity.class, Intent.class, int.class, Bundle.class});
// 初始化Factory相关方法
loadPluginActivity = new MethodInvoker(classLoader, factory, "loadPluginActivity", new Class<?>[]{Intent.class, String.class, String.class, int.class});
显然，反射的是Factory2中的startActivity方法，而Factory.startActivity其实就是调用的PmInternalmpl.startActivity方法，显然这个跟上面宿主启动插件Activity对上啦。
那么RepluginInternal.initLocked方法是什么时候走的呢？容易看到是在RepluginFramework.init中调用，而RepluginFramework.init初始化时在Entry的create方法中，这里是不是很熟悉啦。没错，在《Replugin插件化技术解读之框架初始化、插件安装与加载（二）》一文中我们知道在加载插件的时候会通过回调执行插件的Entry的create方法初始化插件，显然这里这条线又连上啦。
这样插件内部启动startActivity说白了就是通过反射调用宿主Factory2中startActivity方法去重走了遍上述分析的标准启动插件Activity流程。注意，这里其实仅仅是通过插件Activity继承PluginActivity重写了Activity内部StartActivity方法，改变了Activity内startActivity方法启动步骤。
我们显然还要修改Context上下文对应的startActivity方法才能保证这里调用的时候也会走到我们设定好的宿主startActivityq启动流程，
那么插件内部其他startActivity的地方都要进行这样的调整才行，这个就大家自己跟下就能明白了，原理差不多。
public abstract class PluginActivity extends Activity {
@Override
protected void attachBaseContext(Context newBase) {
newBase = RePluginInternal.createActivityContext(this, newBase);
super.attachBaseContext(newBase);
}
PluginActivity的attachBaseContext方法中我们会使用RepluginInternal.createActivityContext方法，通过反射，最终吊起来PmInternalImpl.createActivityContext方法。创建对应插件的PluginContext对象，PluginContext前文已经介绍，然后用这个PluginContext替换掉插件内部的上下文BaseContext，其实也就是Activity继承的ContextWrapper类的Context mBase对象。跟踪Android源码很容易发现，ContextWrapper内部封装了startActivity startService等方法，所以这里我们要将这个Context替换掉。那么PluginContext内部又做了什么呢？显然它也重写了startActivity方法。
@Override
public void startActivity(Intent intent) {
if (mContextInjector != null) {
mContextInjector.startActivityBefore(intent);
}
super.startActivity(intent);
if (mContextInjector != null) {
mContextInjector.startActivityAfter(intent);
}
}
这里 super.startActivity其实就是对应宿主上下文了，直接走宿主startActivity流程。
其他还有在PluginApplicationClient为插件创建的Application对象，在PluginApplicationClient.callAttachBaseContext方法中使用反射调用了Application.attachf方法，用PluginContext对象替换了原来的Context，这个就各位看官自己去梳理了哈。
原文链接https://blog.csdn.net/hellogmm/article/details/79058135
阿里P7移动互联网架构师进阶视频（每日更新中）免费学习请点击：https://space.bilibili.com/474380680