Android 热修复原理

关于热修复的原理，其实网上有很多文章的讲述。但是原理都是一致的，所以实现起来差异不是很大。
在Android的ClassLoader体系中，Android中加载类都是使用PatchClassLoader和DexClassLoader*,他们有什么区别呢？
其实很容易说明：
*DexClassLoader是可以用于加载apk文件或jar文件的。
*PathClassLoader只能加载dex格式文件。
一、Dex的加载。
无论是DexClassLoader还是PathClassLoader都是BaseDexClassLoader的子类，在BaseDexClassLoader初始化的时候就会加载dexPath下的classes.dex文件。然后放入DexPathList中

加载dex到pathList

那么DexPathList是什么呢？我们一起看一看他的构造函数

这里写图片描述

原来是将我们传入的DexPath,加载到当前的dexElements中去了。
这样我们app里的dex文件就被加载到davlik里了，那么他是怎么去find的Class呢？

这里写图片描述

这样的话，只要我们修改dexElements中的顺序，将我们的patchjar放到数组的第一个，这样就会加载我们patch.jar里面的类，而代替之前存有bug的类。
对，他的原理就是这么简单。
二、修改顺序的验证。
我们根据这个来试验一下，看看是否能够成功。

这里写图片描述

失败了，报错了。我们根据异常信息追踪一下

这里写图片描述

这里写图片描述

在校验是否在同一个dex的时候做了一个判断

if (!fromUnverifiedConstant &&
IS_CLASS_FLAG_SET(referrer, CLASS_ISPREVERIFIED))

那么这个CLASS_ISPREVERIFIED是什么时候设置的呢？虚拟机在把dex优化成odex的过程中会对该dex的所有class一个校验。

这里写图片描述

那么他是怎么dvmVerifyClass 的呢？

这里写图片描述

校验class的static 、private、 构造函数和虚函数。也就是说会根据构造函数或者静态函数，私有函数。然后这个类会被打上CLASS_ISPREVERIFIED。
所以当我们的A.class调用到B.class的时候 只会在同一个dex中查找,如果dex不相同就会抛出来我们之前遇见的异常了。

那么怎么跳过校验呢？
很简单只要在我们的a.dex中调用b.dex的某一个类就可以了，这样就防止类被打上CLASS_ISPREVERIFIED。
QQ 空间的做法是在所有类的构造函数加入了

if (ClassVerifier.PREVENT_VERIFY) {
System.out.println(AntilazyLoad.class); }

这样当校验class的时候会引用一个在不同dex的AntilazyLoad类。然后在启动的时候AntilazyLoad的dex包要先加载进来，否则会找不到AntilazyLoad类的。还需要注意一点就是Application是不能加入这段代码的，因为这样就是在加载AntilazyLoad之前就使用了。

总结：
在ClassLoader中有一个存储dex的数组dexElements，修改dexElements的顺序可以决定优先选取哪个dex的class。这样就可以实现热修复的效果。但是dex在优化的过程中会进行class的校验，给每一个class打上了一个CLASS_ISPREVERIFIED的标签，在
调用的时候会根据该标签判断所在的class是否是同一个dex如果不是是会抛出异常导致程序停止。所以我们需要防止类被打上CLASS_ISPREVERIFIED。就需要在我们的class中调用另一个dex的class，所以我们选择在构造函数中加上另一个dex的引用。之所以选择构造函数是因为他不增加方法数，一个类即使没有显式的构造函数，也会有一个隐式的默认构造函数。

这就是热修复的原理了，下一次我会和大家一起学习一下怎么样根据热修复的原理进行实现。