美文网首页
Android插件化——类加载器机制

Android插件化——类加载器机制

作者: ZuYuan | 来源:发表于2021-12-27 22:52 被阅读0次

    需求

    必要特性

    1. 支持加载插件的dex代码,包括插件中的四大组件类;
    2. 支持插件访问宿主的类,且该类只会被加载一次;

    补充特性

    1. 支持分别加载不同插件中类名相同但内容不同的类;

    技术基础

    1. class加载的双亲委派模型: class文件优先由父类加载器加载,保证了一个class文件只会被一个类加载器加载一次;
    2. BaseClassLoader: 支持对一个apk进行加载,当然加载apk也是自动解析并加载其内部的dex文件。BaseClassLoader内含有一个dexElements数组,代表dex的查找路径。class的查找过程就是顺序遍历dexElements来查找相关类。
                  类查找方向
    =========================================> 
         |           |          |         |
    |---------| |--------| |---------|   ...
     dex1.dex    dex2.dex   dex3.dex
    
    

    BaseDexClassLoader有两个子类:PathClassLoader, 加载已经安装过的apk,即正在运行的应用的类加载器都是PathClassLoader。DexClassLoader,加载外置的apk。

    1. JVM访问到一个内存不存在的class时,会优先使用调用者(当前类)的类加载器进行加载,Class.forName(String className)方法同理。

    技术方案

    单ClassLoader方案

    其原理和Tinker热修复的类加载机制一致。但相对简单的是由于插件化的原理天然支持CLASS_ISPREVERIFIED标志。 大致原理为:向应用的PathClassLoader中的dexElements`数组添加一个元素并赋值为插件apk路径:

                  类查找方向
    =============================================> 
         |           |         |         |
    |---------| |--------|    ...    |--------|
     dex1.dex    dex2.dex              插件.apk
    
    

    这种类加载机制的模型相对简单,并且天然支持四大组件类加载。但是由于插件的代码和宿主的代码放在了同一个类加载器中,运行时插件的安装和卸载都伴随着对宿主类加载器的dexElements进行反射修改,这是一项非常危险的操作,容易对宿主运行稳定性产生影响。这种类加载模型对“独立安装”类型的插件也不友好,不支持加载不同插件中类名相同但内容不同的类。

    多ClassLoader方案

    每个插件对应一个自定义的DexClassLoader,用于加载各自的dex代码。
    自定义DexClassLoader的类加载过程:

      自定义DexClassLoader.loadClass()
    =================宿主找到类就结束==============>  
                /                     \
    宿主ClassLoader.loadClass()         \
                                        \
                              自定义DexClassLoader.findClass() 
    

    上面的类加载过程符合抽象意义的双亲委派模型,优先从宿主的ClassLoader中查找类,即优先加载宿主的class,当宿主中没有该类时,再从插件的ClassLoader中查找。这种类加载模型并不用反射宿主的dexElements数组。
    由技术基础中的第3点可知,在这种类加载模型下,宿主的类肯定是无法直接访问插件类的(默认由于组件化的限制,宿主本来就无法直接访问插件类),因此需要通过插件的ClassLoader.loadClass(String className) 来访问插件的类。当然在插件激活的时候向宿主注册插件的“功能服务”似乎是更加合理的选择。
    多ClassLoader的模型还面临着一个问题——插件的四大组件的类加载。四大组件是由AMS通知ActivityThread启动的,实际上最终它们的class是由Application中的mPackageInfomClassLoader加载的。这一步避免不了反射,需要将mPakageInfo中的mClassLoader替换成我们的自定义的用于分发的ClassLoader。这里的自定义模型和上面的自定义DexClassLoader模型是一致的,优先从宿主进行加载,宿主找不到再从插件中加载。当然如果是四大组件都被代理的情况下,也还可以避免掉上述的这种反射问题。
    多ClassLoader的模型需要较严格的项目组件化,但好处是反射较少。每个插件拥有独立的ClassLoader也能够解决不同插件中的“类重名”问题。

    实际体验

    单ClassLoader模型简单,但遇到的运行时兼容问题较多。多ClassLoader模型相对复杂,开发难度较高,但可以解决“类重名”问题,运行时的兼容问题很少。推荐使用多ClassLoader模型。
    desc:如果使用了R8的话,插件的Kotlin代码会遇到伴生类或者lambda类被分包到宿主中去的情况。在多ClassLoader模型下,这会导致伴生/lambda类和它的宿主类分别被不同的类加载器加载,出现ClassNotFound问题。

    相关文章

      网友评论

          本文标题:Android插件化——类加载器机制

          本文链接:https://www.haomeiwen.com/subject/qvsuqrtx.html