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.xml
                    manifestFile = 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("", newManifest + "")
                    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 {

    @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 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, ctCls
        try {
            stream = new FileInputStream(clsFilePath)
            ctCls = pool.makeClass(stream);
/*
             // 打印当前 Activity 的所有父类
            CtClass tmpSuper = ctCls.superclass
            while (tmpSuper != null) {
                println(tmpSuper.name)
                tmpSuper = tmpSuper.superclass
            }
*/
            // ctCls 之前的父类
            def originSuperCls = ctCls.superclass

            /* 从当前 Activity 往上回溯，直到找到需要替换的 Activity */
            def superCls = originSuperCls
            while (superCls != null && !(superCls.name in loaderActivityRules.keySet())) {
                // println ">>> 向上查找 $superCls.name"
                ctCls = superCls
                superCls = 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() {
                        @Override
                        void 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 Zhang
        if (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 Zhang
        if (!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：坑位Intent
        intent.setComponent(cn);

        if (LOG) {
            LogDebug.d(PLUGIN_TAG, "start activity: real intent=" + intent);
        }

        context.startActivity(intent);

        // 通知外界，已准备好要打开Activity了
        // 其中：from为要打开的插件的Intent，to为坑位Intent
        RePlugin.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 中声明主题到 Intent
            intent.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) {
    // 根据进程名称，取得该进程对应的 PluginContainerStates
    ProcessStates 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)) { // 非默认 taskAffinity
        synchronized (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 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 here
    return 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> refs;
    ···
}

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

    /**
     * 初始化 LaunchMode 和 Theme 对应的坑位
     *
     * @param containers  保存所有 activity 坑位的引用
     * @param prefix      坑位前缀
     * @param launchMode  launchMode
     * @param translucent 是否是透明的坑
     * @param count       坑位数
     */
    void addStates(Map allStates, HashSet containers, String prefix, int launchMode, boolean translucent, int count) {
        String infix = getInfix(launchMode, translucent);
        HashMap 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 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";

            // Standard
            mLaunchModeStates.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 activity
        PluginContainers.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系统及一些相关技术的理解。