Replugin|Replugin 全面解析 (2) Replugin全面解析(2)

Activity作为四大组件中最重要的组件，在Replugin中对它的支持的架构设计也是最复杂的，所以本篇分析我们就来看看Activity的启动流程。
以下这张图简要的画出类Activity启动的过程，当然简化了一些流程：

Pmbase根据Intent找到对应的插件
分配坑位Activity，与插件中的Activity建立一对一的关系并保存在PluginContainer中
让系统启动坑位Activity，因为它是在Manifest中注册过的
Android系统会尝试使用RepluginClassLoader加载坑位Activity的Class对象
RepluginClassLoader 通过建立的对应关系找到插件Activity，并使用PluginDexClassLoader 加载插件Activity 的Class对象并返回
Android系统就使用这个插件中的Activity的Class对象来运行生命周期函数

Android系统就是这样被欺骗了！

文章图片
activity.jpg
启动一个Activity的入口函数是 Replugin.startActivity()，然后调用 Factory.startActivityWithNoInjectCN，再经过 PluginCommImpl.startActivivty()，最终来到 PluginLibraryInternalProxy.startActivity()，这里将是真正开始工作的地方，会分为以下几个步骤：

如果有必要，需要先下载插件
下载过程会通过回调让用户去实现，比如显示进度，安装等。

if (download) { if (PluginTable.getPluginInfo(plugin) == null) { if (isNeedToDownload(context, plugin)) { return RePlugin.getConfig().getCallbacks().onPluginNotExistsForActivity(context, plugin, intent, process); } } }

检查插件状态
如果插件状态不正确，或者首次加载大插件，会通过回调让用户处理，用户可以可以在回调里定制自己的行为，比如弹出提示框，加载进度条等。

if (PluginStatusController.getStatus(plugin) < PluginStatusController.STATUS_OK) { return RePlugin.getConfig().getCallbacks().onPluginNotExistsForActivity(context, plugin, intent, process); }if (!RePlugin.isPluginDexExtracted(plugin)) { PluginDesc pd = PluginDesc.get(plugin); if (pd != null && pd.isLarge()) { return RePlugin.getConfig().getCallbacks().onLoadLargePluginForActivity(context, plugin, intent, process); } }

【Replugin|Replugin 全面解析 (2)】寻找坑位，启动坑位Activity
调用在PluginLibraryInternalProxy.startActivity()中调用PluginCommImpl.loadPluginActivity来寻找坑位Activity。

请注意注释中的分支C，如果是第一次去获取信息，会首先去加载插件的Dex文件以及资源等，并创建PluginDexClassLoader。这个分支我们在后面来讲解。

public ComponentName loadPluginActivity(Intent intent, String plugin, String activity, int process) { ActivityInfo ai = null; String container = null; PluginBinderInfo info = new PluginBinderInfo(PluginBinderInfo.ACTIVITY_REQUEST); try { ai = getActivityInfo(plugin, activity, intent); //分支C:获取 ActivityInfo // 根据 activity 的 processName，选择进程 ID 标识 if (ai.processName != null) { process = PluginClientHelper.getProcessInt(ai.processName); } // 容器选择（启动目标进程，如果有必要的话，一般默认会使用UI进程） IPluginClient client = MP.startPluginProcess(plugin, process, info); ...... // 远程分配坑位 container = client.allocActivityContainer(plugin, process, ai.name, intent); } catch (Throwable e) { }PmBase.cleanIntentPluginParams(intent); ...... return new ComponentName(IPC.getPackageName(), container); }

来重点看看坑位分配，这是一个远程调用，调用了Persistent进程中的PluginProcessPer.allocActivityContainer函数，进一步调用bindActivity函数。

final String bindActivity(String plugin, int process, String activity, Intent intent) { Plugin p = mPluginMgr.loadAppPlugin(plugin); //获取插件对象 ...... ActivityInfo ai = p.mLoader.mComponents.getActivity(activity); //获取ActivityInfo ...... String container; // 自定义进程 if (ai.processName.contains(PluginProcessHost.PROCESS_PLUGIN_SUFFIX2)) { String processTail = PluginProcessHost.processTail(ai.processName); container = mACM.alloc2(ai, plugin, activity, process, intent, processTail); } else { container = mACM.alloc(ai, plugin, activity, process, intent); } ...... return container; }

这里mACM.alloc2调用allocLocked函数真正的执行了坑位分配的任务。这段代码简单明了，注意坑位找好以后会返回一个AcitivtyState对象，这里面保存了坑位Activity和真实要启动的Activity之间的对应关系。并且这个对应关系会被保存起来，在RepluginClassLoader在加载类的时候会被拿出来使用，以获取要运行的Activity的class对象。

private final ActivityState allocLocked(ActivityInfo ai, HashMap map, String plugin, String activity, Intent intent) { // 首先找上一个活的，或者已经注册的，避免多个坑到同一个activity的映射 for (ActivityState state : map.values()) { if (state.isTarget(plugin, activity)) { return state; } } // 新分配：找空白的，第一个 for (ActivityState state : map.values()) { if (state.state == STATE_NONE) { state.occupy(plugin, activity); return state; } } ActivityState found; // 重用：则找最老的那个 found = null; for (ActivityState state : map.values()) { if (!state.hasRef()) { if (found == null) { found = state; } else if (state.timestamp < found.timestamp) { found = state; } } } if (found != null) { found.occupy(plugin, activity); return found; } // 强挤：最后一招，挤掉：最老的那个 found = null; for (ActivityState state : map.values()) { if (found == null) { found = state; } else if (state.timestamp < found.timestamp) { found = state; } } if (found != null) { found.finishRefs(); found.occupy(plugin, activity); return found; } return null; }

坑位找到啦！PluginLibraryInternalProxy.startActivity()中开始启动坑位Activity，就在分支D的位置，这个分支我们稍微延后一点来展开。

public boolean startActivity(Context context, Intent intent, String plugin, String activity, int process, boolean download) { ...... ComponentName cn = mPluginMgr.mLocal.loadPluginActivity(intent, plugin, activity, process); // 找到坑位组件 ...... // 将Intent指向到“坑位” intent.setComponent(cn); ...... context.startActivity(intent); //分支D: 启动坑位Activityreturn true; }

看到这里你一定会疑惑，难道这样插件的Activity就启动起来啦吗？这启动的明明就是一个坑位Activity啊？别着急，接着就是前面一直强调的唯一hook点发挥作用的时候啦！！
Dex的加载以及Activity的加载启动
上面有一个分支C你还记得吗？我们将它与Activity的加载流程放在一起来讲，因为这两者是紧密相关的。
先来看分支C。
- PluginCommImpl.getActivityInfo调用PmBase.loadAppPlugin获取插件对象，从下面注释的分支可以看出，Replugin 是支持使用 IntentFilter 来启动组件的，完美支持原生特性，是不是很赞！
  
  public ActivityInfo getActivityInfo(String plugin, String activity, Intent intent){ Plugin p = mPluginMgr.loadAppPlugin(plugin); //获取插件对象 ...... ActivityInfo ai = null; //activity 不为空时，从插件声明的 Activity 集合中查找 if (!TextUtils.isEmpty(activity)) { ai = p.mLoader.mComponents.getActivity(activity); } else { //activity 为空时，根据 Intent 匹配 ai = IntentMatcherHelper.getActivityInfo(mContext, plugin, intent); } return ai; }
- PmBase.loadAppPlugin会最终调用Plugin.loadLocked()函数，这个函数有两个参数，第一个是加载类型，一共有四种加载类型，在这里使用的是Plugin.LOAD_APP，因为运行插件需要所有的东西。第二个参数是是否使用缓存，通常情况下我们会现在缓存中查找插件信息，这样会更快。只是如果大量插件加载到内存会不会占用太多的内存，感兴趣的同学可以自己研究研究。
  这里如果第一次加载失败，Replugin还会做一次重试，相关代码几乎相同，这里就省略了。
  
  private boolean loadLocked(int load, boolean useCache) { // 这里先处理一下，如果cache命中，省了后面插件提取（如释放Jar包等）操作，直接返回缓存数据 if (useCache) { boolean result = loadByCache(load); if (result) { return true; } } ...... boolean rc = doLoad(logTag, context, parent, manager, load); // 真正的加载if (rc) { try { // 至此，该插件已开始运行 PluginManagerProxy.addToRunningPluginsNoThrows(mInfo.getName()); } catch (Throwable e) { } return true; } ...... File odex = mInfo.getDexFile(); if (odex.exists()) { odex.delete(); } rc = doLoad(logTag, context, parent, manager, load); ...... return true; }
- Plugin.doLoad()当然就是来加载插件的Dex文件，资源，以及so文件等等。
  
  private final boolean doLoad(String tag, Context context, ClassLoader parent, PluginCommImpl manager, int load) { if (mLoader == null) { // 中间省略这一段代码是释放so文件，请自行阅读代码，代码清晰简单 ...... // 加载Dex，获取组件信息 mLoader = new Loader(context, mInfo.getName(), mInfo.getPath(), this); if (!mLoader.loadDex(parent, load)) { return false; } // 在Persistent进程中更新插件信息，设置插件为“使用过的” try { PluginManagerProxy.updateUsedIfNeeded(mInfo.getName(), true); } catch (RemoteException e) { }// 若需要加载Dex，则还同时需要初始化插件里的Entry对象 if (load == LOAD_APP) { // NOTE Entry对象是可以在任何线程中被调用到 if (!loadEntryLocked(manager)) { return false; } } } }
- Loader.loadDex函数会获取Dex中的组件的信息，包括Manifest中的组件属性，比如进程属性，TaskAffinity属性，注册静态广播等等。但这里值得重点强调的是之前核心概念里提及的PluginDexClassLoader终于出现并被初始化了。
  
  final boolean loadDex(ClassLoader parent, int load) { try { ......// 这里省略了一些基本的加载动作 mClassLoader = Plugin.queryCachedClassLoader(mPath); if (mClassLoader == null) { ...... mClassLoader = RePlugin.getConfig().getCallbacks().createPluginClassLoader(mPath, out, soDir, parent); //创建PluginDexClassLoader ...... } ...... mPkgContext = new PluginContext(mContext, android.R.style.Theme, mClassLoader, mPkgResources, mPluginName, this); // 创建插件的Context对象 } catch (Throwable e) { return false; }return true; }
  
  到此为止，插件Dex的加载算是全部完成，下面还剩最后一步，我们的插件就算真正的启动运行起来了。
- 这里我们要接着前面启动坑位Activity的地方接着讲，要启动Activity首先要去加载对应的类，系统会调用Classloader的loadClass方法，这里就是调用Replugin提供的替代者RepluginClassLoader的方法。接着又会调用PMF.loadClass，其实就是调用Pmbase.loadClass
  
  protected Class loadClass(String className, boolean resolve) throws ClassNotFoundException { Class c = null; c = PMF.loadClass(className, resolve); if (c != null) { return c; } try { c = mOrig.loadClass(className); // 如果上面没有找到，那就在Host当中找 return c; } catch (Throwable e) { } return super.loadClass(className, resolve); }
- PmBase.loadClass看起来代码很多，对于Activity来说，其实我们只需要关注下面这一小段即可，mClient是PluginProcessPer的实例，而PluginProcessPer是IPluginClient的实现类。
  
  final Class loadClass(String className, boolean resolve) { ...... if (mContainerActivities.contains(className)) { Class c = mClient.resolveActivityClass(className); if (c != null) { return c; } ...... } ...... }
- 这里先从PluginContainers的实例对象mACM中去查找ActivityState，对这个类还有印象吗？它就是在分配坑位的时候，我们用来保存坑位组件与真实组件对应关系的类。然后在缓存中找到插件名对应的插件对象，因为在分配坑位的时候插件信息已经加载过了，不需要重新加载。接着取出插件的ClassLoader对象，这个对象正是加载插件时创建的PuginDexClassLoader的实例了。然后利用插件的PuginDexClassLoader对象来加载真实Activity的class对象。
  
  final Class resolveActivityClass(String container) { String plugin = null; String activity = null; // 找到坑位Activity与真实Activity的对应关系对象 PluginContainers.ActivityState state = mACM.lookupByContainer(container); ...... plugin = state.plugin; activity = state.activity; ...... Plugin p = mPluginMgr.loadAppPlugin(plugin); //通过插件名从缓存中加载Plugin对象 ...... ClassLoader cl = p.getClassLoader(); Class c = null; try { c = cl.loadClass(activity); } catch (Throwable e) { } return c; }
  
  找到插件Activity的类对象后，Android系统就开始运行Activity的启动流程了，这些事情由ActivityManagerService和ActivityThread负责。就这样，Replugin用插件中的Activity替换了坑位Activity，我们的插件被运行起来啦！！很巧妙的设计～

小结
以上的内容就是一个插件Activity要运行起来，Replugin的基本代码流程，这里要说明一下，源码中的逻辑远不止这么点，如果你有兴趣可以跟着这篇文章在源码中过一遍，有很多不是那么复杂的逻辑这里并没有讲到，当然也有一些重要的地方因为代码并不复杂也没有讲到。
下一篇Replugin 全面解析（3）会对插件的加载和运行做更完整和详细的讲解！