MPlugin的相关方法

prepare 方法

该方法主要是预加载（可放置在Application#attachBaseContext中进行设置），主要实现流程如下

• 进行hookInstrumentation（实现绕过注册文件检查机制）具体可以看小编之前写的《剖析Activity启动及Hook》
• 构建AssetManager，加载插件dex资源
• 通过插入DexElements方式将插件Apk注入宿主Apk中
• 若插件存在so库，则解压插件so库拷贝至宿主中并插入宿主so数组中，可参考小编之前写的《插件化中加载so库解决方案》

loadPluginResource 方法

通过阅读源码我们知道，AssetManager有一个addAssetPath方法可以指定资源的位置，所以我们可以通过反射去调用该方法从而构建AssetManager，获得对应dex下的Resources、Theme，从而实现读取插件中的资源。

主要有两种方式：

• 方案1（MPlugin采用的方式）：可以通过AssetManager.class.newInstance()方式构建新的AssetManager，从而将宿主MainActivity中的Resources、Theme替换成新的AssetManager中的Resources、Theme，将MainActivity中的context传给插件，让插件中的activity使用该context进行load取插件资源，这样的好处就是可以避免资源id冲突问题。
  缺点：就是只能用该context提取资源，不能用当前activity中的context。
  同时这样有可能引起宿主资源加载冲突，小编暂时想到的方案是通过获取当前堆栈信息来判断调用该方法来自哪个类来决定返回对应的resource对象，相关代码如下：

  /**
     * 通过获取当前线程堆栈，根据包名区分是否来自插件调用
     * @return
     */
    public static boolean isPluginCallerClass(String packageName){
        StackTraceElement[] stes = Thread.currentThread().getStackTrace();
        for (int i = 0; i < stes.length; i ++) {
            if(stes[i].getClassName().contains(packageName)){
                return true;
            }
        }
        return false;
    }

• 方案2：可以通过获取当前AssetManager，再通过反射调用addAssetPath，传入插件dex路径，从而实现资源获取，缺点是资源id冲突（主要解决方式是修改aapt重定义资源id命名规则）

关于context简介

Activity、Service、Application都是ContextWrapper的子类。而ContextWrapper里面有一个Context类型的成员变量mBase，它对应的类型是ContextImpl。ContextWrapper实现方法的时候调用了mBase的方法。比如调用getResources时则通过mBase调用到了ContextImpl中的实现方法，进而一步步到AssetManager中根据dex路径获取资源。
所以我们为了让context能获取到对应的dex资源，我们还需要将新构建的AssetManager获得的Resources、Theme对象置入activity的getResources()、getTheme()重写方法中返回。

图片源自：https://www.jianshu.com/p/a1dc2223f87c

相关代码如下：

    @Override
    public synchronized AssetManager getAssets() {
        return mPluginResource == null ? super.getAssets() : mPluginResource.assetManager;
    }

    @Override
    public synchronized Resources getResources() {
        return mPluginResource == null ? super.getResources() : mPluginResource.resources;
    }

    @Override
    public synchronized Resources.Theme getTheme() {
        return mPluginResource == null ? super.getTheme() : mPluginResource.theme;
    }

installPlugin 方法

通过插入DexElements方式将插件Apk注入宿主Apk中，并启动插件activity

关于dex注入

从《剖析ClassLoader深入热修复原理》中我们知道PathClassLoader、DexClassLoader均继承于BaseDexClassLoader，而通过源码阅读发现BaseDexClassLoader中有一个隐藏方法即addDexPath，该方法的主要作用就是将dex文件插入到DexElements数组首位，从而实现dex注入，所以我们可以通过反射调用从而实现插件dex注入宿主DexElements中。（网上一般是自己写这块的逻辑，估计在5.0以前没有该方法）

相关代码如下：

    public void addDexPath(String dexPath, File optimizedDirectory) {
        final List<IOException> suppressedExceptionList = new ArrayList<IOException>();
        final Element[] newElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                suppressedExceptionList, definingContext);

        if (newElements != null && newElements.length > 0) {
            final Element[] oldElements = dexElements;
            dexElements = new Element[oldElements.length + newElements.length];
            System.arraycopy(
                    oldElements, 0, dexElements, 0, oldElements.length);
            System.arraycopy(
                    newElements, 0, dexElements, oldElements.length, newElements.length);
        }

        if (suppressedExceptionList.size() > 0) {
            final IOException[] newSuppressedExceptions = suppressedExceptionList.toArray(
                    new IOException[suppressedExceptionList.size()]);
            if (dexElementsSuppressedExceptions != null) {
                final IOException[] oldSuppressedExceptions = dexElementsSuppressedExceptions;
                final int suppressedExceptionsLength = oldSuppressedExceptions.length +
                        newSuppressedExceptions.length;
                dexElementsSuppressedExceptions = new IOException[suppressedExceptionsLength];
                System.arraycopy(oldSuppressedExceptions, 0, dexElementsSuppressedExceptions,
                        0, oldSuppressedExceptions.length);
                System.arraycopy(newSuppressedExceptions, 0, dexElementsSuppressedExceptions,
                        oldSuppressedExceptions.length, newSuppressedExceptions.length);
            } else {
                dexElementsSuppressedExceptions = newSuppressedExceptions;
            }
        }
    }

MPlugin流程

plugin668.jpeg

看完如上流程，其实没有想象中复杂，当然本实例只实现了启动插件activity以及内部跳转，在开发的过程中遇到了一些问题比如宿主代理activity(只需启动一次即可)必须存在才能保证插件activity正常运行。
除了资源加载需要使用到宿主代理context外，其他均可以使用插件当前context，比如设置主题、进行dialog的启动、引入OkHttp库的网络请求、以及一些组件的生命周期绑定，这些是没问题的，通过内存泄漏监测以及内存释放情况，均无出现异常。

本方案与DL插件区别

本方案采用的也是代理方式，但是没有像DL那样完全代理插件Activity的生命周期，而是采用代理Activity的context来渲染插件Activity的view，其余的比如弹框、网络请求等均可使用插件Activity自身的context，这样一个好处是保证了插件Activity的本身生命周期完整性，同时还支持引入第三方库的插件Activity运行。

关于so加载的解决方案：

https://www.jianshu.com/p/a4a6ed83483b

video2gif_20180821_162145.gif

实例地址：https://github.com/3332523marco/MPlugin

问题纪要：

注意插件Activity继承的是AppCompatActivity
如果Activity 继承的是Activity出现的情况可能不一样

问题一

通过如上实践，小编用的其实就是类似DL插件的实现方式，用宿主的context进行inflate加载插件布局文件，那小编就在想，如果不用这种方式直接启动插件activity又会怎样呢？尝试发现启动插件activity后，能正常启动，但是页面的布局竟然显示成宿主的，这就是资源id冲突导致的，那小编又想到了一个方式，既然资源id冲突，那干脆直接把插件apk所对应的Resource资源对象（可阅读实例中构建新的AssetManager对象生成Resource对象）放到插件activity中并重写getResource方法不就行了（暂时方式，只要验证可行，可以尝试在宿主中hook掉插件activity的mResource对象，从而实现无侵入），于是小编果断重写了插件activity的getResource方法后，启动插件activity，结果还是失败了，插件activity会在AppCompatDelegateImplV9中的createSubDecor方法里抛出contentView.setId(android.R.id.content); contentView为null的空指针

contentView的生成方式如下：

 LayoutInflater inflater = LayoutInflater.from(mContext);

 ViewGroup subDecor = (ViewGroup) inflater.inflate(R.layout.abc_screen_simple, null);
 ContentFrameLayout contentView = (ContentFrameLayout) subDecor1.findViewById(
                R.id.action_bar_activity_content);

通过断点定位分析，之所以导致contentView为null，并不是因为R.layout.abc_screen_simple中没有这个R.id.action_bar_activity_content，而是因为它链取的地址仍然是宿主的id而非插件所指向的id，从而导致ViewGroup进行遍历查找view元素时找不到对应的id，从而返回null，具体我们来看下截图就明了了。

plugin_1.jpeg

plugin_2.jpeg

plugin_3.jpeg

看到这里你就大概知道为什么为null了，布局文件中的id值和我们findViewById传入的值是对不上的，这个id为2131165193的值是宿主的，所以导致返回为null

问题二

为了尝试实现无需插件重写相关方法也能正常运行，根据阅读源码，尝试在newActivity方法中拿到插件activity对象后，通过反射将AppCompatActivity中的mDelegate对象替换为宿主mDelegate，因为我们知道Activity的setContentView、findViewById等方法都是通过mDelegate这个对象代理调用的，所以我们可以尝试通过将宿主的mDelegate与之替换。
替换代码如下：

  Field nameField = null;// appCompatActivity为插件activity实例化对象
        try {
            nameField = appCompatActivity.getClass().getSuperclass().getSuperclass().getDeclaredField("mDelegate");
            nameField.setAccessible(true);// 设置操作权限为true
           //HookInstrumentationProxy.m为宿主mDelegate
            nameField.set(appCompatActivity, HookInstrumentationProxy.m);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        }

替换成功后，发现在无需重写setContentView、findViewById等方法的情况下能正常启动插件activity，但是会启动两次页面，多了一个全白的页面位于栈顶，通过返回上一页，为插件activity页面，加载jni均正常、点击事件均正常，但是点击弹出dialog，则抛出异常。
出现空白页面的主要原因是你把宿主的mDelegate给了插件，因为当调用setContentView时会先将contentParent给remove掉，这也就是为什么出现空白页面，其实这个空白页面就是宿主的页面被清空并跳转至栈顶了

问题三

通过在gradle.properties文件中设置android.enableAapt2 = false，直接在插件中将getResources对象重置成插件apk本身，竟然可以正常运行，但是若引入第三方含资源文件的库，会抛异常，需要将第三方含资源文件的库同时引入宿主工程才正常。