Android热修复底层原理

Android热修复的技术已经出现一段时间了，市面上也有许多热修复的框架，我们只需要按照使用说明，一步一步集成即可，但是，作为一名有追求的程序员，无论使用任何技术，都需要先对技术有一定的了解，底层的原理是什么，这样使用起来才能够得心应手，并且在细节的处理上也许会更上一层楼。

什么是Android热修复

作为一名程序员，你一定会有一种感觉，就是每当我们发了一个版本，总是会提心吊胆，生怕出了什么问题，大问题就不用说了，马上加班改bug，重新发版，可是有些小问题，比如某个字写错了，怎么办？难道重新发一个版本？那用户体验实在是太差了。如果能有一种方法，让我们偷偷从服务器下载最新的某个类的代码，然后替换掉用户正在使用的类，不被用户发觉并且改好了bug，那不就太好了。这就是Android热修复技术。

Android热修复的原理

想要实现热修复，我们必须要先知道Android的打包原理，我们都知道最后我们在手机上安装的是一个后缀名是.apk的文件，这个.apk本身其实就是一个压缩文件，里面包含一个很重要的文件，是一个叫classes.dex的文件，这个dex文件里面包含了所有的代码，资源文件，清单文件，加密文件等等，当然，我们的有bug的类的字节码文件也在其中。也就是说，如果我们想办法把classes.dex文件中的错误的字节码文件，替换成我们从服务器端下载的正确的文件，那就大功告成了！

那么问题来了，我们的思路是直接将classes.dex直接替换掉，换成我们新的dex文件，可不可以呢？事实上这样是不行的，因为我们需要有一个主程序去执行下载，替换的过程，所以必须要保留classes.dex文件，那么我们生成一个新的classes2.dex文件，让主文件去替换新文件，就可以了。这也就是为什么，我们去解压微信的apk，会发现4个classes.dex文件，分别是classes1.dex，classes2.dex，classes3.dex，最后还有一个主包classes.dex，来执行其他三个dex文件的替换操作。

接下来我们改说说apk的构建构成了，首先aapt生成映射的R.java文件，接着调用aidl.exe，接着是javac生成字节码文件，接着是混淆proguard，然后是dx去编译成dex文件，最后生成未签名的apk，如果需要签名，再去调用signjar去生成签名的apk文件。其中跟我们热修复最相关的节点就是dx编译生成dex文件的过程，默认Android只会生成一个dex文件，我们需要去进行修改，生成属于我们自己的dex文件就可以了！

那么具体是如何做的呢？首先，dex文件中包含字节码文件，Android中有一个叫dexclassloader的类去加载这些类，里面有一个属性pathList，存放的是类的路径，就像我们使用命令行javac执行编译的时候，需要给一个路径一样，没有路径是没法加载的，pathList就是这个作用，而其中还有一个属性dexElements作用就是存放pathList里面的元素，将来类加载器在加载的时候就从这个dexElements里面找。而ClassLoader在加载类的时候有一个特点，就是先从dexElements里面的第一个元素找，找不到的话找第二个，再找不到就找第三个，以此类推，如果找到的话，后面如果还有一样的元素，就不会加载了，这样的话，我们的工作就是将自己的没有问题的dex文件，放到dexElements的最前面，大功就告成了。这也就是热修复的底层原理。

总结

Android实现热修复其实也不是Google工程师给出的建议，他们最初在设计系统的时候可能也没有想到我们会这么做，不然一开始就会给出这种策略，方便又使用。所以，只要我们敢想，敢干，就很有可能实现从0到1的突破。祝大家早日成为技术大拿！