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中的小程序页面有效，对原生模块无能为力。
