刚开始听说热修复的时候,我的脸上充满着不可思议,只觉得这是一个黑科技。
但是当我逐渐深入了解之后,发现这确实是一门复杂的知识,但却不是那么高不可攀且难懂的东西。
热修复的实现种类繁多,各种框架也层出不穷,不是一篇文章就能讲清楚的。
所以这篇文章的目的很简单,就是带你实现一个简单的代码热修复,亲身感受一下热修复的神奇。
首先热修复指的是三块:代码,资源和so库。
对这三块的修复有分别对应的方法,而我们这篇文章的关注点只在 代码热修复 上。
那么代码热修复的方式大致分为两种:
1.底层替换方式,可立即生效。
2.类加载方式,需重启才能生效。
感兴趣的朋友可以阅读:《深入探索Android热修复技术原理》 这本书,里面有对各种技术的详细介绍。
这篇文章选择的修复方式是 类加载方式,因为这个方案是在Java层实现的,加上核心逻辑非常简单,所以便于我们的理解。
为了更直观的讲述热修复的实现,我们先构建一个具体的场景:
假设你有个页面,页面中有一个按钮,点击这个按钮,弹出一个Toast,内容为 “我是一个BUG” 。
效果如下:
image.png
现在假设我们修复了这个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 文件夹,如图所示:
image.png
然后我们将修复了BUG的.class文件连带着包名拷贝出来,例如我这边修复的文件是MainActivity.class,那么我们需要把 com.chentian.androidhotloadtest.bug.MainActivity.class 整个都拷贝出来
接下来我们需要使用 Android SDK 里的 dk 工具,将其转换成dex文件,该工具位于 build-tools里,建议将其添加进环境变量,方便使用:
image.png
那么接下来我们输入如下命令:
image.png
该命令会将MainActivity.class 文件转换成 hot.dex 文件。具体的命令使用方法可以查阅 dex --help 。
在正常的热修复中,补丁文件是通过服务器下发的,这里为了方便演示,我们直接把 hot.dex 文件放入手机的 Download目录下的hotload文件夹中(注意要获取存储权限),那么我们之前的代码中的 "dex文件路径" 就需要就改成:
PathClassLoader dexClassLoader = new PathClassLoader( Environment.getExternalStoragePublicDirectory("Download").getAbsolutePath() + "/hotload/hot.dex" , parentClassLoader );
image.png
2.热修复的时机
或许你已经发现了,我们这个方法并不是直接将本地的 dex文件 偷梁换柱,而是让其先于 旧dex文件 加载,这样就会使用 补丁dex 中新的代码了。
那么我们进行修复的时机,肯定是要在 旧dex文件中的有问题的类 被加载之前。如果有问题的类已经被加载,那么它将无法被卸载,哪怕你进行了替换,程序使用的依然还是 旧的有问题的类。
所以在这里,我们将修复的时机放在Application中,这是App的初始化入口,它肯定会先于 MainActivity 。
效果
完成以上步骤后,我们来查看一下效果
image.png
我们的代码已经被修复啦~
结束
感谢大家的阅读,希望和大家一起进步,如果有任何疑问,欢迎在评论区留言,谢谢~
网友评论