热修复 移动平台热更新技术背景

2018/06/09 20:59
阅读数 3

为什么要做热更新

当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。

重点是还会有原来的版本遗留,无论你怎么提示都有人放弃治疗,不愿意升级,强制不能使用体验又足够糟糕到让人不能启齿。

如果这是一个影响公司收入或者体验影响极其不好的Bug,那完蛋了,可能公司老板会对整个技术团队的技术能力丧失信心,其对技术人员的伤害是致命的。

最后最致命的是: 有时候仅仅是因为不小心写错了一行代码,就让所有的加班都付之东流,苦不苦,冤不冤,想想都苦。
还有一种剧情是研发总监把锅甩给测试团队,测试不过关,测试摊摊手说我也不是神啊,总会有漏网之鱼。

那能不能神不知鬼不觉在没有产生较大影响前把bug快速修复了呢?

热更新的行业情况

先来说说Android
并不是因为Android更有料就先说他,而是它的用户量级比Iphone大,我们写文章也是讲究大数据分析的不是。
Andoid端在15年热补丁就比较火,先后出现了 Dexposed、AndFix,Qzone超级补丁,微信的Tinker, 大众点评的nuwa、百度金融的rocooFix, 饿了么的amigo以及美团的robust

再来看看Iphone端
技术上要在 iOS 上做到原生动态化比 Android 更容易,iOS 开发语言 Objective-C 天生动态,运行时都能随意替换方法,运行时加载动态库又是项很老的技术,只要我把增量的代码和资源打包到一个 framework 里,动态下发运行时加载,修 bug,加功能都不在话下,性能完全无损,这件事就结束了。
但是呢。苹果把加载动态库的功能给封了,动态库必须跟随安装包一起签名才能被加载,无法通过别的途径签名后再下发。
于是有了 waxPatch 和 JSPatch 这样的方案,以及异军突起不局限于热修复Bug而能做主体功能发 布的 React Native 和 Weex 后面又有了吊口味的滴滴的DynamicCocoa方案和OCScript

Android 热更新方案

技术派系:
  • Native,代表有阿里的Dexposed、AndFix与腾讯的内部方案KKFix;
  • Java,代表有Qzone的超级补丁、大众点评的nuwa、百度金融的rocooFix、饿了么的amigo以及美团的robust。
Native流派与Java流派都有着自己的优缺点,它们具体差异大家可参考下文。事实上从来都没有最好的方案,只有最适合自己的。

下面我们来一一简单看下各热更新的实现方案:

阿里的 DexPosed

阿里开源项目,基于Xposed的AOP框架,方法级粒度,可以进行AOP编程、插桩、热补丁、SDK hook等功能。

不同的是,Xposed通过劫持 zygote(须root),而dexposed通过劫持 java method (而非楼上说的劫持class loader方法),将java method改变为native,并且将这个方法的实现链接到一个通用的Native Dispatch方法上

用处,最大的自然是hotpatch,用这种东西来热替换某个导致崩溃的方法。手淘还有做的一件事,就是用它作性能监控。这主要得益于无侵入式的方法调用Befor和After事件,能够让我们很好的记录和分析一个方法的调用时间。

开源项目promeG/XLog就是基于dexposed实现的方法调用logging。

优点:运行时、方法级、性能损耗少、学习成本低、本进程
缺点:不支持art、 不支持Dalvik 3.0, 所以注定它会逐步失声,再多的优点也是徒劳

Qzon的超级补丁 HotFix

该方案基于的是android dex分包方案的,关于dex分包方案本身更多是为了解决Android的64K方法调用限制问题,具体的原因是:
  • DexOpt 会把每一个类的方法 id 检索起来,存在一个链表结构里面,但是这个链表的长度是用一个 short(2^16=65536) 类型来保存的,导致了方法 id 的数目不能够超过65536个。当一个项目足够大的时候,显然这个方法数的上限是不够的。
  • Dexopt 使用 LinearAlloc 来存储应用的方法信息。Dalvik LinearAlloc 是一个固定大小的缓冲区。在Android 版本的历史上,LinearAlloc 分别经历了4M/5M/8M/16M限制。Android 2.2和2.3的缓冲区只有5MB,Android 4.x提高到了8MB 或16MB。当方法数量过多导致超出缓冲区大小时,也会造成dexopt崩溃

尽管在新版本的 Android 系统中,DexOpt 修复了方法数65K的限制问题,并且扩大了 LinearAlloc 限制,但是这套技术机制保留了下来。
分包的方案简单来说就是在打包时将应用的代码分成多个 dex,使得主 dex 的方法数和所需的 LinearAlloc 不超过系统限制。在应用启动或运行过程中,首先是主 dex 启动运行后,再加载从 dex,这样就绕开了这两个限制。
如何拆分和如何加载可以查看Google官方的方案  MultiDex

Qzon的超级补丁方案玩的是什么招呢?
把BUG方法修复以后, 放到一个单独的DEX里,插入到dexElements数组的最前面,让虚拟机去加载修复完后的方法。
Patch.dex中的A.class会优先加载,后续的dex中的A.class就不会加载直接跳过,达到修复目的。

核心问题:
当两个调用关系的类不在同一个DEX时,就会产生异常报错。我们知道,在APK安装时,虚拟机先将classes.dex优化成odex文件后才会执行。在这个过程中,会进行类的verify操作,如果调用关系的类都在同一个DEX中的话就会被打上CLASS_ISPREVERIFIED的标志,然后才会写入odex文件。具体如何解决这个问题可以参见QQ空间终端开发团队发布的  安卓App热补丁动态修复技术介绍

优点:
  • 没有合成整包(和微信Tinker比起来),产物比较小,比较灵活
  • 可以实现类替换,兼容性高

不足:
  • 不支持即时生效,必须通过重启才能生效。
  • 为了实现修复这个过程,必须在应用中加入两个dex!dalvikhack.dex中只有一个类,对性能影响不大,但是对于patch.dex来说,修复的类到了一定数量,就需要花不少的时间加载。对手淘这种航母级应用来说,启动耗时增加2s以上是不能够接受的事。
  • 在ART模式下,如果类修改了结构,就会出现内存错乱的问题。为了解决这个问题,就必须把所有相关的调用类、父类子类等等全部加载到patch.dex中,导致补丁包异常的大,进一步增加应用启动加载的时候,耗时更加严重。

微信的 Tinker

这个项目之初最大难点在于如何突破Qzone方案的性能问题,通过研究Instant Run的冷插拔与buck的exopackage给了我们灵感。它们的思想都是全量替换新的Dex

因为使用全新的dex,所以自然绕开了Art地址可能错乱的问题,在Dalvik模式下也不需要插桩,加载全新的合成dex即可。
焦点问题是合并的过程会不会有问题,会不会耗时或者效率低? 为此腾讯在DEX方面也花了很多时间研究内部的格式以及如何做Merge和进行校验工作,详细了解可以查看 大腾讯的第一个开源项目Tinker 这篇文章

优势:
  • 合成整包,不用再构造函数插入代码,防止verify,verify和opt在编译期间就已经完成,不会在运行期间进行
  • 性能提高。兼容性和稳定性比较高。
  • 开发者透明,不需要对包进行额外处理。

不足:
  • 与超级补丁技术一样,不支持即时生效,必须通过重启应用的方式才能生效。
  • 需要给应用开启新的进程才能进行合并,并且很容易因为内存消耗等原因合并失败。
  • 合并时占用额外磁盘空间,对于多DEX的应用来说,如果修改了多个DEX文件,就需要下发多个patch.dex与对应的classes.dex进行合并操作时这种情况会更严重,因此合并过程的失败率也会更高。

阿里的 Andfix 

为何唯独Andfix能够做到即时生效呢?

原因是这样的,在app运行到一半的时候,所有需要发生变更的Class已经被加载过了,在Android上是无法对一个Class进行卸载的。而腾讯系的方案都是让Classloader去加载新的类。如果不重启,原来的类还在虚拟机中,就无法加载新类。因此,只有在下次重启的时候,在还没走到业务逻辑之前抢先加载补丁中的新类,这样后续访问这个类时,就会Resolve为新的类。从而达到热修复的目的。

Andfix采用的方法是,在已经加载了的类中直接在native层替换掉原有方法,是在原来类的基础上进行修改的。
以Art为例,每一个Java方法在art中都对应着一个ArtMethod,ArtMethod记录了这个Java方法的所有信息,包括所属类、访问权限、代码执行地址等等。通过env->FromReflectedMethod,可以由Method对象得到这个方法对应的ArtMethod的真正起始地址。然后就可以把它强转为ArtMethod指针,从而对其所有成员进行修改。
这很有 C/C++ 研发的味道,实际上Andfix的核心代码replaceMethod就是用cpp写的。

IOS的热更新方案

苹果把加载动态库的功能给封了,动态库必须跟随安装包一起签名才能被加载,无法通过别的途径签名后再下发。

Wax

最早要从 Wax 这个项目开始说,大家都知道 Objective-C 有着非常强大的动态特性。比如说:
  • 运行时构造类和方法
  • 运行时替换方法的实现

实际上这两个能力是非常恐怖的,像脚本语言那样,文本即代码,无须编译。
后来出现了一个叫做 Wax 的项目(这个项目目前由阿里巴巴维护),这个项目打出的口号是用 Lua 来写 iOS 原生应用,当然现实中没有人会这样干,因为写起来实在是太痛苦了。但是鉴于 iOS 应用审核比写 Wax 还痛苦,所以 Wax 成为了做 HotFix 的最佳选择。

这个项目的做法是通过加载 Lua 脚本,动态的生成 Objective-C 的方法,通常用来替换掉出了问题的那个,Lua 脚本是可以动态下发的,所以也就实现了修复线上 bug 的使命。

当然,Wax 用起来是极为痛苦的,尤其是和 Objective-C 的类型转换。

JSPatch

iOS 7 的时候 Apple 推出了 JavaScriptCore,这是一个非常有趣的框架,他是 JS 与原生交互的桥梁,让你在原生和 JS 之间穿梭自如,现在 iOS 平台各种动态技术大多都是基于此。

JSCore 推出不久之后,一个更优秀的项目诞生了:由 bang 写的 JSPatch。这个项目无疑从各种角度碾压了 Wax,并且 JS 也比 Lua 更为人熟知,所以也就迅速替代 Wax 成为了热修复的主流选择。

JSPatch 的接入成本非常低,对项目的影响也非常小,不需要引入额外的脚本解释器(因为已经有 JSCore 了),并且 JS 写起来真的比 Lua 要爽很多。

2017年3月8日,很多iOS开发者收到了警告邮件,声称其App违规使用动态方法,责令限时整改,Jspatch一直就被打入冷宫了。

这次警告事件无疑是对iOS平台Native动态化是一次严重打击,其影响甚至可能波及到Android平台,毕竟Google也是禁止加载远程代码的,并且执行更为严格,只是管不到中国的Android开发而已。

2018-6-9




展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部