APP热更新方案 - 大熊先生|互联网后端技术_H5之家

为什么要做热更新

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

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

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

最后最致命的是：

有时候仅仅是因为不小心写错了一行代码，就让所有的加班都付之东流，苦不苦，冤不冤，想想都苦。

还有一种剧情是研发总监把锅甩给测试团队，测试不过关，测试摊摊手说我也不是神啊，总会有漏网之鱼.

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

热更新的行业情况

先来说说Android

并不是因为Android更有料就先说他，而是它的用户量级比Iphone大，我们写文章也是讲究大数据分析的不是..

Andoid端在15年热补丁就比较火，先后出现了Dexposed、AndFix，Qzone超级补丁的类Nuwa方式，微信的Tinker, 大众点评的nuwa、百度金融的rocooFix, 饿了么的amigo以及美团的robust.

再来看看Iphone端

技术上要在 iOS 上做到原生动态化比 Android 更容易，iOS 开发语言 Objective-C 天生动态，运行时都能随意替换方法，运行时加载动态库又是项很老的技术，只要我把增量的代码和资源打包到一个 framework 里，动态下发运行时加载，修 bug，加功能都不在话下，性能完全无损，这件事就结束了。

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

于是有了 waxPatch 和 JSPatch 这样的方案，以及异军突起不局限于热修复Bug而能做主体功能发布的React Native 和 Weex，后面又有了吊口味的滴滴的DynamicCocoa方案和OCScript

热更新的技术原理

先来说JAVA

技术派系：

• 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

使用方法：

dexposed提供了3个使用方法：

beforeHookedMethod afterHookedMethod replaceHookedMethod

来看看使用方式，也极其简单.

优缺点：

来说说硬伤吧，不支持art，不支持art，不支持art。

不支持Dalvik 3.0.

所以注定它会逐步失声,再多的优点也是徒劳

插播一条硬广: 技术文章转发收录太多,此文出处以及微信公众号: 互联网手艺人

Qzon的超级补丁方案

该方案基于的是android dex分包方案的，关于dex分包方案本身更多是为了解决Android的64K方法调用限制问题，具体的原因是：

• DexOpt 会把每一个类的方法 id 检索起来，存在一个链表结构里面，但是这个链表的长度是用一个 short 类型来保存的，导致了方法 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数组的最前面，让虚拟机去加载修复完后的方法。