插件化框架RePlugin解析--RePlugin初始化流程

RePlugin框架中重要的类及用途说明。

// 继承于Application，初始化的入口类
RePluginApplication.java  
// 外观类，持有了PluginCommImpl、PluginLibraryInternalProxy的实例
PmBase.java 
// 持有了PmBase的实例
PMF.java
// 负责宿主与插件、插件间的互通
PluginCommImpl.java
// 主要用于Activity的启动
PluginLibraryInternalProxy.java
// Activity坑位管理
PluginProcessPer.java
// 对外提供服务的入口，提供PluginServiceServer和PluginManagerServer等
PmHostSvc.java
// 插件Service管理Binder类
PluginServiceServer.java
// 插件管理Binder类
PluginManagerServer.java

1、从attachBaseContext()开始初始化

@Override
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);

    RePluginConfig c = createConfig();
    if (c == null) {
        c = new RePluginConfig();
    }

    RePluginCallbacks cb = createCallbacks();
    if (cb != null) {
        c.setCallbacks(cb);
    }
    
    RePlugin.App.attachBaseContext(this, c);
}

由于RePlugin初始化过程中会hook系统的ClassLoader，而RePluginApplication里的attachBaseContext()是一个应用里最早被系统调用到的方法。该方法首先创建RePluginConfig和RePluginCallbacks的实例，如果没有自定义创建，则会创建默认的实例。接下来调用RePlugin.App.attachBaseContext(this, c)正式开始初始化流程。

2、RePlugin.App.attachBaseContext()初始化流程

public static void attachBaseContext(Application app, RePluginConfig config) {
    if (sAttached) {
        if (LogDebug.LOG) {
            LogDebug.d(TAG, "attachBaseContext: Already called");
        }
        return;
    }
    // 很简单，让RePluginInternal持有app
    RePluginInternal.init(app);
    sConfig = config;
    // 初始化插件安装目录，创建默认Callback
    sConfig.initDefaults(app);

    IPC.init(app);

    // 打印当前内存占用情况
    // 只有开启“详细日志”才会输出，防止“消耗性能”
    if (LOG && RePlugin.getConfig().isPrintDetailLog()) {
        LogDebug.printMemoryStatus(LogDebug.TAG, "act=, init, flag=, Start, pn=, framework, func=, attachBaseContext, lib=, RePlugin");
    }

    // 初始化HostConfigHelper（通过反射HostConfig来实现）
    // NOTE 一定要在IPC类初始化之后才使用
    HostConfigHelper.init();

    // FIXME 此处需要优化掉
    AppVar.sAppContext = app;

    // Plugin Status Controller
    PluginStatusController.setAppContext(app);

    PMF.init(app);
    PMF.callAttach();

    sAttached = true;
}

上面有注释的地方不再分析。IPC.init(app)的作用是初始化常驻进程名称，当前进程是UI进程还是常驻进程，后面的初始化会根据进程的不同，执行不同的p初始化过程。接下来调用PMF.init(app)继续执行框架的初始化工作，而PMF.callAttach()的作用是加载默认插件。

3、PMF.init()初始化流程

public static final void init(Application application) {
    // 让PMF持有application
    setApplicationContext(application);
    // 初始化进程UID，分配进程index
    PluginManager.init(application);
    
    sPluginMgr = new PmBase(application);
    sPluginMgr.init();

    // 将PluginCommImpl实例给Factory
    Factory.sPluginManager = PMF.getLocal();
    // 将PluginLibraryInternalProxy实例给Factory2
    Factory2.sPLProxy = PMF.getInternal();
    
    // hook系统的ClassLoader
    PatchClassLoaderUtils.patch(application);
}

上面有注释的地方不再分析，我们主要跟进PmBase实例的创建和init()初始化。

4、创建PmBase实例

PmBase(Context context) {
    mContext = context;

    // TODO init
    //init(context, this);
    // 根据不同进程，拼接出Provider和Service坑位
    if (PluginManager.sPluginProcessIndex == IPluginManager.PROCESS_UI || PluginManager.isPluginProcess()) {
        String suffix;
        if (PluginManager.sPluginProcessIndex == IPluginManager.PROCESS_UI) {
            suffix = "N1";
        } else {
            suffix = "" + PluginManager.sPluginProcessIndex;
        }
        //
        mContainerProviders.add(IPC.getPackageName() + CONTAINER_PROVIDER_PART + suffix);
        //
        mContainerServices.add(IPC.getPackageName() + CONTAINER_SERVICE_PART + suffix);
    }

    // PluginProcessPer是用于Activity坑位管理
    mClient = new PluginProcessPer(context, this, PluginManager.sPluginProcessIndex, mContainerActivities);

    // 创建PluginCommImpl实例
    mLocal = new PluginCommImpl(context, this);

    // 创建PluginLibraryInternalProxy实例
    mInternal = new PluginLibraryInternalProxy(this);
}

5、调用PmBase的init()初始化

void init() {

    RePlugin.getConfig().getCallbacks().initPnPluginOverride();

    if (HostConfigHelper.PERSISTENT_ENABLE) {
        // （默认）“常驻进程”作为插件管理进程，则常驻进程作为Server，其余进程作为Client
        if (IPC.isPersistentProcess()) {
            // 初始化“Server”所做工作
            initForServer();
        } else {
            // 连接到Server
            initForClient();
        }
    } else {
        // “UI进程”作为插件管理进程（唯一进程），则UI进程既可以作为Server也可以作为Client
        if (IPC.isUIProcess()) {
            // 1. 尝试初始化Server所做工作，
            initForServer();

            // 2. 注册该进程信息到“插件管理进程”中
            // 注意：这里无需再做 initForClient，因为不需要再走一次Binder
            PMF.sPluginMgr.attach();

        } else {
            // 其它进程？直接连接到Server即可
            initForClient();
        }
    }

    // 最新快照
    PluginTable.initPlugins(mPlugins);

    // 输出
    if (LOG) {
        for (Plugin p : mPlugins.values()) {
            LogDebug.d(PLUGIN_TAG, "plugin: p=" + p.mInfo);
        }
    }
}

UI进程：即我们应用的UI进程
常驻进程：进程名称为GuardService
UI进程和常驻进程都可以作为插件管理进程，默认是用常驻进程作为插件管理进程。
所以不管是UI进程或常驻进程，将调用initForServer()进行服务端(插件管理端)的初始化，否则调用initForClient()进行插件端初始化。

6、initForServer()初始化插件管理端

private final void initForServer() {
    if (LOG) {
        LogDebug.d(PLUGIN_TAG, "search plugins from file system");
    }

    mHostSvc = new PmHostSvc(mContext, this);
    PluginProcessMain.installHost(mHostSvc);
    PluginProcessMain.schedulePluginProcessLoop(PluginProcessMain.CHECK_STAGE1_DELAY);

    // 兼容即将废弃的p-n方案 by Jiongxuan Zhang
    mAll = new Builder.PxAll();
    Builder.builder(mContext, mAll);
    refreshPluginMap(mAll.getPlugins());

    // [Newest!] 使用全新的RePlugin APK方案
    // Added by Jiongxuan Zhang
    try {
        List l = PluginManagerProxy.load();
        if (l != null) {
            // 将"纯APK"插件信息并入总的插件信息表中，方便查询
            // 这里有可能会覆盖之前在p-n中加入的信息。本来我们就想这么干，以"纯APK"插件为准
            refreshPluginMap(l);
        }
    } catch (RemoteException e) {
        if (LOGR) {
            LogRelease.e(PLUGIN_TAG, "lst.p: " + e.getMessage(), e);
        }
    }
}

总结上面代码中完成的操作：

1. new PmHostSvc()中创建PluginServiceServer和PluginManagerServer实例
2. PluginProcessMain.installHost(mHostSvc)调用mHostSvc.fetchManagerServer()获取PluginManagerServer实例缓存到PluginManagerProxy中。
3. schedulePluginProcessLoop()的作用是无限循环检测进程中是否还有组件，否则就kill这个进程
4. 获取到所有插件信息汇入总表

7、initForClient()初始化插件端

private final void initForClient() {
    if (LOG) {
        LogDebug.d(PLUGIN_TAG, "list plugins from persistent process");
    }

    // 1. 先尝试连接
    PluginProcessMain.connectToHostSvc();

    // 2. 然后从常驻进程获取插件列表
    refreshPluginsFromHostSvc();
}

能够执行到这个方法的一定是处于插件进程，那么要连接到"插件管理端"获取信息，则需要进行多进程通信。

static final void connectToHostSvc() {
    ...
    // 通过Provider的方式获取到远程Binder对象(`BinderProxy`)
    IBinder binder = PluginProviderStub.proxyFetchHostBinder(context);
    ...
    // 将远程Binder对象转换为一个IPluginHost类型的Binder对象(Stub.Proxy)
    sPluginHostRemote = IPluginHost.Stub.asInterface(binder);
    ...
    try {
        // 通过sPluginHostRemote获取到PluginManagerServer这个远程Binder对象
        PluginManagerProxy.connectToServer(sPluginHostRemote);
        ...
    } catch (RemoteException e) {
        ...
    }

    // 注册该进程信息到“插件管理进程”中
    PMF.sPluginMgr.attach();
}

connectToHostSvc()无非就是通过查询Provider的方式，拿到IPluginHost类型的远程Binder对象，然后再通过这个Binder对象拿到PluginManagerServer这个远程Binder对象，这样我们就可以和插件管理进程通信了。
关于Binder机制，请参考Android插件化基础--Binder机制。
至此，RePlugin的核心初始化流程就分析完毕了。