1、前言

由于公司项目中使用到热修复技术，之前对这块技术知之甚少，所以有时间去学习了解了一下。

2、学习资源

2.1 热修复介绍

还是鸿洋老师的精彩讲解，中间引用了Andorid dex分包方案和QQ空间的热修复的技术贴。

2.2 其他相关知识

pathclassloader和dexclassloader的区别如下：
1.DexClassLoader和PathClassLoader都属于符合双亲委派模型的类加载器（因为它们没有重载loadClass方法）。也就是说，它们在加载一个类之前，回去检查自己以及自己以上的类加载器是否已经加载了这个类。如果已经加载过了，就会直接将之返回，而不会重复加载。
2.DexClassLoader和PathClassLoader其实都是通过DexFile这个类来实现类加载的。这里需要顺便提一下的是，Dalvik虚拟机识别的是dex文件，而不是class文件。因此，我们供类加载的文件也只能是dex文件，或者包含有dex文件的.apk或.jar文件。
3.PathClassLoader是通过构造函数new DexFile(path)来产生DexFile对象的；而DexClassLoader则是通过其静态方法loadDex（path, outpath, 0）得到DexFile对象。这两者的区别在于DexClassLoader需要提供一个可写的outpath路径，用来释放.apk包或者.jar包中的dex文件。换个说法来说，就是PathClassLoader不能主动从zip包中释放出dex，因此只支持直接操作dex格式文件，或者已经安装的apk（因为已经安装的apk在cache中存在缓存的dex文件）。而DexClassLoader可以支持.apk、.jar和.dex文件，并且会在指定的outpath路径释放出dex文件。

4.另外，PathClassLoader在加载类时调用的是DexFile的loadClassBinaryName，而DexClassLoader调用的是loadClass。因此，在使用PathClassLoader时类全名需要用”/”替换”.”

3、总结

通过资料的学习，我从如下几个方面进行总结：

3.1、热修复的目的：实现在不发布新版本的情况下修复app中存在的一些bug，从而降低生产成本。

3.2、热修复的原理：动态的将补丁（jar包）中包含的DexFile注入到ClassLoader的dexElements中。

3.3、热修复实现的步骤：

将修改后的类打包成dex文件，然后将该dex文件写入到app私有目录中的文件，接着用pathClassLoader和DexClassLoader分别获取原来的dexElements对象和补丁的dexElements对象并将两者合并，合并时将补丁的dexElements放在最前面。最后，将新的数组dexElements通过反射的方式设置给pathList。