RePlugin之Hook ClassLoader

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
后来关于插件四大组件的启动， 都是以上两者为基础的