从“0”到“1”手撸一个热修复框架
前言
热修复原理，这个一直是这几年来很热门的话题，在项目中使用的话，也基本要么是阿里系或者腾讯系的开源框架。但是作为一个光会使用的程序员是远远不够的。这篇文章会从dex分包的原因，原理，热修复的由来及原理为思路，手动写一个热修复的框架，这样感觉比光分析原理要更加深记忆。也是一片比较全面的文章。秉持着一blog一框架的原则，没有分开，关于热修复的所有知识点，都汇聚在这篇博客上，可能略长，希望大家能够认真看完。
先看原理，再撸代码
什么是dex分包
先了解下什么是dex分包，当我们把一个apk解压后，我们会发现有一个classes.dex的文件，它包含了我们项目中所有的class文件。但是随着业务越来越复杂，方法数也越来越多，当方法数超过一定范围后，就会导致项目编译失败。
因为一个dvm中存储方法id用的是short类型，所以就导致dex中方法不能超过65535个
那么如何解决这个问题尼？那就是dex分包方案。
2.1 分包的原理
就是将编译好的class文件，拆分打包成2个dex，绕过dex方法的限制，运行时，再动态加载第2个dex文件。
这样除了第1个dex文件外（正常apk中存在的唯一的dex文件），其他的所有dex文件都以资源的形式放到apk里面，并在Application的onCreate回调中通过系统的ClassLoader加载它们。
值得注意的是，在注入之前就已经引用到的类，则必须放到第一个dex文件中，否则会提示找不到该文件。
接下来我们就来看看，如何将第2个dex文件注入到系统中。
classLoader
在Android中，我们编译好的class文件，是需要加载到虚拟机才会被执行的，而这个加载的过程就是通过ClassLoader来完成的。
3.1 ClassLoader体系
看上图应该也能明白，我们第二个dex是以资源的形式存在的，所以我们要用到的classLoader是DexClassLoader。
DexClassPath：可以从一个jar包或者未安装的apk中加载dex
看下DexClassLoader是怎么加载class的，这段逻辑是在它的父类BaseDexClassLoader中，我们先看下这个类的源码。
– BaseDexClassLoader.java
public class BaseDexClassLoader extends ClassLoader {
// 需要加载的dex列表
private final DexPathList pathList;
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
// 使用pathList对象查找name类
Class c = pathList.findClass(name, suppressedExceptions);
return c;
}
}
这段代码很简单的，就是创建了个DexPathList对象，然后调用它的findClass方法，根据类名，寻找该类，那么我们看下DexPathList对象，它在DexClassLoader中。
– DexClassLoader.java
*package*/ final class DexPathList {
private static final String DEX_SUFFIX = ".dex";
private static final String JAR_SUFFIX = ".jar";
private static final String ZIP_SUFFIX = ".zip";
private static final String APK_SUFFIX = ".apk";
private final ClassLoader definingContext;
// ->> 注释1
private final Element[] dexElements;
public Class findClass(String name, List<Throwable> suppressed) {
// ->> 注释2
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
if (clazz != null) {
return clazz;
}
}
}
if (dexElementsSuppressedExceptions != null) {
suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
}
return null;
}
}
- 注释1：一个ClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组就是dexElements
- 注释2：当找类的时候，会按顺序遍历dex文件，然后从当前遍历的dex文件中找类，如果找到该类则返回，如果找不到从下一个dex文件继续查找
那么显而易见，我们就可以通过反射，强行的将一个外部的dex文件添加到此dexElements中，这样寻找起类来，就也可以从我们第2个dex中寻找了，这样就算是将我们第2个dex加载进去了。（代码在下面的实战中会写）
3.2 总结一下
1. 因为dvm中存储方法id用的是short类型，所以就导致dex中方法不能超过65535个，所以我们会将我们编译好的class文件，拆分打包成2个dex，绕过dex方法的限制，运行时再加载第2个dex。
2. 通过源码我们可知，一个ClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成了一个有序数组dexElements，在项目运行的过程中，我们所需用到的class，就是根据遍历dexElements去寻找的，将我们只需要将需要加载的dex文件，通过反射加入到dexElements数组中，就可以完成加载了。
这下知道了dex分包的原因和原理了吧，那么思考一个问题，如果在加载的过程中有2个一样的class文件，该怎么办？
其实从上述的代码我们可以知道，寻找一个class文件时，它会遍历dexElements数组，先从第一个dex中去寻找，找到就返回，找不到才从下一个dex继续找，那么其实就可以理解成
如果有两个重复的class，那么dex1.class会覆盖dex2.class
看到这个，聪明如我的你，有没有想到什么？
我们如果有个class里面有bug，我们只需要提供一个一样的class，并把它打包成dex，通过反射，放到dexElements最前端，那是不是就加载我们新的class，之前的有问题的class是不是就被覆盖了？没错，这就是热修复原理
热修复原理
这块知识，其实可以看下安卓App热补丁动态修复技术介绍，当然懒惰如你懒得看的话，那么就继续看咱们的，接下来的内容，实际上也是参考上面这篇文章的。
通过上面的推论，我们知道了，如果两个class相同，那么在前面的dex中的class，会覆盖后面dex中与它一样的class。如下图：
那么热补丁的原理就是，当修改好了一个类的bug后，将这个类打包成dex，比如叫patch.dex，再通过反射，将该dex放置在dexElements的最前面，那么这个patch中我们修改的class就覆盖了之前出现问题的class。如下图
撸代码
源码很简单，点击按钮蹦出一个toast MainActivity.java
@Override
public void onClick(View v) {
switch (v.getId()){
case R.id.btn:
MyLogic myLogic = new MyLogic();
Toast.makeText(MainActivity.this, myLogic.toMsg(), Toast.LENGTH_SHORT).show();
break;
}
}
public class MyLogic {
public String toMsg(){
return "老板很抠门";
}
}
只是随口一说，爽归爽，但是不能让老板知道，老板用的时候，得给他手机打个补丁。只能让别人看，不能让老板自己看到。
5.1 制作补丁
-
修改源码：
首先，我们先将代码修正过来，将“老板很抠门”改成“老板人真好”，然后重新编译项目。 -
找到MyLogic.class 文件：
位置如下图
- 创建文件夹：
路径和包名一样，然后将找到的class文件复制进去
-
打jar包：
在外层目录下，我是在temp里面创建的包路径，所以先切换到temp目录下 cd temp 进入外层目录后，再执行打包命令：jar -cvf my.jar com
注：jar命令是在jdk的bin目录里面，不要忘记配置环境变量
-
打dex包：
执行命令
dx --dex --output=my_dex.jar my.jar如下图所示
好了，大功告成，将我们的my_dex.jar 放到sdcard上就行了，一般是放在服务器提供下载，这里为了简单使用。
5.2 加载补丁
还记得上面我们说的逻辑吗？（不记得看上面的4）
咳咳，虽然很啰嗦，但是吧，还得说 通过DexClassLoader加载我们的补丁（my_dex.jar）,然后放到dexElements的前面，替换原有的错误。
思路
- 反射获取BaseDexClassLoader对象，然后获取它的成员变量pathList，pathList为DexClassLoader的内部类，里面有成员变量dexElements，获取它。
- 创建DexClassLoader对象，加载我们的补丁文件（my_dex.jar）, 并通过反射获取它父类的pathList对象，依次获取补丁包加载后生成的dexElements。
- 将2个dexElements通过反射合并，生成新的dexElements
- 将新生成的dexElements，通过反射，替换掉当前加载的dexElements。
5.3 撸代码
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
// 获取我们补丁的路径
String dexPath = Environment.getExternalStorageDirectory().getAbsolutePath()+"/my_dex.jar";
// 加载补丁
try {
inject(dexPath);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* 加载补丁
* */
private void inject(String dexPath) throws Exception{
// ================= 1.获取classes的dexElements ===================
// 反射获取 BaseDexClassLoader
Class<?> mBaseDexClassLoader = Class.forName("dalvik.system.BaseDexClassLoader");
// 反射获取 BaseDexClassLoader 中的 pathList
Field pathListField = mBaseDexClassLoader.getDeclaredField("pathList");
pathListField.setAccessible(true);
Object pathList = pathListField.get(getClassLoader());
// 反射获取 pathList 中的 dexElements
Field dexElementsField = pathList.getClass().getDeclaredField("dexElements");
dexElementsField.setAccessible(true);
Object dexElements = dexElementsField.get(pathList); // pathList为dexClassLoader中的内部类
// ================= 2.获取我们的补丁中的dexElements ===================
String dexopt = getDir("dexopt", 0).getAbsolutePath();
DexClassLoader mDexClassLoader = new DexClassLoader(dexPath, dexopt, dexopt, getClassLoader());
// 反射获取加载我们补丁后 dexClassLoader 中的 pathList
Field myPathListField = mBaseDexClassLoader.getDeclaredField("pathList");
myPathListField.setAccessible(true);
Object myPathList = myPathListField.get(mDexClassLoader);
// 反射获取 加载我们补丁后，pathList 中的 dexElements
Field myDexElementsField = myPathList.getClass().getDeclaredField("dexElements");
myDexElementsField.setAccessible(true);
Object myDexElements = myDexElementsField.get(myPathList);
// ================= 3.合并数组 ===================
Object newDexElements = mergeArray(myDexElements, dexElements);
// ================= 4.将合并后的数组赋值给我们的app的classLoader ===================
dexElementsField.set(pathList, newDexElements);
}
/**
* 通过反射合并两个数组
*/
private Object mergeArray(Object firstArr, Object secondArr) {
int firstLength = Array.getLength(firstArr);
int secondLength = Array.getLength(secondArr);
int length = firstLength + secondLength;
Class<?> componentType = firstArr.getClass().getComponentType();
Object newArr = Array.newInstance(componentType, length);
for (int i = 0; i < length; i++) {
if (i < firstLength) {
Array.set(newArr, i, Array.get(firstArr, i));
} else {
Array.set(newArr, i, Array.get(secondArr, i - firstLength));
}
}
return newArr;
}
}
结果
在源码不变的基础上，加载补丁前和加载补丁后的对比
踩坑
可能是SDK比较新的缘故，所以并未发生网络上提到的CLASS_ISPREVERIFIED问题，简单说一下这个问题，在class替换加载的过程中，虚拟机会将dex优化成odex后才拿去执行。在这个过程中会对所有class一个校验。
假设A类在它的static方法，private方法，构造函数，override方法中直接引用到B类。如果A类和B类在同一个dex中，那么A类就会被打上CLASS_ISPREVERIFIED标记，替换的话，会抛出异常
6.1 解决办法
这个规则其实也可以理解成，只要在static方法，构造方法，private方法，override方法中直接引用了其他dex中的类，那么这个类就不会被打上CLASS_ISPREVERIFIED标记。
那么我们只需要让所有类都引用其他dex中的某个类就可以了
比如说 在所有类的构造函数中插入这行代码 System.out.println(AntilazyLoad.class); 这样当安装apk的时候，classes.dex内的类都会引用一个在不相同dex中的AntilazyLoad类，这样就防止了类被打上CLASS_ISPREVERIFIED的标志了，只要没被打上这个标志的类都可以进行打补丁操作。
源码：
https://github.com/liuyangbajin/android_framework
上述逻辑主要是来源于QQ空间热修复逻辑
感谢大家能耐着性子看完啰里啰嗦的文章
在这里我也分享一份私货，自己收录整理的Android学习PDF+架构视频+面试文档+源码笔记，还有高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习
如果你有需要的话，可以点赞+评论，关注我，然后加我VX：15388039515 我发给你
（或关注微信公众号“Android开发之家”回复【资料】免费领取）
推荐阅读