刚开始听说热修复的时候，我的脸上充满着不可思议，只觉得这是一个黑科技。
但是当我逐渐深入了解之后，发现这确实是一门复杂的知识，但却不是那么高不可攀且难懂的东西。
热修复的实现种类繁多，各种框架也层出不穷，不是一篇文章就能讲清楚的。
所以这篇文章的目的很简单，就是带你实现一个简单的代码热修复，亲身感受一下热修复的神奇。
首先热修复指的是三块：代码，资源和so库。
对这三块的修复有分别对应的方法，而我们这篇文章的关注点只在 代码热修复 上。
那么代码热修复的方式大致分为两种：
1.底层替换方式，可立即生效。
2.类加载方式，需重启才能生效。
感兴趣的朋友可以阅读：《深入探索Android热修复技术原理》 这本书，里面有对各种技术的详细介绍。
这篇文章选择的修复方式是 类加载方式，因为这个方案是在Java层实现的，加上核心逻辑非常简单，所以便于我们的理解。
为了更直观的讲述热修复的实现，我们先构建一个具体的场景：
假设你有个页面，页面中有一个按钮，点击这个按钮，弹出一个Toast，内容为 “我是一个BUG” 。
效果如下：
现在假设我们修复了这个BUG，那么按照正常的流程，我们需要打包然后发布。用户那边的流程则是下载新的安装包。
虽然是BUG，但是为了这么一行代码而进行打包发布的操作，显得过于笨重了。对用户的体验也不好。
于是热修复技术出现了。他可以在不重新安装的前提下，更新你的代码。
那么这样的操作是如何实现的呢？我们一起来看看Android加载代码的流程。
我们在编写Android应用的时候，代码是一个个的.java文件，他们会先被编译成.class文件，再被转换成.dex文件，而Android加载APP所需要的就是dex文件。
我们热修复所做的事情就是用新的修复了bug的dex文件，替换掉旧的dex文件即可。所以我们可以从dex文件的加载机制入手。
Android加载dex文件的类有DexClassLoader和PathClassLoader两种，这两个类并没有什么本质区别，无非就是构造时所需的参数不太一样。他们都会调用他们的父类的构造方法进行构建，也就是 BaseDexClassLoader 的构造方法。
如果对这部分代码感兴趣，大家可以上这个网站查看源码：Android Code Search
在源码中我们可以发现，当调用 BaseDexClassLoader 的构造函数的时候，会生成 DexPathList ，而DexPathList构造函数里面有个 dexElements 数组，存放着的就是App所需的Dex文件
当App加载dex文件时，就会从dexElements数组里顺序寻找。那么我们其实只要把补丁dex文件放到dexElements数组的头部，就可以先一步被加载。由于类加载的双亲委派机制，已经被加载的类不会被重复加载。借此我们就实现了代码的热修复。
思路有了，接下去就是具体的实现，我们按照步骤一个个来。
1.加载补丁dex
BaseDexClassLoader parentClassLoader = (BaseDexClassLoader) context.getClassLoader();
PathClassLoader dexClassLoader = new PathClassLoader( "dex文件路径" , parentClassLoader );
2.通过反射得到补丁的dexElements
Field pathListField = Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");
pathListField.setAccessible(true);
Object pathList = pathListField.get(dexClassLoader);
Field dexElementsField = pathList.getClass().getDeclaredField("dexElements");
dexElementsField.setAccessible(true);
Object newDexElements = dexElementsField.get(pathList);
3.通过反射得到原本的dexElements
Object parentPathList = pathListField.get(parentClassLoader);
Field parentDexElementsField = parentPathList.getClass().getDeclaredField("dexElements");
parentDexElementsField.setAccessible(true);
Object baseDexElements = parentDexElementsField.get(parentPathList);
4.合并两个dexElements，并且把补丁的dexElements放在前面
Class localClass = newDexElements.getClass().getComponentType();
int firstArrayLength = Array.getLength(newDexElements);
int allLength = firstArrayLength + Array.getLength(baseDexElements);
Object allDexElements = Array.newInstance(localClass, allLength);
for (int k = 0; k < allLength; ++k) {
if (k < firstArrayLength) {
Array.set(allDexElements, k, Array.get(newDexElements, k));
} else {
Array.set(allDexElements, k, Array.get(baseDexElements, k - firstArrayLength));
}
}
5.用合并完成的dexElements替换掉当前的dexElements
Field localField = parentPathList.getClass().getDeclaredField("dexElements");
localField.setAccessible(true);
localField.set(parentPathList, allDexElements);
注意点：
1.补丁dex文件如何获得：
首先我们修复完代码上的bug，例如我们上述的例子中，将Toast弹出的提示文案改为 “ 我被修复啦 ” ，就表示我们已经修复了bug，接下来我们点击Android Studio 上 Build 选项，点击 Rebuild Project 。
接下来我们的左侧栏中会多出一个 build 文件夹，如图所示：
然后我们将修复了BUG的.class文件连带着包名拷贝出来，例如我这边修复的文件是MainActivity.class，那么我们需要把 com.chentian.androidhotloadtest.bug.MainActivity.class 整个都拷贝出来
接下来我们需要使用 Android SDK 里的 dk 工具，将其转换成dex文件，该工具位于 build-tools里，建议将其添加进环境变量，方便使用：
那么接下来我们输入如下命令：
该命令会将MainActivity.class 文件转换成 hot.dex 文件。具体的命令使用方法可以查阅 dex --help 。
在正常的热修复中，补丁文件是通过服务器下发的，这里为了方便演示，我们直接把 hot.dex 文件放入手机的 Download目录下的hotload文件夹中（注意要获取存储权限），那么我们之前的代码中的 "dex文件路径" 就需要就改成：
PathClassLoader dexClassLoader = new PathClassLoader( Environment.getExternalStoragePublicDirectory("Download").getAbsolutePath() + "/hotload/hot.dex" , parentClassLoader );
2.热修复的时机
或许你已经发现了，我们这个方法并不是直接将本地的 dex文件 偷梁换柱，而是让其先于 旧dex文件 加载，这样就会使用 补丁dex 中新的代码了。
那么我们进行修复的时机，肯定是要在 旧dex文件中的有问题的类 被加载之前。如果有问题的类已经被加载，那么它将无法被卸载，哪怕你进行了替换，程序使用的依然还是 旧的有问题的类。
所以在这里，我们将修复的时机放在Application中，这是App的初始化入口，它肯定会先于 MainActivity 。
效果
完成以上步骤后，我们来查看一下效果
我们的代码已经被修复啦~
结束
感谢大家的阅读，希望和大家一起进步，如果有任何疑问，欢迎在评论区留言，谢谢~