热修复的一些理解

对于热修复这个概念，第一次听到是在苹果制裁腾讯的时候听到的，后来就在很多的ap中都有看到，就看了下热修复相关的博客。

从原理来看，主要是利用jvm的ClassLoader加载机制，这里使用的是PathClassLoader及DexClassLoader这两个类来实现热修复的。

这两个类都继承自BaseClassLoader，他们的实现差别就在构造函数上的一个参数，而具体的功能实现都放在BaseClassLoader中，对于我们的app编出来的classes.dex文件，使用的是PathClassLoader来进行的类加载。而热修复则是利用DexClassLoader，利用该类将我们用于修复的dex文件加载进来，并且与现有的PathClassLoader加载得到的当前app所对应的class文件进行合并，放到同一个数组里面，因为ClassLoader是遍历数组来找到要执行的类，所以，这里只需要将修复的类，放到类元素的数组的前面，让ClassLoader提前得到我们用于修复的类就可以完成热修复。

这里利用ClassLoader加载机制，将修复所用的补丁，动态的加到ClassLoader所维护的elements数组的头部，让ClassLoader提前找到修复用的class，而不是一开始我们app自带的class来完成bug的修复。通过少量的内存空间来换取用户频繁升级的用户体验，是好呢？还是坏呢？

实现思路：

1. 利用SDK中的dx工具生成补丁dex。

2.写代码获取当前类加载器中的dexPathList；

3.得到dexPathList所对应的Elements；

4.利用DexClassLoader将补丁dex加载进来。

5.将补丁dex Elements与上面获取到的Elements进行数组合并，补丁Elements要放在数组的靠前位置。

6.用新得到的Elements数组替换原ClassLoader的Elements数组。

参考链接：https://blog.csdn.net/csdn_lqr/article/details/78534065