Android热更新技术——Tinker、nuwa、AndFix、Dexposed

时间:2021-08-17 08:02:27

一、热修复技术作用

  线上app BUG紧急修复,不重新发版,不重新安装,在线远程修复问题

二、局限性与适用场景

  • 补丁只能针对单一客户端版本,随着版本差异变大补丁体积也会增大;
  • 补丁不能支持所有的修改,例如AndroidManifest;
  • 补丁无论对代码还是资源的更新成功率都无法达到100%。

既然补丁技术无法完全代替升级,那它适合使用在哪些场景呢?

1.轻量而快速的升级

2.远端调试

3.数据统计

4.其他(Instant Run)

Android官方也使用热补丁技术实现Instant Run。它分为Hot Swap、Warm Swap与Cold Swap三种方式。

Android热更新技术——Tinker、nuwa、AndFix、Dexposed

三、热修复的原理

1、通过更改dex加载顺序实现热修复(下载补丁后app需要重启,而后才会加载补丁生效)

通过更改含有bug的dex文件的加载顺序;在dex的加载中,若已找到方法则不会继续查找,所以如果能让修复之后的方法在含有bug的方法之前加载就能达到修复bug的目的。把有问题的类修复后,放到一个单独的dex,通过反射插入到dexElements数组的最前面,让虚拟机优先加载打完补丁的class。

实践中,会发现运行加载类的时候报preverified错误,原来在DexPrepare.cpp,将dex转化成odex的过程中,会在DexVerify.cpp进行校验,验证直接引用的类和clazz是否在同一个dex,如果是,则会打上CLASS_ISPREVERIFIED标志。通过在所有类(Application除外,当时还没加载自定义类的代码)的构造函数插入一个对在单独的dex的类的引用,就可以解决这个问题。空间使用了javaassist进行编译时字节码插入。

隐患:虚拟机在安装期间为类打上CLASS_ISPREVERIFIED标志是为了提高性能的,我们强制防止类被打上标志多少会影响app的性能。但是在大项目中拆分dex的问题已经比较严重,很多类都没有被打上这个标志。

开源实现有Nuwa, HotFix, DroidFix。实际应用案例:QQ空间

2、通过Native替换方法指针的方式实现热修复(下载补丁后app不需要重启,即可加载补丁生效)

主要是阿里开源的两个热修复框架:Dexpost AndFix。它们都是通过Native层使用指针替换的方法替换bug,达到修复bug的目的,具体可参考其github文章。

(1)基于Xposed的AOP框架,方法级粒度,可以进行AOP编程、插桩、热补丁、SDK hook等功能。

Xposed需要Root权限,是因为它要修改其他应用、系统的行为,而对单个应用来说,其实不需要root。 Xposed通过修改Android Dalvik运行时的Zygote进程,并使用Xposed Bridge来hook方法并注入自己的代码,实现非侵入式的runtime修改。

我们知道,应用启动的时候,都会fork zygote进程,装载class和invoke各种初始化方法,Xposed就是在这个过程中,替换了app_process,hook了各种入口级方法(比如handleBindApplication、ServerThread、ActivityThread、ApplicationPackageManager的getResourcesForApplication等),加载XposedBridge.jar提供动态hook基础。

方法级的替换是指,可以在方法前、方法后插入代码,或者直接替换方法。只能针对java方法做拦截,不支持C的方法。

硬伤是不支持art,不支持art,不支持art。

(2)AndFix同样是方法的hook,AndFix不像Dexposed从Method入手,而是以Field为切入点。dalvik和art都支持

使用上,直接写一个新的类,会由补丁工具会生成注解,描述其与要打补丁的类和方法的对应关系。

3、微信热补丁方案(下载补丁后app需要重启,而后才会加载补丁生效)

思想是全量替换新的Dex。即完全使用新的Dex,这样既不出现Art地址错乱的问题,在Dalvik也无须插桩。考虑到补丁包的体积,不能直接将新的Dex放在里面。但可以将新旧两个Dex的差异放到补丁包中,最简单可以采用BsDiff算法。

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

在最极端的情况,由于利用了原本dex的信息完全替换一个13M的Dex,我们的补丁大小也仅仅只有6.6M。

但是这套方案并非没有缺点,它带来的问题有两个:

(1)占用Rom体积;这边大约是你修改Dex数量的1.5倍(dexopt与dex压缩成jar)的大小。
(2)一个额外的合成过程;虽然我们单独放在一个进程上处理,但是合成时间的长短与内存消耗也会影响最终的成功率。

微信的热补丁方案叫做Tinker,也算缅怀一下Dota中的地精修补匠,希望能做到无限刷新。

若不care性能损耗与补丁包大小,QZone方案是最简单且成功率最高的方案(没有单独的合成过程)。相对Tinker来说,它的占用Rom体积也更小。另一方面,QZone与Tinker的成功率大约相差3%左右。

事实上,一个完整的框架应该也是一个容易使用的框架。Tinker对补丁版本管理、进程管理、安全校验等都有着很好的支持。同时我们也支持gradle与命名行两种接入方式。希望在不久的将来,它可以很快的跟大家见面。

https://www.cnblogs.com/aademeng/articles/6883861.html

http://www.bbs0101.com/archives/1437.html(讲解和总结的很好,包含是否需要重启)

https://www.jianshu.com/p/52cacc0f23fa

https://www.cnblogs.com/fanfu1/p/5506149.html