Android Patch 方案与持续交付

发表于   |   作者: mason   |  

Android 不仅系统版本众多，机型众多，而且各个市场都各有各的政策和审核速度，每次发布一个版本对于开发同学来讲都是一种漫长的煎熬。相比于 iOS 两三天就能达到 80% 的覆盖速度而言，Android 应用版本升级至少需要两周才能达到 80% 的升级率，严重阻碍了版本迭代速度。也导致市场上 App 版本分散，处理 bug 和投诉等也越来越麻烦。

  • 修复的 bug 需要等待下个版本发布窗口才能发布？
  • 已经 ready 的需求排队上线，需要等待其他 Feature Team 合入代码？
  • 老版本升级速度慢？频繁上线版本提醒用户升级，影响用户体验？

这几个问题是每个 App 开发同学都必然要面对的。那么有没有方法能在用户无感知的情况下加速 bug 处理和版本迭代速度？

在这方面 PC 端 Chrome 浏览器的 patch 升级方案给我们了一个很好的借鉴：当 Chrome 有版本升级的时候会自动下载 patch 文件。下次启动后，Chrome 就已经是新版本。

他山之石，可以攻玉

近一两年 Android 热补丁框架非常热门。从最初 360 动态下发 lua 脚本，到后来出现的各种方案，如雨后春笋般出现。早期的补丁框架偏向于以代码修复为主，主要分为两大类：native hook 方案和 Multidex 方案。

native hook 方案如阿里巴巴的 AndFix 和 Dexposed。Multidex 方案如 Qzone。切入点都是替换掉将要执行的代码。基于 Qzone 方案的思路，出现了 nuwa 这个比较完善的库，工具链比较完善。

类似 Chrome 的 patch 升级方案足以满足加速 bug 处理和版本迭代速度的需求，给了我们很大的借鉴意义。在安卓系统上，可以通过 hotfix 的思路来达到这一目的：下发补丁文件，更新 App 版本

站在巨人的肩膀上

在今年 3 月份开始做技术选型的时候把上面的几种方案试了一轮。其中 AndFix 甚至跟上了现网的一个发布版本，但是由于影响正向开发过程（只能修改方法、不能修改 field、不能新增类等问题）、库本身难于维护（需要依赖外部开源力量进行维护）以及发现的莫名其妙的 bug（导致我们 App 下发 patch 后白屏），所以即使跟上了发布版本也没有使用。nuwa 仅支持更新 Java 代码，不能更新资源和 so 文件，满足不了我们的需求。

没有好用的轮子，我们决定自己造一个，于是有了现在的 patch 方案。

App 只是一个加载器

既然做安卓 patch 方案，最好的结果就是能支持更新 App 所有的代码和资源。但是

  • Application 类是 App 启动之初就被安卓系统加载起来，所以至少 Application 类和它启动依赖的其他业务类是不能被更新的？
  • 修复 bug 或者版本迭代过程中难免会遇到需要修改资源文件的情况。资源文件能更新吗？
  • native 实现的 so 文件如何更新？

针对上面三个问题， 我们的设计是把 App 仅仅当做一个加载器。系统启动 App 之后，加载器决定将要运行的代码和资源的位置。当有新功能或者 bugfix 需要推送给用户，替换加载器内容即可。

支持更新全部代码

上面提到 Application 由于启动就被加载而不能被更新的问题，我们代理了真实 Application 类的创建过程。通过代理 Application，控制 Application 从新 dex 文件中加载。假设真实的 Application 类是 MyApplication。我们在编译期间自动修改 AndroidManifest.xml 文件，把 MyApplication 替换为 MoaiApplication（是 App 的入口 Application）。App 启动后由 MoaiApplication 加载完相应的文件（dex/资源文件/so 文件）后，再将控制权交回给 MyApplication。

代理生命周期

将控制权交回给 MyApplication，我们最初是代理 MyApplication 的生命周期。具体做法是，MoaiApplication 决定加载哪里的业务代码、资源文件以及 so 文件之后依然负责接收 App 的全部生命周期，然后把生命周期代理给 MyApplication，简单例子如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
private MyApplication delegate;
@Override
protected void attachBaseContext(Context base) {
  super.attachBaseContext(base);
  delegate = MyApplication.class.newInstance();
}
@Override
public void onCreate() {
  super.onCreate();
  delegate.onCreate();
}

还有比较多生命周期函数上面代码就没一一列举。

从上面代码容易想到代理方案的缺点：必须要完整代理所有生命周期接口。否则 MyApplication 会由于生命周期不完整而出现奇怪的 bug。比如我们最初版本在测试过程中就出现了没有代理 registerActivityLifecycleCallbacks 函数而导致拿不到 Activity 生命周期 onActivityCreated/onActivityDestroyed 等回调。

反射 Application

踩到生命周期回调不完整的坑之后，我们开始考虑能不能把 App 运行期间 Application 的引用全部替换成 MyApplication ？这样就无需 MoaiApplication 把生命周期代理给 MyApplication，而是由 MyApplication 直接接收系统回调。安卓系统 ContextWrapper 的实现是包装了一层真正的 mBase 上下文，App 真正使用到的就是这个 mBase。通过反射 mBase 以及其中字段对 Application 的引用，『彻底』解决了需要手写代理 Application 全部生命周期的方法。

dex分包

Qzone 方案下发的 patch 文件是变更过的 Java 类组成的 patch.dex，在 dalvik 和 ART 虚拟机下分别需要解决 Class ref in pre-verified class resolved to unexpected implementation 和内存地址错乱问题。这些问题根源在于改变了类原本所属的 dex 文件。既然改变类所在的 dex 会导致各种各样的问题，那直接替换掉整个 dex 不就好了？在调研 JRebal for Android 和 Instant Run 的时候也发现了他们有类似的做法。

我们把 App 的 dex 分成两部分：

  • patch 库的 dex 文件 -> classes.dex
  • 其他业务代码的 dex 文件 -> classes[N].dex

其中 classes.dex 中仅包含了 patch 库的全部代码，并不包含任何其他业务代码。

假设 apk 中包含三个文件：classes.dex、classes2.dex、classes3.dex。classes.dex 充当的角色就是加载器，负责启动 App 并且加载后面的两个 dex。这样做的目的是，App 启动需要用到的所有类都集中在 classes.dex 中，所有业务代码的类都集中在 classes[N].dex 中。如果某次下发 patch 代码把 classes2.dex 变更为 classes2-1.dex，那么由加载器加载 classes2-1.dex 和 classes3.dex 即可实现更新包含 MyApplication 类在内的所有代码。

怎么加载更新后的代码？

如果 dex 文件有更新，加载器会选择加载更新后的文件。我们最初采用了 Google 官方的 Multidex 方案，扩展 DexPathList 的 dexElements 字段。

Multidex 方案存在问题

Multidex 方案上线后发现某些机型（比如三星s6 5.0.2 ROM）并不能加载扩展进去的 dex 中的代码。debug 阶段却能顺利加载（debugger 拖慢代码执行速度）。目前的猜测是某些厂商在 5.x 以上版本改动 ROM 导致 App 启动逻辑有多线程并发执行。

最终我们弃用了 Multidex 方案，转而 Hack 系统 ClassLoader。

ClassLoader Hack 方案

所有线程使用的是同一个 ClassLoader 对象。所以一旦 Hack 了这个对象，所有线程都开始使用 Hack 过的对象，从而能够解决多线程导致加载不到扩展的 dex 文件中代码的问题。

安卓系统加载代码的 ClassLoader 是 PathClassLoader 和 BootClassLoader。我们最初设计的方案是在 PathClassLoader 和 BootClassLoader 之间插入一个 BaseDexClassLoader，让所有业务代码都在这个插入的 BaseDexClassLoader 中加载。但是这样的设计存在缺陷：业务代码的 ClassLoader 会变成 BaseDexClassLoader，如果业务代码依赖了 patch 库的代码（在 classes.dex 中），会出现 ClassNotFoundException。

在这方面 Instant Run 的设计很精巧。它让 PathClassLoader 插入的父 loader （IncrementalClassLoader）包装了 DelegateClassLoader，并且把 DelegateClassLoader 的父 loader 设置为 PathClassLoader，使得类加载的路径变成：

在 DelegateClassLoader 加载业务代码的时候（业务代码在 classesN.dex 中），流程会沿着标记的顺序最终第 5 步成功加载到业务代码。业务代码如果依赖 patch 库的代码，会在 PathClassLoader 加载。这样所有代码都可以被加载到。

怎么更新资源？

单纯更新 Java 代码的 patch 框架，实用性会受到很大的局限。开发同学需要仔细验证提交内容，确保提交中不包含资源文件的变更以及 native so 的改动，会导致本就复杂的开发流程变得更加繁琐。所以我们在支持更新 Java 代码的基础之上，也支持更新资源和 native so 文件。

App 加载资源是依赖 Context#getResources 函数返回的 Resources 对象。Resources 内部包装了 AssetManager，最终由 AssetManager 从 apk 文件中加载资源。所以我们反射了替换系统默认的 Resources，让 AssetManager 从我们更新后的 apk 中加载资源。现阶段的实现支持比如 string/anim/drawable/color/layout 等资源文件的变更。由于 Android 系统在安装 apk 时候已经把 AndroidManifest.xml 文件解析并写入到系统中，目前还不支持修改四大组件，比如增加 Activity。后续会继续研究如何做到无缝修改四大组件。

怎么更新 so 文件？

在 Android 项目中使用 native 函数前需要先调用 System.loadLibrary(libName)。

当 lib 文件需要更新或者有 bug 时候怎么办？首先想到的是在代码中把加载 so 文件的代码改成System.load(libFilePath)，让系统加载自己指定的 libFilePath 文件。然而这样的改动需要

  • 在源代码中修改或者使用工具在编译期把 loadLibrary 接口改为 load
  • patch 库把 so 文件从 patch 文件中复制到特定目录

这样在运行期才有可能加载更新后的 so 文件。

通过分析系统加载 so 文件的方式后，我们使用了更简单的处理方法。查找 lib 文件是通过调用 PathClassLoader 的 findLibrary，最终调用到 DexPathList 的 findLibrary。DexPathList 会在自己维护的列表目录中查找对应的 lib 文件是否存在。所以我们在发现 patch 文件中有 so 文件变更的时候，会在 PathClassLoader 的 nativeLibraryDirectories（Android6.0以下）或者nativeLibraryPathElements （Android 6.0及以上）的最前面插入自定义的lib文件目录。这样 ClassLoader 在 findLibrary 的时候会先在自定义的 lib 目录中查找，优先加载变更过的 so 文件。

patch 包的生成与应用

回到我们最初的目标：patch 不应该影响正向开发流程。我们生成 patch 文件是针对 apk 进行的，开发同学无需关心此次发布是 patch 版本还是正常版本，只需要正常开发并且打包要发布的 apk 即可，不会对正向开发流程产生任何影响。

我们提供 python 脚本生成两个 apk 的：对比两个 apk 中的所有文件，找出有变更的文件进行 diff，把 diff 结果写入 patch 文件。线上用户下载 patch 文件到本地之后，启动一条新的进程使用 context.getApplicationInfo().sourceDir 路径的 apk 与 patch 文件合并，得到新的 apk（包含资源文件，不包含 dex 文件）以及 dex 文件、native so 文件，并在这条进程中提前做 dex 优化（dex2oat/dexopt）。针对 dex 优化过程太慢的问题（优化过程慢会导致进程可能会系统kill，降低 patch 成功率）我们并发了 dex 优化过程，使 patch 过程耗时相对减小。新 apk、dex文件、so 文件就可以在下次启动 App 的时候由加载器加载。

优势和不足

正所谓没有完美的架构，只有适合自己的架构。当前的开源方案并不能满足我们加速 bug处理和版本迭代速度的需求，于是有了站在巨人肩膀上的思考和我们现在的 patch 方案。我们目前的优势：

  • 全面支持 patch Java 代码、资源文件 和 native so 文件。版本只需要正常滚动，开发同学无需关心是发布 patch 版本还是正常版本
  • 使用相对简单（减少接入成本也是我们的最初思考点之一），只需要在 build.gradle 中加入三行代码即可，无需更多配置。

从我们团队发布的多个 patch 版本来看，下发的 diff 结果文件稍大。大文件下载过程可能出现的错误也会间接影响到 patch 铺开的速度，所以我们也在尝试更好的 diff 方案。Chrome 最初升级方案也是 bsdiff，而后慢慢演变出 Courgette 算法。

演进与思考

我们对于补丁框架的定义不仅仅是『修复bug』就足够，除此之外，如何快速接入，如何做到不影响现有流程，这对于很多应用来说至关重要。在此之上，搞清楚框架的定位，适当舍弃一些不重要方面的时候，快速迭代，在迭代中持续优化，事情往往比想象的更加简单。

持续交付一直都是快速迭代思想的一种践行方式，对于 App 开发而言，如果我们通过构造补丁框架这样一个渠道，可以通过自动化系统把补丁快速地把新功能推送给用户，那这个事情的意义就不仅仅是『修复 bug』这么简单。减少线上 crash 率和加速版本迭代、让新功能尽早与用户见面，从而可以在更短的时间内不断收集用户反馈信息对产品进行打磨。

目前我们已经在微信读书线上三个版本开始试行了用补丁代替版本发布或者加速老版本升级的做法，期待将来能通过这个渠道，为安卓开发同学们做到无感知的持续交付过程 。