One Hook
RePlugin 仅通过hook一个地方来改变ClassLoader的加载方式， 使得加载Class时先寻找所有插件是否有该Class, 没有之后才去执行原本ClassLoader
RepluginClassLoader
@Override
protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
Class<?> c = null;
// 先来寻找所有插件是否有该类
c = PMF.loadClass(className, resolve);
if (c != null) {
return c;
}
//
try {
// 插件中没有的话就用原本的ClassLoader加载
c = mOrig.loadClass(className);
// 只有开启“详细日志”才会输出，防止“刷屏”现象
if (LogDebug.LOG && RePlugin.getConfig().isPrintDetailLog()) {
LogDebug.d(TAG, "loadClass: load other class, cn=" + className);
}
return c;
} catch (Throwable e) {
//
}
//
return super.loadClass(className, resolve);
}
先来看我们是如何将系统的ClassLoader替换为我们的RepluginClassLoader的
我们知道， Replugin要求我们继承自RePluginApplication，我们来看RePluginApplication中干了什么，
@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);
}
我们看到在attachBaseContext中， 做了RePluginConfig， RePluginCallbacks的创建，这两个不用管， 看这一行RePlugin.App.attachBaseContext(this, c); 这里面我们只看PMF.init(app); init这里对进行了初始化， 当然这里也包括了对ClassLoader的Hook PatchClassLoaderUtils.patch(application);
我们来重点看下这个方法
public static boolean patch(Application application) {
try {
//********************************************
// =》 1. 反射， 获取classLoader 字段
Context oBase = application.getBaseContext();
if (oBase == null) {
return false;
}
Object oPackageInfo = ReflectUtils.readField(oBase, "mPackageInfo");
if (oPackageInfo == null) {
return false;
}
// mPackageInfo的类型主要有两种：
// 1. android.app.ActivityThread$PackageInfo - Android 2.1 - 2.3
// 2. android.app.LoadedApk - Android 2.3.3 and higher
// 获取mPackageInfo.mClassLoader
ClassLoader oClassLoader = (ClassLoader) ReflectUtils.readField(oPackageInfo, "mClassLoader");
if (oClassLoader == null) {
return false;
}
// 以上 拿到了classLoader字段
// *****************************************************************
// 都不用看， 这段肯定是用来生成RepluginClassLoader的
ClassLoader cl = RePlugin.getConfig().getCallbacks().createClassLoader(oClassLoader.getParent(), oClassLoader);
// 将新的ClassLoader写入mPackageInfo.mClassLoader
ReflectUtils.writeField(oPackageInfo, "mClassLoader", cl);
// 设置线程上下文中的ClassLoader为RePluginClassLoader
// 防止在个别Java库用到了Thread.currentThread().getContextClassLoader()时，“用了原来的PathClassLoader”，或为空指针
Thread.currentThread().setContextClassLoader(cl);
} catch (Throwable e) {
e.printStackTrace();
return false;
}
return true;
}
上面很明显这个patch方法就是对contextImpl 中的 mPackageInfo 中的mClassLoader进行替换的， 换成了我们的RePluginClassLoader， 就这样， 完成了Hook
另外这里再说一个点，
- 坑位
坑位是Replugin中设计非常巧妙的一个概念，它的功能是与RepluginClassLoader配合才能实现的。所谓坑位就是预先在Host的Manifest中注册的一些组件（Activity, Service, Content Provider，唯独没有Broadcast Receiver)，叫做坑位。这些坑位组件的代码都是由gradle插件在编译时生成的，他们实际上并不会被用到。在启动插件的组件时，会用这些坑位去替代要启动的组件，并且会建立一个坑位与真实组件之间的对应关系（用ActivityState表示)，然后在加载类的时候RepluginClassLoader 会根据前文提到的被篡改过的行为偷偷使用插件的PluginDexClassLoader加载要启动的真实组件类，骗过了系统，这就是唯一hook点的作用。
出处：神罗天征_39a0
后来关于插件四大组件的启动， 都是以上两者为基础的
