过去的一两年android插件化，热修复等技术发展迅速，并且还在持续的探索中，也许插件化技术最终会在android工程中退出舞台，但里面包含的技术是非常值得我们学习的。最近，会就android动态加载等技术进行研究总结。
本篇文章作为插件化框架第一篇，首先分析android中的类加载器，并实现在android中动态加载一个外部apk中的类，从以下三部分进行介绍。
一. java类加载器双亲委派机制
二. android中的类加载器介绍
三. android中动态加载实现类加载
一. java类加载器双亲委派机制
学过java的同学都知道类加载器是采用双亲委派机制来进行类加载的。双亲委派机制从ClassLoader.java可以清晰的看出来。
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class c = findLoadedClass(name);//判断类是否已经加载过
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);//父类加载器优先加载
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);//调用当前类加载器的findClass方法进行加载
// this is the defining class loader; record the stats
}
}
return c;
}
简单来说，java的双亲委派机制分为三个过程，在ClassLoader的loadClass方法中会先判断该类是否已经加载，若加载了直接返回，若没加载过则先调用父类加载器的loadClass方法进行类加载，若父类加载器没有找到，则会调用当前正在查找的类加载器的findClass方法进行加载。这里就涉及到类加载器的两个很重要的方法loadClass和findClass。在自定义类加载器中会涉及到这两个方法，具体二者有什么区别呢？
由上文的双亲委派机制的代码可以看出来，如果想保证自定义的类加载器符合双亲委派机制，则覆写findClass方法；如果想打破双亲委派机制，则覆写loadClass方法。，双亲委派机制保证了同一个类不会被重复加载，但是某些情况下，是需要限定名相同的多个类被多个类加载器分别加载的，比如容器插件应用场景。这时就可以在自定义类加载器时覆写loadClass方法，摆脱双亲委派机制来直接加载。例如：
public class MyClassLoader extends DexClassLoader{
public MyClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
super(dexPath, optimizedDirectory, librarySearchPath, parent);
}
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
if(xxx){//条件判断是否自己加载
return this.loadClass(name);
}else{//双亲委派机制加载
return super.loadClass(name, resolve);
}
}
}
二. 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());
打印结果：
02-14 12:37:49.161 22341-22341/com.ljj.host I/ljj: Context的类加载器：java.lang.BootClassLoader@a645091
02-14 12:37:49.162 22341-22341/com.ljj.host I/ljj: TextView的类加载器： java.lang.BootClassLoader@a645091
可见系统的类都是由BootClassLoader加载完成。
Log.i("ljj", "classLoader:"+getClassLoader());
02-14 13:19:23.730 20518-20518/com.ljj.host 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());
02-14 13:32:01.747 4482-4482/com.ljj.host I/ljj: classLoader:dalvik.system.PathClassLoader[DexPathList[[directory "."],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]]
可见调用ClassLoader.getSystemClassLoader()得到的也是一个PathClassLoader，但是DexPathList为“.”。这就奇怪了，为什么路径会为“.”,有必要查看一下源码。
static private class SystemClassLoader {
public static ClassLoader loader = ClassLoader.createSystemClassLoader();
}
private static ClassLoader createSystemClassLoader() {
String classPath = System.getProperty("java.class.path", ".");
String librarySearchPath = System.getProperty("java.library.path", "");
return new PathClassLoader(classPath, librarySearchPath, BootClassLoader.getInstance());
}
从源码中可以看出，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。先从源码的角度进行简单分析。
public class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory,
String librarySearchPath, ClassLoader parent) {
super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
}
}
DexClassLoader的源码很简单，只包含一个构造函数，看来所有的工作都是在BaseDexClassLoader中完成的。这里再看BaseDexClassLoader前，先说一下DexClassLoader构造函数的四个参数。
dexPath：是加载apk/dex/jar的路径
optimizedDirectory：是dex的输出路径(因为加载apk/jar的时候会解压除dex文件，这个路径就是保存dex文件的)
librarySearchPath：是加载的时候需要用到的lib库，这个一般不用，可以传入Null
parent：给DexClassLoader指定父加载器
下面继续分析BaseClassLoader。
public class BaseDexClassLoader extends ClassLoader {
private final DexPathList pathList;
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
String librarySearchPath, ClassLoader parent) {
super(parent);
this.pathList = new DexPathList(this, dexPath, librarySearchPath, optimizedDirectory);
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
Class c = pathList.findClass(name, suppressedExceptions);
if (c == null) {
ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
for (Throwable t : suppressedExceptions) {
cnfe.addSuppressed(t);
}
throw cnfe;
}
return c;
}
可以看出，DexClassLoader会通过传入的路径构造出一个DexPathList对象，作为pathList。从findClass方法可以看出来加载的类都是从pathList中查找。至于DexPathList对象的源码就不往下具体分析了，简单的理解就是将每个dex都构建成Element元素，放入到dexElements数组中，多说一句，这个dexElements数组的用处很大，MultiDex方案以及由此衍生出的QQ空间热更新方案都是通过改变dexElements数组的元素位置来实现的。感兴趣的同学可以去学习一下。
三. android中动态加载实现类加载
类加载器知识介绍完毕后，我们来具体实现利用DexClassLoader来动态加载一个apk中的类。最简单的实现方式，我们可以将一个java文件打包成jar或者转化成dex后压缩成apk，然后利用DexClassLoader加载后，反射调用里面的方法来验证效果，不过这个实例不太好说明问题，而且在项目中我们一般也不这样用。
在项目中我们可能更多的是这样使用，一个插件工程，一个宿主工程，二者间的联系通过公共接口来完成。下面来具体操作以下。
第一步：将接口打包成jar
我们新建一个接口，打包出PayService.jar。
public interface IPay {
public void pay(int money);
public String getOrder(String userName);
public String getUserName();
}
我电脑里装有eclipse，打jar包非常方便。如果没有安装eclipse，也可以用jar命令或者gradle任务来完成。
第二步：新建一个android工程，命名为PluginPro
将PayService.jar放入libs目录，新建一个PayServiceImpl类实现IPay接口，为了方便起见，具体实现中只打印了log。
public class PayServiceImpl implements IPay {
@Override
public void pay(int money) {
Log.i("ljj", "pay: "+money+" 元");
}
@Override
public String getOrder(String s) {
return "0001";
}
@Override
public String getUserName() {
return "ljj";
}
}
以compile的形式打包进apk。
compile fileTree(include: ['*.jar'], dir: 'libs')
第三步：新建一个android工程，命名为HostPro
将PluginPro工程生成的apk放入assets目录下，至于为什么放入到assets目录，目前插件框架中的插件都是放入到assets目录上进行打包的，这里虽然不存在插件框架，但是尽量模拟一下这种动态加载的场景。我们分为以下几种情况进行分析。
1. PayService.jar在PluginPro和HostPro均以compile的形式进行依赖，DexClassLoader的parent设置为应用默认的PathClassLoader
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//创建apk加载路径
String src=this.getFilesDir().getAbsolutePath()+ File.separator+"plugin.apk";
//作为odex的释放路径
String des= this.getFilesDir().getAbsolutePath()+ File.separator+"plugin"+File.separator;
try {
copyPlugin(src);//将assets下的插件apk拷贝到src路径下
//创建DexClassLoader,parent指定为应用默认的PathClassLoader
DexClassLoader classLoader=new DexClassLoader(src,des,null,getClassLoader());
Class class1=classLoader.loadClass("com.ljj.plugin.serviceimpl.PayServiceImpl");
Object instance=class1.newInstance();
IPay payService=(IPay)instance;
String userName=payService.getUserName();
String order=payService.getOrder("ss");
payService.pay(10);
Log.i("ljj", "userName: "+userName);
Log.i("ljj", "order: "+order);
} catch (Exception e) {
e.printStackTrace();
}
}
private void copyPlugin(String path) throws Exception{
InputStream in=this.getAssets().open("app-release-unsigned.apk");
OutputStream os=new FileOutputStream(path);
byte[] temp=new byte[1024];
int len=-1;
while((len=in.read(temp))!=-1){
os.write(temp,0,len);
}
in.close();
os.flush();
os.close();
}
}
使用android5.0系统的手机进行测试一把，结果如下，能够正常运行，正常调用到了插件apk中的函数：
02-15 16:21:04.750 8875-8875/com.ljj.host I/art: Can not find class: Lcom/ljj/plugin/serviceimpl/PayServiceImpl;
02-15 16:21:04.750 8875-8875/com.ljj.host I/ljj: pay: 10 元
02-15 16:21:04.750 8875-8875/com.ljj.host I/ljj: userName: ljj
02-15 16:21:04.750 8875-8875/com.ljj.host I/ljj: order: 0001
保持代码不变，又搞了个android4.2系统的手机测试一把，结果挂了：
02-15 08:50:32.346 3897-3897/? E/AndroidRuntime: FATAL EXCEPTION: main
java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
at dalvik.system.DexFile.defineClass(Native Method)
at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:211)
at dalvik.system.DexPathList.findClass(DexPathList.java:313)
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:51)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
at com.ljj.host.MainActivity.onCreate(MainActivity.java:35)
我们来分析一下为什么出现这种结果。首先在插件apk和宿主apk中都包含了IPay接口，我们定义的DexClassLoader指定的parent为应用默认的PathClassLoader，两个classLoader的DexPathList的路径如下所示。之所以出现这种原因可能是art和Dalvik虚拟机的内部加载细节的差异。下面针对两种情况进行分析。
02-15 09:27:28.020 6666-6666/? I/ljj: onCreate: dalvik.system.DexClassLoader[DexPathList[[zip file "/data/data/com.ljj.host/files/plugin.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]]
02-15 09:27:28.020 6666-6666/? I/ljj: onCreate: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.ljj.host-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.ljj.host-1, /vendor/lib, /system/lib]]]
在art虚拟机中，当我们执行loadClass("com.ljj.plugin.serviceimpl.PayServiceImpl");时，根据双亲委派机制，PathClassLoader会先在宿主apk中查找，此时肯定找不到"PayServiceImpl",接着由DexClassLoader从插件apk中查找PayServiceImpl，毫无疑问，可以查找PayServiceImpl，同时发现其实现了IPay接口，此时仍然会由PathClassLoader去宿主apk中查找，很明显可以找到IPay接口，所以IPay接口是由应用的PathClassLoader加载的。这样就正常的完成了整个类加载过程。
在dalvik虚拟机中，虚拟机在首次加载dex的时候，会进行dexopt过程，进行预校验。具体来解释下抛出此异常的原因。当一个class文件和其直接引用的类在同一个dex中时，就会被打上CLASS_ISPREVERIFIED标记，而如果加载过程中，发现该类和其引用又不是在同一个dex中加载的，此时就会抛出该异常，该异常是由Resolve.cpp的dvmResolveClass函数定义的。在本文的例子中，插件apk中，PayServiceImpl引用了IPay接口并且他们都在同一个插件dex中，所以PayServiceImpl会被标记CLASS_ISPREVERIFIED，而IPay接口由双亲委派机制可以看出是由PathClassLoader在宿主apk中加载到的，此时虚拟机会认为IPay接口不在插件dex中，与之前标记的CLASS_ISPREVERIFIED冲突，从而抛出异常。很明显，当A类和其引用的B类如果不在同一个dex中，那么A类就不会被打上CLASS_ISPREVERIFIED标记，那么我们插件采用provided方式，则虚拟机会发现插件中没有IPay类，就不会对PayServiceImpl打标记了，也就不会再抛异常了。可参考文章安卓App热补丁动态修复技术介绍。这个问题就是QZone热更新方案所遇到的坑。有兴趣的可以了解下。
所以我们在插件开发中，尽量保证只在宿主（插件）中使用compile方式，而在插件可以（宿主）中使用provided进行依赖，就可以完全避免java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation的产生。
下面我们使用分析好的方式继续探索。
2. PayService.jar在PluginPro采用provided方式，在HostPro中以compile的形式进行依赖，DexClassLoader的parent设置为系统默认的PathClassLoader
代码与上文中保持不变，可以正确的完成动态加载，但是我们尝试着将parent设置为ClassLoader.getSystemClassLoader()
DexClassLoader classLoader=new DexClassLoader(src,des,null,ClassLoader.getSystemClassLoader());
再次运行，会发现结果又报错了。。。。
02-15 21:53:15.820 3070-3070/com.ljj.host W/System.err: java.lang.ClassNotFoundException: Didn't find class "com.ljj.plugin.serviceimpl.PayServiceImpl" on path: DexPathList[[zip file "/data/data/com.ljj.host/files/plugin.apk"],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]
02-15 21:53:15.820 3070-3070/com.ljj.host W/System.err: Caused by: java.lang.ClassNotFoundException: Didn't find class "com.ljj.test.interfaces.IPay" on path: DexPathList[[zip file "/data/data/com.ljj.host/files/plugin.apk"],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]
看log可以大致猜出来是由于没有加载到IPay接口，导致PayServiceImpl失败。宿主中明明有IPay接口，为什么会找不到呢，原因就在于我们的parent设置为了系统的pathClassLoader，前面分析了该类加载器的 DexPathList的路径为".",也就是什么都加载不到，接着会转由DexClassLoader去加载PayServiceImpl，要想成功加载PayServiceImpl，必须能够加载到IPay接口，而插件是以provided的方式依赖的PayService.jar，所以DexClassLoader无法成功加载PayServiceImpl，也就出现了log中所示内容。
3. PayService.jar在PluginPro和HostPro均以compile的形式进行依赖，DexClassLoader的parent设置为系统默认的PathClassLoader
02-15 22:16:35.750 19600-19600/com.ljj.host W/System.err: java.lang.ClassCastException: com.ljj.plugin.serviceimpl.PayServiceImpl cannot be cast to com.ljj.test.interfaces.IPay
02-15 22:16:35.750 19600-19600/com.ljj.host W/System.err: at com.ljj.host.MainActivity.onCreate(MainActivity.java:39)
02-15 22:16:35.750 19600-19600/com.ljj.host W/System.err: at android.app.Activity.performCreate(Activity.java:6013)
又出错了，这次报了java.lang.ClassCastException，首先需要明白，Java虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。当我们调用loadClass的时候，很明显，PayServiceImpl和其实现的接口IPay都是由DexClassLoader在插件apk中加载的，而执行到IPay payService=(IPay)instance;时，宿主apk中的IPay是由应用默认的PathClassLoader加载的，二者并不是同一个类，所以强转时会报错。
通过以上三种情况，主要是为了更加深刻的理解类加载器的知识，同时得出我们在开发插件时，尽量避免出现插件和宿主中都compile依赖，只保证compile一次，其他provided即可，此外在自定义DexClassLoader的parent时要特别注意，不能随意设置，一般设置成应用默认的classLoader。
关于android的类加载器相关知识就介绍到里，也可能有的地方理解的不到位，欢迎多多交流。
目前本人在公司负责热修复相关的工作，主要是基于robust的热修复相关工作。感兴趣的同学欢迎进群交流。
