replugin原理笔记

Replugin源码目录主要有4个工程组成，其组成如下图所示，包括2个gradle工程，2个Android library工程。

replugin-host-gradle
replugin-host-library
replugin-plugin-gradle
replugin-plugin-library
Replugin是一套完整的、稳定的、适合全面使用的，占坑类插件化方案。Replugin的hook点只有一处，确保了框架的兼容性、稳定性。使用Replugin宿主和插件都需引入其gradle插件，但是宿主、插件的改造接入都非常简便。

1 宿主的改造

replugin-host-gradle，宿主工程构建时需要依赖的gradle插件，主要作用是进行宿主应用的构建任务，生成带插件坑位的AndroidManifest.xml，插件坑位可在宿主工程的gradle文件的repluginHostConfig中进行配置。以及生成包含插件信息的plugins-builtin.json文件。其主要任务包括：
生成带 RePlugin 插件坑位的 AndroidManifest.xml（允许自定义数量）
生成 RepluginHostConfig 类，方便插件框架读取并自定义其属性
生成 plugins-builtin.json，json中含有插件应用的信息，包名，插件名，插件路径等。
主要实现在RePlugin.groovy的apply方法中：

public void apply(Project project) {
···
def appID = variant.generateBuildConfig.appPackageName
def newManifest = ComponentsGenerator.generateComponent(appID, config)
···
//json generate task
def generateBuiltinJsonTaskName = scope.getTaskName(AppConstant.TASK_GENERATE, "BuiltinJson")
def generateBuiltinJsonTask = project.task(generateBuiltinJsonTaskName)generateBuiltinJsonTask.doLast {FileCreators.createBuiltinJson(project, variant, config)
}
generateBuiltinJsonTask.group = AppConstant.TASKS_GROUP
variant.outputs.each { output ->output.processManifest.doLast {output.processManifest.outputs.files.each { File file ->def manifestFile = null;//在gradle plugin 3.0.0之前，file是文件，且文件名为AndroidManifest.xml//在gradle plugin 3.0.0之后，file是目录，且不包含AndroidManifest.xml，需要自己拼接//除了目录和AndroidManifest.xml之外，还可能会包含manifest-merger-debug-report.txt等不相干的文件，过滤它if ((file.name.equalsIgnoreCase("AndroidManifest.xml") && !file.isDirectory()) || file.isDirectory()) {if (file.isDirectory()) {//3.0.0之后，自己拼接AndroidManifest.xmlmanifestFile = new File(file, "AndroidManifest.xml")} else {//3.0.0之前，直接使用manifestFile = file}//检测文件是否存在if (manifestFile != null && manifestFile.exists()) {println "${AppConstant.TAG} handle manifest: ${manifestFile}"def updatedContent = manifestFile.getText("UTF-8").replaceAll("</application>", newManifest + "</application>")manifestFile.write(updatedContent, 'UTF-8')}}}}
}

replugin-host-gradle 插件的构建任务基于{productFlavors}{buildTypes}组合出多维构建任务，为每一个组合在AndroidManifest.xml中生成四大组件坑位。生成四大组件坑位的代码在ComponentsGenerator中.

def newManifest = ComponentsGenerator.generateComponent(appID, config)

 ComponentsGenerator的generateComponent方法主要实现在AndroidManifest中四大组件坑位的写入。

/* 透明坑 */
config.countTranslucentStandard.times {activity("${name}": "${applicationID}.${infix}N1NRTS${it}","${cfg}": "${cfgV}","${exp}": "${expV}","${ori}": "${oriV}","${theme}": "${themeTS}")
}

循环进行坑位的生成，其原理基于Groovy的MarkupBuilder，组装出四大组件坑位的xml。宿主app编译完成后，可以在build\\intermediates\\manifests\\full\\ AndroidManifest.xml中看到四大组件的坑位。

2 插件的改造

replugin-plugin-gradle主要在插件应用的编译器基于Transform api 注入到编译流程中, 再通过Javassist对编译中间环节的 Java 字节码文件进行修改，以便实现编译期动态修改插件应用的目的。

replugin-plugin-gradle插件基于Gradle的Transform API，在编译期的构建任务流中，在class转为dex之前，插入一个Transform，基于Javassist技术实现对字节码文件的注入，修改Activity的继承关系、Provider和LocalBroadcastManager的调用代码为插件库的调用代码。

Javassist是一个Java字节码类库。Java的字节码是包含Java类与接口，并按照一定的顺序存在class文件中。
插件的工作原理主要在ReClassPlugin.grooovy文件中：

public class ReClassPlugin implements Plugin<Project> {@Override
public void apply(Project project) {
······
def transform = new ReClassTransform(project)
// 将 transform 注册到 android
android.registerTransform(transform)
······
}

在apply方法中，创建了很多的Task，主要用于插件调试。直接看到apply方法的最后的ReClassTransform。

public class ReClassTransform extends Transform {

Transform 是 Android Gradle API ，允许第三方插件在class文件转为dex文件前操作编译完成的class文件，这个API的引入是为了简化class文件的自定义操作而无需对Task进行处理。

ReClassTransform.groovy中的关键代码是transform方法中调用了doTransform方法，在其中遍历注入器进行注入。

def doTransform(Collection<TransformInput> inputs,TransformOutputProvider outputProvider,Object config,def injectors) {/* 初始化 ClassPool */Object pool = initClassPool(inputs)/* 进行注入操作 */Util.newSection()Injectors.values().each {if (it.nickName in injectors) {println ">>> Do: ${it.nickName}"// 将 NickName 的第 0 个字符转换成小写，用作对应配置的名称def configPre = Util.lowerCaseAtIndex(it.nickName, 0)doInject(inputs, pool, it.injector, config.properties["${configPre}Config"])} else {println ">>> Skip: ${it.nickName}"}}if (config.customInjectors != null) {config.customInjectors.each {doInject(inputs, pool, it)}}/* 重打包 */repackage()/* 拷贝 class 和 jar 包 */copyResult(inputs, outputProvider)Util.newSection()
}

 Replugin中的注入器如下图所示，每个注入器执行特定的注入任务，分别处理相应的class文件和jar文件。

Activity注入器LoaderActivityInjector，其中定义了Activity替换规则。即如果我在插件中写了一个WelcomeActivity extends Activity，则通过该注入器，最终继承关系会被改成WelcomeActivity extends PluginActivity。PluginActivity、PluginFragmentActivity等的定义在replugin-plugin-library工程中。

/* LoaderActivity 替换规则 */
def private static loaderActivityRules = ['android.app.Activity'                    : 'com.qihoo360.replugin.loader.a.PluginActivity','android.app.TabActivity'                 : 'com.qihoo360.replugin.loader.a.PluginTabActivity','android.app.ListActivity'                : 'com.qihoo360.replugin.loader.a.PluginListActivity','android.app.ActivityGroup'               : 'com.qihoo360.replugin.loader.a.PluginActivityGroup','android.support.v4.app.FragmentActivity' : 'com.qihoo360.replugin.loader.a.PluginFragmentActivity','android.support.v7.app.AppCompatActivity': 'com.qihoo360.replugin.loader.a.PluginAppCompatActivity','android.preference.PreferenceActivity'   : 'com.qihoo360.replugin.loader.a.PluginPreferenceActivity','android.app.ExpandableListActivity'      : 'com.qihoo360.replugin.loader.a.PluginExpandableListActivity'
]

 LoaderActivityInjector的关键代码在handleActivity方法中。

private def handleActivity(ClassPool pool, String activity, String classesDir) {def clsFilePath = classesDir + File.separatorChar + activity.replaceAll('\\\\.', '/') + '.class'if (!new File(clsFilePath).exists()) {return}println ">>> Handle $activity"def stream, ctClstry {stream = new FileInputStream(clsFilePath)ctCls = pool.makeClass(stream);
/*// 打印当前 Activity 的所有父类CtClass tmpSuper = ctCls.superclasswhile (tmpSuper != null) {println(tmpSuper.name)tmpSuper = tmpSuper.superclass}
*/// ctCls 之前的父类def originSuperCls = ctCls.superclass/* 从当前 Activity 往上回溯，直到找到需要替换的 Activity */def superCls = originSuperClswhile (superCls != null && !(superCls.name in loaderActivityRules.keySet())) {// println ">>> 向上查找 $superCls.name"ctCls = superClssuperCls = ctCls.superclass}// 如果 ctCls 已经是 LoaderActivity，则不修改if (ctCls.name in loaderActivityRules.values()) {// println "    跳过 ${ctCls.getName()}"return}/* 找到需要替换的 Activity, 修改 Activity 的父类为 LoaderActivity */if (superCls != null) {def targetSuperClsName = loaderActivityRules.get(superCls.name)// println "    ${ctCls.getName()} 的父类 $superCls.name 需要替换为 ${targetSuperClsName}"CtClass targetSuperCls = pool.get(targetSuperClsName)if (ctCls.isFrozen()) {ctCls.defrost()}ctCls.setSuperclass(targetSuperCls)// 修改声明的父类后，还需要方法中所有的 super 调用。ctCls.getDeclaredMethods().each { outerMethod ->outerMethod.instrument(new ExprEditor() {@Overridevoid edit(MethodCall call) throws CannotCompileException {if (call.isSuper()) {if (call.getMethod().getReturnType().getName() == 'void') {call.replace('{super.' + call.getMethodName() + '($$);}')} else {call.replace('{$_ = super.' + call.getMethodName() + '($$);}')}}}})}ctCls.writeFile(CommonData.getClassPath(ctCls.name))println "    Replace ${ctCls.name}'s SuperClass ${superCls.name} to ${targetSuperCls.name}"}} catch (Throwable t) {println "    [Warning] --> ${t.toString()}"} finally {if (ctCls != null) {ctCls.detach()}if (stream != null) {stream.close()}}}

在Javassist中CtClass是一个class文件的抽象表述。一个CtClass（compile-time class）的实例是一个可以用来操作class文件的句柄。ClassPool是用来管理字节码的编辑,ClassPool是一个存放着代表class文件的CtClass类容器，它扫描读取了class文件并且构造了CtClass类，并且是后面响应修改class文件的入口。

如果想要修改一个class文件，用户必须实例化一个ClassPool类，并且使用ClassPool的get方法取得代表这个那个class文件的CtClass的引用。

在injectClass方法中遍历插件的AndroidManifest.xml中声明的所有Activity，在handleActivity方法中根据loaderActivityRules定义的替换规则，修改此Activity的父类为对应插件库中的父类。除了修改Activity的继承规则，还要对方法体进行修改。

3 插件Activity的启动过程

3.1 classLoader的hook

public static final void init(Application application) {setApplicationContext(application);PluginManager.init(application);sPluginMgr = new PmBase(application);sPluginMgr.init();Factory.sPluginManager = PMF.getLocal();Factory2.sPLProxy = PMF.getInternal();PatchClassLoaderUtils.patch(application);
}

 PatchClassLoaderUtils.patch(application)方法，进行classLoader的hook，替换为RePluginClassLoader。

// 获取mPackageInfo.mClassLoader
ClassLoader oClassLoader = (ClassLoader) ReflectUtils.readField(oPackageInfo, "mClassLoader");
if (oClassLoader == null) {if (LOGR) {LogRelease.e(PLUGIN_TAG, "pclu.p: nf mpi. mb cl=" + oBase.getClass() + "; mpi cl=" + oPackageInfo.getClass());}return false;
}// 外界可自定义ClassLoader的实现，但一定要基于RePluginClassLoader类
ClassLoader cl = RePlugin.getConfig().getCallbacks().createClassLoader(oClassLoader.getParent(), oClassLoader);// 将新的ClassLoader写入mPackageInfo.mClassLoader
ReflectUtils.writeField(oPackageInfo, "mClassLoader", cl);

接着还会进行守护进程(guardService)的启动，守护进程主要是通过启动ContentProvider组件来启动。在守护进程中进行加载插件，及相关信息保存。

3.2 Activity的启动、类加载

启动插件的Activity通过Replugin.startActivity(Context context, Intent intent)启动，执行PluginLibraryInternalProxy的startActivity方法

    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);}// 是否启动下载// 若插件不可用（不存在或版本不匹配），则直接弹出“下载插件”对话框// 因为已经打开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);}}}/* 检查是否是动态注册的类 */// 如果要启动的 Activity 是动态注册的类，则不使用坑位机制，而是直接动态类。// 原因：宿主的某些动态注册的类不能运行在坑位中（如'桌面'插件的入口Activity）if (LOG) {LogDebug.d("loadClass", "isHookingClass(" + plugin + " , " + activity + ") = "+ Factory2.isDynamicClass(plugin, activity));}if (Factory2.isDynamicClass(plugin, activity)) {intent.putExtra(IPluginManager.KEY_COMPATIBLE, true);intent.setComponent(new ComponentName(IPC.getPackageName(), activity));context.startActivity(intent);return true;}// 如果插件状态出现问题，则每次弹此插件的Activity都应提示无法使用，或提示升级（如有新版）// Added by Jiongxuan Zhangif (PluginStatusController.getStatus(plugin) < PluginStatusController.STATUS_OK) {if (LOG) {LogDebug.d(PLUGIN_TAG, "PluginLibraryInternalProxy.startActivity(): Plugin Disabled. pn=" + plugin);}return RePlugin.getConfig().getCallbacks().onPluginNotExistsForActivity(context, plugin, intent, process);}// 若为首次加载插件，且是“大插件”，则应异步加载，同时弹窗提示“加载中”// Added by Jiongxuan Zhangif (!RePlugin.isPluginDexExtracted(plugin)) {PluginDesc pd = PluginDesc.get(plugin);if (pd != null && pd.isLarge()) {if (LOG) {LogDebug.d(PLUGIN_TAG, "PM.startActivity(): Large Plugin! p=" + plugin);}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));}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：坑位Intentintent.setComponent(cn);if (LOG) {LogDebug.d(PLUGIN_TAG, "start activity: real intent=" + intent);}context.startActivity(intent);// 通知外界，已准备好要打开Activity了// 其中：from为要打开的插件的Intent，to为坑位IntentRePlugin.getConfig().getEventCallbacks().onPrepareStartPitActivity(context, from, intent);return true;}

其中会先检查插件的状态，若插件未加载，会回调让用户去加载。

ComponentName cn = mPluginMgr.mLocal.loadPluginActivity(intent, plugin, activity, process);

接着寻找坑位，Replugin插件化技术最关键的2个技术点，一个是四大组件占坑，二是只有一个hook点classloader。 在PluginCommImpl加载插件的Activity时，通过调用远程方法进行坑位分配。

  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 {// 获取 ActivityInfo(可能是其它插件的 Activity，所以这里使用 pair 将 pluginName 也返回)ai = getActivityInfo(plugin, activity, intent);if (ai == null) {if (LOG) {LogDebug.d(PLUGIN_TAG, "PACM: bindActivity: activity not found");}return null;}// 存储此 Activity 在插件 Manifest 中声明主题到 Intentintent.putExtra(INTENT_KEY_THEME_ID, ai.theme);if (LOG) {LogDebug.d("theme", String.format("intent.putExtra(%s, %s);", ai.name, ai.theme));}// 根据 activity 的 processName，选择进程 ID 标识if (ai.processName != null) {process = PluginClientHelper.getProcessInt(ai.processName);}// 容器选择（启动目标进程）IPluginClient client = MP.startPluginProcess(plugin, process, info);if (client == null) {return null;}// 远程分配坑位container = client.allocActivityContainer(plugin, process, ai.name, intent);if (LOG) {LogDebug.i(PLUGIN_TAG, "alloc success: container=" + container + " plugin=" + plugin + " activity=" + activity);}} catch (Throwable e) {if (LOGR) {LogRelease.e(PLUGIN_TAG, "l.p.a spp|aac: " + e.getMessage(), e);}}// 分配失败if (TextUtils.isEmpty(container)) {return null;}PmBase.cleanIntentPluginParams(intent);// TODO 是否重复// 附上额外数据，进行校验
//        intent.putExtra(PluginManager.EXTRA_PLUGIN, plugin);
//        intent.putExtra(PluginManager.EXTRA_ACTIVITY, activity);
//        intent.putExtra(PluginManager.EXTRA_PROCESS, process);
//        intent.putExtra(PluginManager.EXTRA_CONTAINER, container);PluginIntent ii = new PluginIntent(intent);ii.setPlugin(plugin);ii.setActivity(ai.name);ii.setProcess(IPluginManager.PROCESS_AUTO);ii.setContainer(container);ii.setCounter(0);return new ComponentName(IPC.getPackageName(), container);}

远程调用找到坑位后，将要启动的目标Activity、插件名称、坑位等信息保存到PluginIntent中，PluginIntent没发现什么大用处，保存了信息，但又没把信息返回给调用方，loadPluginActivity方法将坑位信息返回。

坑位的分配在PluginProcessPer.java中的allocActivityContainer方法中，再看bindActivity方法中继续调用其他方法进行坑位分配。

final String bindActivity(String plugin, int process, String activity, Intent intent) {/* 获取插件对象 */Plugin p = mPluginMgr.loadAppPlugin(plugin);if (p == null) {if (LOG) {LogDebug.w(PLUGIN_TAG, "PACM: bindActivity: may be invalid plugin name or load plugin failed: plugin=" + plugin);}return null;}/* 获取 ActivityInfo */ActivityInfo ai =   p.mLoader.mComponents.getActivity(activity);
······
// 自定义进程`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);
}

 首先根据插件名称去获取加载的插件信息，插件信息中包含待启动Activity的类名、主题、启动模式等信息。

再看PluginContainers类中的alloc2方法，根据Activity不同的启动模式，分配不同的坑位，宿主的gradle在编译阶段会给不同启动模式的Activity都生成一定数量的坑位。所以在分配坑位时，也根据当前要启动的Activity的启动模式去对应的坑位集合中去寻找坑位。

tring alloc2(ActivityInfo ai, String plugin, String activity, int process, Intent intent, String processTail) {// 根据进程名称，取得该进程对应的 PluginContainerStatesProcessStates states = mProcessStatesMap.get(processTail);ActivityState state;String defaultPluginTaskAffinity = ai.applicationInfo.packageName;if (LOG) {LogDebug.d(TaskAffinityStates.TAG, String.format("插件 %s 默认 TaskAffinity 为 %s", plugin, defaultPluginTaskAffinity));LogDebug.d(TaskAffinityStates.TAG, String.format("%s 的 TaskAffinity 为 %s", activity, ai.taskAffinity));}/* SingleInstance */if (ai.launchMode == LAUNCH_SINGLE_INSTANCE) {synchronized (mLock) {state = allocLocked(ai, states.mLaunchModeStates.getStates(ai.launchMode, ai.theme), plugin, activity, intent);}/* TaskAffinity */} else if (!defaultPluginTaskAffinity.equals(ai.taskAffinity)) { // 非默认 taskAffinitysynchronized (mLock) {state = allocLocked(ai, states.mTaskAffinityStates.getStates(ai), plugin, activity, intent);}/* other mode */} else {synchronized (mLock) {state = allocLocked(ai, states.mLaunchModeStates.getStates(ai.launchMode, ai.theme), plugin, activity, intent);}}if (state != null) {return state.container;}return null;
}

真正执行坑位的方法allocLocked方法

private final ActivityState allocLocked(ActivityInfo ai, HashMap<String, ActivityState> map,String plugin, String activity, Intent intent) {······// 新分配：找空白的，第一个for (ActivityState state : map.values()) {if (state.state == STATE_NONE) {if (LOG) {LogDebug.d(PLUGIN_TAG, "PACM: alloc empty container=" + state.container);}state.occupy(plugin, activity);return state;}}·······// never reach herereturn null;
}

 在allocLocked方法中坑位Activity和真实要启动的Activity之间的对应关系，被保存在ActivityState类中，plugin是插件名，activity是待启动的插件中的activity，container是坑位。

static final class ActivityState {final String container;int state;String plugin;String activity;long timestamp;final ArrayList<WeakReference<Activity>> refs;···
}

坑位container到底是什么样的一个东西呢，搜索container在哪里进行了赋值，发现container只在ActivityState 的构造函数中进行了赋值。搜索构造函数的调用方，可以在LaunchModeStates看到相关代码。

    /*** 初始化 LaunchMode 和 Theme 对应的坑位** @param containers  保存所有 activity 坑位的引用* @param prefix      坑位前缀* @param launchMode  launchMode* @param translucent 是否是透明的坑* @param count       坑位数*/void addStates(Map<String, ActivityState> allStates, HashSet<String> containers, String prefix, int launchMode, boolean translucent, int count) {String infix = getInfix(launchMode, translucent);HashMap<String, ActivityState> states = mStates.get(infix);if (states == null) {states = new HashMap<>();mStates.put(infix, states);}for (int i = 0; i < count; i++) {String key = prefix + infix + i;// 只有开启“详细日志”时才输出每一个坑位的信息，防止刷屏if (RePlugin.getConfig().isPrintDetailLog()) {LogDebug.d(TAG, "LaunchModeStates.add(" + key + ")");}ActivityState state = new ActivityState(key);states.put(key, state);allStates.put(key, state);containers.add(key);}}

可以看出，在循环中container = prefix + infix +i;infix的值可以在getInfix方法查看。继续往上查找调用关系，查看PluginContainers.java中的init方法。

    final void init(int process, HashSet<String> containers) {if (process != IPluginManager.PROCESS_UI&& !PluginProcessHost.isCustomPluginProcess(process)&& !PluginManager.isPluginProcess()) {return;}//prefix = 包名+“.loader.a.Activity”String prefix = IPC.getPackageName() + CONTAINER_ACTIVITY_PART; // 因为自定义进程可能也会唤起使用 UI 进程的坑，所以这里使用'或'条件if (process == IPluginManager.PROCESS_UI || PluginProcessHost.isCustomPluginProcess(process)) {/* UI 进程标识为 N1 */String suffix = "N1";// StandardmLaunchModeStates.addStates(mStates, containers, prefix + suffix, LAUNCH_MULTIPLE, true, HostConfigHelper.ACTIVITY_PIT_COUNT_TS_STANDARD);mLaunchModeStates.addStates(mStates, containers, prefix + suffix, LAUNCH_MULTIPLE, false, HostConfigHelper.ACTIVITY_PIT_COUNT_NTS_STANDARD);······}}

基本可以看出container的根据不同启动模式、主题等有所不同，但基本类似于：包名+“.loader.a.Activity”+“N1”+“NR”+“NTS”+i，i代表数字编号。可以看出来就是replugin- host-gradle插件在AndroidManifest.xml文件中生成的坑位。

插件Activity的坑位找到后，就调用startActivity通知AMS去启动坑位Activity，中间还有一大堆的流程略过，然后要进行类的加载。这时Replugin中的RepluginClassLoader开始发挥作用了。

RepluginClassLoader的loadClass方法最终会调用PmBase类中的loadClass方法。

    final Class<?> loadClass(String className, boolean resolve) {// 加载Service中介坑位if (className.startsWith(PluginPitService.class.getName())) {if (LOG) {LogDebug.i(TAG, "loadClass: Loading PitService Class... clz=" + className);}return PluginPitService.class;}//if (mContainerActivities.contains(className)) {Class<?> c = mClient.resolveActivityClass(className);if (c != null) {return c;}// 输出warn日志便于查看// use DummyActivity orig=if (LOGR) {LogRelease.w(PLUGIN_TAG, "p m hlc u d a o " + className);}return DummyActivity.class;}······
}

再看看关键的PluginProcessPer类的resolveActivityClass方法，找到要真正启动的Activity类，并进行加载。

    final Class<?> resolveActivityClass(String container) {String plugin = null;String activity = null;// 先找登记的，如果找不到，则用forward activityPluginContainers.ActivityState state = mACM.lookupByContainer(container);······plugin = state.plugin;activity = state.activity;Plugin p = mPluginMgr.loadAppPlugin(plugin);······ClassLoader cl = p.getClassLoader();Class<?> c = null;try {c = cl.loadClass(activity);} catch (Throwable e) {if (LOGR) {LogRelease.e(PLUGIN_TAG, e.getMessage(), e);}}return c;}

而lookupByContainer方法在PluginContainer类中，前面查找坑位的时候，也是用的PluginContainer中的alloc2、allocLocked方法。坑位与真实待启动Activity的对应关系就保存在ActivityState中。
找到插件中真正待启动Activity的类信息后，进行类加载，然后就是Android系统Activity的启动流程。从而通过占坑骗过了AMS的校验，通过hook系统ClassLoader完成真实插件Activity类的加载，进而通过系统完成插件Activity的启动。

4、 总结

前面只是针对Replugin中的一些关键技术、感兴趣点进行了粗略的分析。Replugin的很多技术精髓还需更加仔细的研读。但通过上面的一些分析，对Replugin的主要技术及设计思想能有一个大概的了解。能加深对Android系统及一些相关技术的理解。