Android 垃圾回收黑科技

今天，我们来学习下 Android 中的垃圾回收机制。

大家应该知道，JVM 和 Dalvik 的垃圾回收机制实际并不完全相同。而垃圾回收机制一直都是工作和面试中的必备技能，对 GC 有深入的理解，才能在代码层面更好地去减少 GC 的发生，毕竟每次 GC 都会对主线程的运行造成一定的卡顿，从而影响到用户体验。

1前言

本节将介绍支付宝 Android 客户端启动速度优化下的「垃圾回收」具体思路。

应用启动时间是移动 App 一个重要的用户体验环节，相对于普通的移动 App，支付宝过于庞大，必然会影响启动速度，一些常规的优化手段在支付宝中已经做得比较完善了，本篇文章尝试从 GC 的层面来进一步优化支付宝的启动速度。

2背景

相对于 C 语言来说，Java 语言有一些特性，例如开发人员不用考虑内存的分配和回收，然而，进程内存管理又是必不可少的环节，妥协的结果是 Java 语言的设计者们把对象分配和回收放到了 Java虚拟机，这里希望明确一个概念：GC 是有代价的，这个代价包括：阻塞 Java 程序的执行，占用 CPU 资源，占用额外内存等，谷歌的工程师意识到了 GC 对应用的影响，所以把 GC 的日志默认输出到了 Logcat，我们经常能够看到 Logcat 里输出以下几种 GC 日志：

1.GC_EXPLICIT： Dalivk 给开发人员提供的主动触发 GC 的 API，读者可以参看 Google Maps 的设计来体会这个 API 的用法

2.GC_FOR _ALLOCK： 是分配对象失败时触发的 GC，这个 GC 会将应用所有的 Java 线程暂停运行，直到 GC 结束。

3.GC_CONCURRENT： 是 Java 虚拟机根据堆的当前状态触发的 GC，这个 GC 在 Dalvik 单独 GC 线程里运行，在部分时间里不影响应用 Java 线程的运行。 支付宝启动是一个典型的关键路径场景，我们希望看到尽可能少的 GC_ CONCURRENT（如果可能， GC_ FOR_ ALLOCK 也应该缩减到最少），然而，通过 Logcat 我们会看到非常糟糕的 GC 行为—大量的 GC_ FOR_ ALLOCK 以及触目惊心的 Java 线程被 WAIT_ FOR_ CONCURRENT_ GC 阻塞。如下图所示，通过简单统计这些 GC 消耗的时间，我们能够得出 GC 严重影响应用启动时间的结论。

3设计思路

支付宝是 Android 系统的一个应用程序，如何能够通过影响 Dalvik 的 GC 行为来缩短启动时间呢？这个问题可以分解为两步：

1.支付宝是否能影响自身 Dalvik 的行为

2.如何改进 Dalvik，缩短启动时间

第一个问题答案是肯定的，Android 系统的设计思路是每个 Android 应用程序都有独立的 Dalvik 实例，应用启动后可以修改自己的进程空间里的代码和数据，因此支付宝通过修改内存中的 Dalvik 库文件 libdvm.so 影响 Dalvik 的行为。

第二个问题的难点在于投入产出比：修改进程空间的代码和数据是面向二进制，难度远远大于源代码，也就是说稍微复杂的Dalvik改进工作是不可能的。

基于以上两点，提出了一种设想：启动时 GC 抑制，允许堆一直增长，直到开发人员主动停止 GC 抑制或者 OOM 停止 GC 抑制，这是一种"空间换时间"策略，用更多的内存消耗来换取启动时间的缩短，这种策略可行有两个前提：一是设备厂商没有加密内存中的 Dalvik 库文件，二是设备厂商没有改动 Google 的 Dalvik 源码（或者少量的改动），理论上通过白名单的方式可以覆盖所有设备，但是实现和维护成本都非常高。

4GC 抑制的实现

GC 抑制的前提是 Dalvik 比较熟悉，知道如何改变 GC 的行为，解决方案大致如下：首先在源码级别找到抑制GC的修改方法，例如改变跳转分支，其次，在二进制代码里找到 A 分支条件跳转的"指令指纹"，以及用于改变分支的二进制代码，假设为 override_A，应用启动后扫描内存中的 libdvm.so，根据"指令指纹"定位到修改位置，然后用 override_A 覆盖，这里需要注意的是，"指令指纹"的定义需要有一些编译器和 arm 指令集知识，实现 GC 抑制主要实现了以下 4 个部分：

• 取消 softlimit 检测

• 取消 GC 线程的唤醒

• 取消 GC 例程函数

• OOM 停止 GC 抑制的实现

• 取消 softlimit 检测：

取消 softlimit 检测的目的是最大限度的分配对象，下图为 softlimit 检查对应的 arm 指令片段，位于 dvmHeapSourceAlloc 函数中，OXE057 对应于"return NULL"的分支，如果我们想永远不进入"return NULL"分支，可以改变 cmp 指令的结果，在具体实现里我们把"0X42"作为"指令指纹"来识别而且修改为 "cmp r0, r0"，这样就可以实现取消 softlimit 检查。

• 取消 GC 线程唤醒

取消 GC 线程唤醒的目的是防止 GC 线程频繁唤醒导致的线程抖动。下图是对应的 C++ 代码和 arm 指令片段，这段代码同样位于 dvmHeapSourceAlloc 函数中。在具体实现里我们会依次扫描 libdvm.so的 dynstr、dynsym、rel.plt 和 plt 区域获取 pthreadcondsignal@plt 的地址，然后遍历 dvmHeapSourceAlloc 中的所有分支跳转，计算跳转目的地址。

如果发现 pthreadcondsignal@plt 和当前分支跳转目的地址配置，擦除这条指令即可。

• 取消 GC 例程函数

取消 GC 例程函数采用钩子技术来实现，我们将 GC 抑制封装成了两个 native 接口 doStartSuppressGC 和 doStopSuppressGC；并且进一步封装为 JNI 接口，便于开发者在 Java 里调用。一般的应用方式是，开发者通过日志看到支付宝在某个场景会触发大量的 GC 且这个 GC 影响用户体验（响应时间慢或者动画卡顿），然后在这个场景前后插入 doStartSuppressGC 和 doStopSuppressGC。

以支付宝冷启动场景为例，我们在容器 Quinox 的 attachBaseContext 函数里插入 doStartSuppressGC，在首页加载结束时插入 doStopSuppressGC。

• OOM 停止 GC 抑制的实现

如果仅仅考虑在支付宝启动过程中抑制 GC，不需要考虑 OOM 停止 GC 抑制的实现，因为支付宝启动不足以触发 OOM。但是我们希望 GC 抑制成为一个基础模块，能够应用到更多场景中。如果程序在调用 doStopSuppressGC 前触发了 OOM，则需要在 OOM 发生前停止 GC 抑制。和前面简单的改变分支跳转方向不同，需要在 OOM 发生前注入一个新的的分支跳转，这个新分支的代码由我们来实现。新分支主要功能是，调用 doStopSuppressGC，然后去掉注入的新分支，最后跳回 Dalvik 执行 OOM。

• 实现同样采用传统的钩子技术。在钩子函数 dvmCollectGarbageInternal 里：

当条件不满足时直接返回，达到取消 GC 的目的；

条件满足时，取消钩子且执行原来的 dvmCollectGarbageInternal。

实现中使用了开源的二进制注入框架：github.com/crmulliner/… 。

这里需要注意的是，在热点函数里使用这个框架提供的 pre_hook 和 post_hook 的性能开销非常大。本文里的设计只会用到一次 pre_hook，所以不存在性能问题。

看到的这里读者可能会问，这种通过“指令指纹”的方式靠谱么？我的答案是，漏判不影响正确性，误判理论上存在但概率极小（误判指“指令指纹”定位到错误代码位置）。即使误判发生了，我们还有最后一层保障——基础架构组同学实现的容灾机制。当误判导致程序异常无法完成正常启动时，重启支付宝而且在后续的启动中直接放弃 GC 抑制。

5效果

上图的启动时间的数据是在内部的 Android 4.x 测试设备上获得的（没有标注 release 表示 debug 版本）。从图表上来看，支付宝客户端的启动时间缩短了 15%～30%。

END

本人Java开发4年Android开发5年，定期分享Android高级技术及经验分享，欢迎大家关注~ （喜欢文章的点个赞鼓励下叭~谢谢。）

然后针对Android程序员，我这边给大家整理了一些资料，包括不限于高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter等全方面的Android进阶实践技术；希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！

资料领取：点赞+加群免费获取 Android IOC架构设计

加群 Android IOC架构设计领取获取往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、混合式开发（ReactNative+Weex）全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。