浅析热更新技术方案(Android)

PS:该文章仅供个人学习交流之用，学识浅薄，不当之处，还请指出！

在Android开发中，关于热修复的话题越来越多，同时随着技术的迭代，各种框架的发展更新，热修复的框架似乎已经日趋成熟，各大互联网公司基本都有研发热更新框架，方案实现及优缺点各有差异，但总的来说就是两大类

• ClassLoader 加载方案
• Native层替换方案

QZone的热修复方案

• 基于Android Dex分包方案
• 利用插桩绕开预校验问题
• 只支持重启修复
• 不支持资源修复

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

何为利用插桩绕开预校验问题？

1. 在apk安装的时候系统会将dex文件优化成odex文件，在优化的过程中会涉及一个预校验的过程
2. 如果一个类的static方法，private方法，override方法以及构造函数中引用了其他类，而且这些类都属于同一个dex文件，此时该类就会被打上CLASS_ISPREVERIFIED
   3.如果在运行时被打上CLASS_ISPREVERIFIED的类引用了其他dex的类，就会报错
   4.正常的分包方案会保证相关类被打入同一个dex文件
   5.想要使得patch可以被正常加载，就必须保证类不会被打上CLASS_ISPREVERIFIED标记。而要实现这个目的就必须要在分完包后的class中植入对其他dex文件中类的引用
   以上参考Android热修复技术——QQ空间补丁方案解析(2)

QZone方案在Dalvik与Art都会产生一些问题

• Dalvik； 在dexopt过程，若class verify通过会写入pre-verify标志，在经过optimize之后再写入odex文件。这里的optimize主要包括inline以及quick指令优化等。
  若采用插桩导致所有类都非preverify，这导致verify与optimize操作会在加载类时触发,这会有一定的性能损耗.
• Art采用了新的方式，插桩对代码的执行效率并没有什么影响。但是若补丁中的类出现修改类变量或者方法，可能会导致出现内存地址错乱的问题。为了解决这个问题我们需要将修改了变量、方法以及接口的类的父类以及调用这个类的所有类都加入到补丁包中。这可能会带来补丁包大小的急剧增加。

Tinker

tinker.png

Tinker的思路是这样的，在编译时通过新旧两个Dex生成差异path.dex。在运行时，将差异patch.dex重新跟原始安装包的旧Dex还原为新的Dex。这个过程可能比较耗费时间与内存，所以我们是单独放在一个后台进程:patch中。为了补丁包尽量的小，微信自研了DexDiff算法，它深度利用Dex的格式来减少差异的大小。它的粒度是Dex格式的每一项，可以充分利用原本Dex的信息，而BsDiff的粒度是文件，AndFix/QZone的粒度为class。

关于Tinker的文档及源代码，可参考Tinker官方github

Tiker方案详细分析可参考微信Android热补丁实践演进之路

一. AndFix

AndFix.png

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

更多细可以参考https://github.com/alibaba/AndFix

Instant Run工作原理及用法

Instant Run对热更新技术的发展也特别具有引导意义，有兴趣的可以参考Instant Run工作原理及用法

参考：

安卓 App 热补丁动态修复技术介绍

干货满满，Android热修复方案介绍

Android 插件化和热修复知识梳理

Android 热修复原理篇及几大方案比较

类加载机制实现Android热修复

热修复——深入浅出原理与实现

Android热修复技术——QQ空间补丁方案解析(1)

Android热修复技术——QQ空间补丁方案解析(3)