Android热修复学习之旅开篇——热修复概述

Android热修复技术无疑是Android领域近年来最火热的技术之一，同时也涌现了各种层出不穷的实现方案，如QQ空间补丁方案、阿里AndFix以及微信Tinker等等，从本篇博客开始，计划写一个系列博客专门介绍热修复的相关内容，本系列博客将一一介绍这些框架的原理和源码分析，作为本系列的开篇，本篇博客将对热修复技术进行一个概述，并对以上几种方案进行对比。

为什么会出现热修复？

简单来说，以前出现bug的时候，都要重新发包对bug进行修复，这样带来的缺点是明显的，需要用户重新升级app,覆盖率太慢，成本太高。所以就出现了热修复技术，通过打补丁的方式，通过从服务器下载补丁包，然后对有问题的类中出问题的方法，进行替换，优点是用户无感知修复，无需下载新的应用，代价小。

热修复框架简单对比

接下来先对几个热修复框架进行简单的介绍，后续将分别单独开一篇博客对其进行详细分析。

1.QQ空间热修复补丁技术
QQ空间热修复的方案是基于dex分包方案的基础之上，简单来说就是把BUG方法修复以后，重新生成一个dex，从服务器下载之后，将其插入到dexElements数组的最前面，让虚拟机去加载修复完后的方法。

可以看到上图中，将修复后的Test.class类打包进patch.dex中，然后放入了dexElements的最前面，当虚拟机加载Test.class时，会按顺序对该类进行查找，由于包含patch.dex中的Test.class是最前面，就会优先加载，在后续的dex中遇到Test.class的话就会直接返回而不去加载，这样就达到了修复的目的。

但是采用这种方案，存在一个明显的问题，那就是当两个调用关系的类不在同一个dex时，就会产生异常报错。发生异常的原因是，在APK安装时，虚拟机会对classes.dex进行优化，变成odex文件，然后才会执行。在这个过程中，会进行类的verify的验证工作，如果调用关系的类都在同一个dex中的话就会被打上CLASS_ISPREVERIFIED的标志，然后才会写入odex文件。

所以使用这种方案时，必须避免类被打上CLASS_ISPREVERIFIED标志，具体的做法就是在每一个类的构造函数中单独引用一个在另外dex中的类。

下面简要概述一下QQ空间修复方案的步骤
1.获取到当前应用的Classloader
2.通过反射获取到他的DexPathList属性对象pathList
3. 通过反射调用pathList的dexElements方法把patch.dex转化为Element数组
4. 两个Element数组进行合并，把patch.dex放到最前面去
5. 加载合并后新的Element数组，达到修复目的

该方案存在如下的缺点：
1.不支持即时生效，必须通过重启才能生效。
2.patch.dex是用来存储修复的类，启动应用时，就要加载patch.dex，当修复的类到了一定数量，加载时间会变得很长，造成应用启动卡顿
3.在ART模式下，如果类结构发生了改变，就会出现内存错乱。为了解决这个问题，就必须把所有相关的调用类、父类子类等等全部加载到patch.dex中，导致补丁包异常的大，进一步增加应用启动的耗时。

2.微信Tinker
微信Tinker框架的原理是通过生成dex差量包的方式，与QQ空间超级补丁技术基本相同，区别在于不再将patch.dex增加到elements数组中，而是差量的方式给出patch.dex，然后将patch.dex与应用的classes.dex合并，然后整体替换掉旧的dex文件，以达到修复的目的。

Tinker框架的流程图如下：

优点：其实最大的优点就是，合成整包，不用在构造函数插入代码，防止verify，也就是QQ空间方案的缺点
缺点：
1.不支持即时生效，必须通过重启应用的方式才能生效。
2.需要单独开一个进程才能进行合并，占用内存
3.合并时占用额外磁盘空间，对于采用dex的应用来说，需要下发多个patch.dex与对应的classes.dex进行合并，失败率提高

3.阿里AndFix
相比与腾讯系的替换dex的方式，阿里AndFix的原理是基于native层的，提供了一种运行时在Native修改Filed指针的方式，实现方法的替换

在Native层操作，主要有以下三个步骤：

优点：
1. 不用重启，能及时生效
2. 补丁包同样采用差量技术，生成的PATCH体积小
不足：
1. 不支持新增字段，以及修改方法，也不支持对资源的替换。
2. 由于厂商的自定义ROM，对少数机型暂不支持。

当然除了上述3个框架，还有美团的Robust,可惜的是这个框架并未开源，所以不在此列出，本篇博客只是简单介绍了这些框架的原理，后续的博客将对这些热修复框架进行详细的分析。