如何选型热更新机制？技术原理分析

热更新是一种App软件开发者常用的更新方式。简单来说，就是在用户下载安装App之后，打开App时遇到的即时更新。

在2017年苹果App Store针对热更新的下架事件以后，开发者们也在不断的探索及尝试最优技术解决方案。随着技术的迭代，各种框架的发展更新，热更新的框架已经日趋成熟，各大互联网公司基本都有研发热更新框架，方案实现及优缺点各有差异，但总的来说有三大类。

ClassLoader 加载方案： 代表有Qzone的超级补丁、大众点评的nuwa、百度金融的rocooFix,、以及美团的robust。

Native层替换方案： 代表有阿里的Dexposed、AndFix与腾讯的内部方案KKFix；

H5/小程序动态加载： 代表有HTML5方案、FinClip 小程序容器热更新方案；

接下来分别为大家介绍几个极具代表性的方案，以及它们的优缺点：

1、QZone的热更新方案

QZone方案推出比较早，对热修复技术的推进很有启发意义。它是基于Android dex分包方案，最关键的技术点在于利用字节码插桩的方式绕开了预校验问题。这种方案只支持App重启之后才能修复，也就是App在运行的时候加载到了补丁包也不能及时修复，需要App重新启动的时候才会修复，这是因为QZone方案是基于类加载区需要重新加载补丁类才能实现的，所以必须进行重启才能修复。此外，QZone方案只支持到类结构本身代码层面的修复，不支持资源的修复。

原理

class加载原理：dex文件转换成dexFile对象，存入Element[]数组，findclass顺序遍历Element数组获取DexFile，然后执行DexFile的findclass。
Hook了ClassLoader.pathList.dexElements[]，将补丁的dex插入到数组的最前端，所以会优先查找到修复的类，从而达到修复的效果。

优点

代码是非侵入式的，对apk体积影响不大。

缺点

需要下次启动才修复。
性能损耗大，为了避免类被加上CLASS_ISPREVERIFIED，使用插桩，单独放一个帮助类在独立的dex中让其他类调用。

2、微信Tinker

据微信内部人士介绍：微信tinker项目之初最大难点在于如何突破Qzone方案的性能问题，通过研究Instant Run的冷插拔与buck的exopackage找到灵感。它们的思想都是全量替换新的Dex

因为使用全新的dex，所以自然绕开了Art地址可能错乱的问题，在Dalvik模式下也不需要插桩，加载全新的合成dex即可。

原理

采用dex替换的方式，避免了dex插桩带来的性能损耗。原理是提供dex差量包，整体替换dex的方案。差量的方式给出patch.dex，然后将patch.dex与应用的classes.dex合并成一个完整的dex，完整dex加载得到dexFile对象作为参数构建一个Element对象然后整体替换掉旧的dex-Elements数组。
Tinker自研了DexDiff/DexMerge算法，对于dex文件的处理经验老道。Tinker还支持资源和So包的更新，So补丁包使用BsDiff来生成，资源补丁包直接使用文件md5对比来生成，针对资源比较大的（默认大于100KB属于大文件）会使用BsDiff来对文件生成差量补丁。

优点

兼容性高、补丁小。
开发透明，代码非侵入式。
支持so文件、资源文件、类的增加和删除。

缺点

需要下次启动才修复。

3、阿里AndFix

AndFix采用native hook的方式，这套方案直接使用dalvik_replaceMethod替换class中方法的实现。由于它并没有整体替换class, 而field在class中的相对地址在class加载时已确定，所以AndFix无法支持新增或者删除filed的情况(通过替换init与clinit只可以修改field的数值)。

原理