Android插件化框架系列之类加载器

原文链接：http://mp.weixin.qq.com/s?__biz=MzAxMTI4MTkwNQ==&mid=2650822215&idx=1&sn=964d9f9c951044e572cccb8846330d25&chksm=80b782d9b7c00bcf9533d0ea5085d449083d014d6aa585817610e4d1b17fe89922eca7deb6c7&mpshare=1&scene=23&srcid=0502Z0haLLlIuOAIA0epVykH#rd

http://mp.weixin.qq.com/s?__biz=MzA5MzI3NjE2MA==&mid=2650238826&idx=1&sn=294d91d9a190ea56822696994f8a04b0&chksm=88639e05bf1417137f364037bb35a8fcc120679c92b924cfabffa7011199d8ac8bba69a25194&mpshare=1&scene=23&srcid=0502n7hUoU3xKeh1f7ugbGGI#rd

发现很多人都在找工作，今天推荐的是包含Android知识、设计模式、数据结构以及面试经验等相关的一个知识合集项目。

地址：

https://github.com/GeniusVJR/LearningNotes

本文作者

本文由jjlanbupt投稿。

jjlanbupt的博客地址：

http://www.jianshu.com/u/d4c81f4599d6

过去的一两年android插件化，热修复等技术发展迅速，并且还在持续的探索中，也许插件化技术最终会在android工程中退出舞台，但里面包含的技术是非常值得我们学习的。最近，会就android动态加载等技术进行研究总结。

本篇文章作为插件化框架第一篇，首先分析android中的类加载器，并实现在android中动态加载一个外部apk中的类，从以下三部分进行介绍。

• 1. java类加载器双亲委派机制

• 2. android中的类加载器介绍

• 3. android中动态加载实现类加载

1
java类加载器双亲委派机制

学过java的同学都知道类加载器是采用双亲委派机制来进行类加载的。双亲委派机制从ClassLoader.java可以清晰的看出来。

简单来说，java的双亲委派机制分为三个过程，在ClassLoader的loadClass方法中会先判断该类是否已经加载，若加载了直接返回，若没加载过则先调用父类加载器的loadClass方法进行类加载，若父类加载器没有找到，则会调用当前正在查找的类加载器的findClass方法进行加载。

这里就涉及到类加载器的两个很重要的方法loadClass和findClass。在自定义类加载器中会涉及到这两个方法，具体二者有什么区别呢？

由上文的双亲委派机制的代码可以看出来，如果想保证自定义的类加载器符合双亲委派机制，则覆写findClass方法；如果想打破双亲委派机制，则覆写loadClass方法。

双亲委派机制保证了同一个类不会被重复加载，但是某些情况下，是需要限定名相同的多个类被多个类加载器分别加载的，比如容器插件应用场景。

这时就可以在自定义类加载器时覆写loadClass方法，摆脱双亲委派机制来直接加载。

例如：

2
android中的类加载器介绍

android中的类加载器中主要包括三类BootClassLoader，PathClassLoader和DexClassLoader。

BootClassLoader主要用于加载系统的类，包括java和android系统的类库。
PathClassLoader主要用于加载应用内中的类。

路径是固定的，只能加载
/data/app中的apk，无法指定解压释放dex的路径。所以PathClassLoader是无法实现动态加载的。

DexClassLoader可以用于加载任意路径的zip,jar或者apk文件。可以实现动态加载。下面来具体看看应用程序中的类加载器。

 Log.i("ljj", "Context的类加载器："    + Context.class.getClassLoader()); Log.i("ljj", "TextView的类加载器： "    + TextView.class.getClassLoader());

打印结果：

com.ljj.host I/ljj:     Context的类加载器：[e-mail] I/ljj:     TextView的类加载器： java.lang.BootClassLoader@a645091

可见系统的类都是由BootClassLoader加载完成。

Log.i("ljj", "classLoader:"+getClassLoader());I/ljj: classLoader:dalvik.system.PathClassLoader[DexPathList[    [zip file "/data/app/com.ljj.host-2/base.apk"],    nativeLibraryDirectories=        [/data/app/com.ljj.host-2/lib/arm64,         /vendor/lib64,         /system/lib64]    ]]

可见直接调用getClassLoader调用的是应用的PathClassLoader，DexPathList为/data/app/com.ljj.host-2/base.apk。

除了BootClassLoader和应用的PathClassLoader外，还有一个classLoader，比较难以理解，我们可以打印出来看看。

Log.i("ljj", "classLoader:"+ClassLoader.getSystemClassLoader());I/ljj: classLoader:dalvik.system.PathClassLoader[DexPathList[    [directory "."],    nativeLibraryDirectories=[/vendor/lib64,     /system/lib64]]]

可见调用ClassLoader.getSystemClassLoader()得到的也是一个PathClassLoader，但是DexPathList为“.”。这就奇怪了，为什么路径会为“.”,有必要查看一下源码。

从源码中可以看出，getSystemClassLoader()方法获得的pathClassLoader的path是由classPath来指定的

String classPath = System.getProperty("java.class.path", ".");

打印发现输出为"."，没有从源码中找到对于"java.class.path"变量的赋值过程，希望了解的人可以指教一下。

至于这个classLoader什么时候用，我的看法是当我们自定义classLoader时，假设是一个插件工程，想与host工程不冲突，独立运行，关注插件工程中的类的加载，而不关注host工程中的类的加载造成的冲突，此时可以将自定义类加载器的parent指定为此classLoader。

至于PathClassLoader我们只要知道它的路径是指定的，必须是已经安装的apk，应用的classLoader默认为PathClassLoader即可。下面我们将重点分析一下DexClassLoader。先从源码的角度进行简单分析。

DexClassLoader的源码很简单，只包含一个构造函数，看来所有的工作都是在BaseDexClassLoader中完成的。

这里再看BaseDexClassLoader前，先说一下DexClassLoader构造函数的四个参数。

• dexPath：是加载apk/dex/jar的路径

• optimizedDirectory：是dex的输出路径(因为加载apk/jar的时候会解压除dex文件，这个路径就是保存dex文件的)

• librarySearchPath：是加载的时候需要用到的lib库，这个一般不用，可以传入Null

• parent：给DexClassLoader指定父加载器
  
  

下面继续分析BaseClassLoader。

可以看出，DexClassLoader会通过传入的路径构造出一个DexPathList对象，作为pathList。从findClass方法可以看出来加载的类都是从pathList中查找。至于DexPathList对象的源码就不往下具体分析了，简单的理解就是将每个dex都构建成Element元素，放入到dexElements数组中。

多说一句，这个dexElements数组的用处很大，MultiDex方案以及由此衍生出的QQ空间热更新方案都是通过改变dexElements数组的元素位置来实现的。感兴趣的同学可以去学习一下。

3
android中动态加载实现类加载

类加载器知识介绍完毕后，我们来具体实现利用DexClassLoader来动态加载一个apk中的类。

最简单的实现方式，我们可以将一个java文件打包成jar或者转化成dex后压缩成apk，然后利用DexClassLoader加载后，反射调用里面的方法来验证效果，不过这个实例不太好说明问题，而且在项目中我们一般也不这样用。

在项目中我们可能更多的是这样使用，一个插件工程，一个宿主工程，二者间的联系通过公共接口来完成。下面来具体操作以下。

第一步：将接口打包成jar

我们新建一个接口，打包出PayService.jar。

我电脑里装有eclipse，打jar包非常方便。如果没有安装eclipse，也可以用jar命令或者gradle任务来完成。

第二步：新建一个android工程，命名为PluginPro

将PayService.jar放入libs目录，新建一个PayServiceImpl类实现IPay接口，为了方便起见，具体实现中只打印了log。

以compile的形式打包进apk。

compile fileTree(include: ['*.jar'], dir: 'libs')

第三步：新建一个android工程，命名为HostPro

将PluginPro工程生成的apk放入assets目录下，至于为什么放入到assets目录，目前插件框架中的插件都是放入到assets目录上进行打包的，这里虽然不存在插件框架，但是尽量模拟一下这种动态加载的场景。

我们分为以下几种情况进行分析。

（1）情况1

1.PayService.jar在PluginPro和HostPro均以compile的形式进行依赖，DexClassLoader的parent设置为应用默认的PathClassLoader

使用android5.0系统的手机进行测试一把，结果如下，能够正常运行，正常调用到了插件apk中的函数：

I/art: Can not find class: Lcom/ljj/plugin/serviceimpl/PayServiceImpl;I/ljj: pay: 10 元I/ljj: userName: ljjI/ljj: order: 0001

保持代码不变，又搞了个android4.2系统的手机测试一把，结果挂了：

我们来分析一下为什么出现这种结果。

首先在插件apk和宿主apk中都包含了IPay接口，我们定义的DexClassLoader指定的parent为应用默认的PathClassLoader，两个classLoader的DexPathList的路径如下所示。之所以出现这种原因可能是art和Dalvik虚拟机的内部加载细节的差异。

下面针对两种情况进行分析。

在art虚拟机中，当我们执行loadClass("com.ljj.plugin.serviceimpl.PayServiceImpl");时，

根据双亲委派机制PathClassLoader会先在宿主apk中查找，因为没有查找到"PayServiceImpl"，而PayServiceImpl实现了IPay接口，此时PathClassLoader会继续查找IPay接口，因为宿主apk中包含了IPay接口，所以IPay接口由PathClassLoader加载完成,接着由DexClassLoader从插件apk中查找PayServiceImpl，毫无疑问，可以查找到PayServiceImpl，此时IPay接口已经加载过了，不会重复加载。

这样就正常的完成了整个类加载过程。

在dalvik虚拟机中，PathClassLoader的加载过程与ART一样，区别在于由DexClassLoader继续查找PayServiceImpl时，DexClassLoader会继续加载插件apk中的IPay接口，

此时就会出现不同的类加载器加载同一个类文件（类文件位于多个dex中）就会抛出java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation的异常，该异常是由Resolve.cpp的dvmResolveClass函数定义的，可参考源码来分析。

所以我们在插件开发中，尽量保证只在宿主（插件）中使用compile方式，而在插件可以（宿主）中使用provided进行依赖，就可以完全避免java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation的产生。

下面我们使用分析好的方式继续探索。

（1）情况2

2. PayService.jar在PluginPro采用provided方式，在HostPro中以compile的形式进行依赖，DexClassLoader的parent设置为系统默认的PathClassLoader

代码与上文中保持不变，可以正确的完成动态加载，但是我们尝试着将parent设置为ClassLoader.getSystemClassLoader()

 DexClassLoader classLoader=    new DexClassLoader(src,des,null,            ClassLoader.getSystemClassLoader());

再次运行，会发现结果又报错了。。。。

看log可以大致猜出来是由于没有加载到IPay接口，导致PayServiceImpl失败。宿主中明明有IPay接口，为什么会找不到呢？

原因就在于我们的parent设置为了系统的pathClassLoader，前面分析了该类加载器的 DexPathList的路径为".",也就是什么都加载不到，接着会转由DexClassLoader去加载PayServiceImpl，要想成功加载PayServiceImpl，必须能够加载到IPay接口，而插件是以provided的方式依赖的PayService.jar，所以DexClassLoader无法成功加载PayServiceImpl，也就出现了log中所示内容。

（1）情况3

3. PayService.jar在PluginPro和HostPro均以compile的形式进行依赖，DexClassLoader的parent设置为系统默认的PathClassLoader

又出错了，这次报了java.lang.ClassCastException，首先需要明白，Java虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。

只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。

当我们调用loadClass的时候，很明显，PayServiceImpl和其实现的接口IPay都是由DexClassLoader在插件apk中加载的，而执行到IPay payService=(IPay)instance;时，宿主apk中的IPay是由应用默认的PathClassLoader加载的，二者并不是同一个类，所以强转时会报错。

通过以上三种情况，主要是为了更加深刻的理解类加载器的知识，同时得出我们在开发插件时，尽量避免出现插件和宿主中都compile依赖，只保证compile一次，其他provided即可，此外在自定义DexClassLoader的parent时要特别注意，不能随意设置，一般设置成应用默认的classLoader。

关于android的类加载器相关知识就介绍到里，也可能有的地方理解的不到位，欢迎多多交流。