移动端四种热更新技术对比

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、阿里AndFix

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

原理

• 直接在native层进行方法的结构体信息对换，从而实现方法的新旧替换。

优点

• 补丁实时生效，不需要重新启动。

缺点

• 存在稳定及兼容性问题。ArtMethod的结构基本参考Google开源的代码，各大厂商的ROM都可能有所改动，可能导致结构不一致，修复失败。
• 无法增加变量及类，只能修复方法级别的Bug，无法做到新功能的发布。

3、微信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文件、资源文件、类的增加和删除。

缺点

• 需要下次启动才修复。

4、FinClip 小程序容器热更新方案

虽说h5与小程序均能帮助 Hybrid 应用实现热更新，但鉴于小程序优于h5的性能，这里仅为大家介绍基于小程序容器的热更新方案。

FinClip是近几年大热的小程序容器技术，App 通过连接后台，从后台拉取小程序包，通过小程序容器运行，可以帮助「Native+小程序」混合开发应用实现热更新

原理：（请技术同学帮忙校正/补充）

• 实现了小程序的容器，由逻辑层负责与 SDK 交互，渲染层负责页面的渲染，同时由 SDK 提供路由界面跳转以及其他原生功能
• SDK 通过运行时检查小程序的更新，动态进行小程序包的下载，实现功能的热更新

优点：（补充小程序热更新方案的优点）

• 非侵入式的代码，对apk体积影响不大。
• 可扩展性高，由小程序接管业务逻辑，可以扩展任意功能

缺点：

• 只对app中的小程序页面有效，对原生模块无能为力。