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<PluginInfo> 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);
}
}
}
总结上面代码中完成的操作：
-
new PmHostSvc()中创建PluginServiceServer和PluginManagerServer实例 -
PluginProcessMain.installHost(mHostSvc)调用mHostSvc.fetchManagerServer()获取PluginManagerServer实例缓存到PluginManagerProxy中。 -
schedulePluginProcessLoop()的作用是无限循环检测进程中是否还有组件，否则就kill这个进程 - 获取到所有插件信息汇入总表
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的核心初始化流程就分析完毕了。
