支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」

前言

《支付宝客户端架构解析》系列将从支付宝客户端的架构设计方案入手，细分拆解客户端在“容器化框架设计”、“网络优化”、“性能启动优化”、“自动化日志收集”、“RPC 组件设计”、“移动应用监控、诊断、定位”等具体实现，带领大家进一步了解支付宝在客户端架构上的迭代与优化历程。

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

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

背景

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

设计思路

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

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

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

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

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

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

GC 抑制的实现

• 取消 softlimit 检测

• 取消 GC 线程的唤醒

• 取消 GC 例程函数

• OOM 停止 GC 抑制的实现

1. 取消 softlimit 检测：

2. 取消GC线程的唤醒

3. 取消GC例程函数

4. OOM 停止GC抑制的实现

效果

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

小结

通过本节内容，我们初步了解了支付宝在 Android 客户端启动性能优化下的「垃圾回收」机制和具体实践，由于篇幅限制，很多技术要点我们无法一一展开。而相应的技术内核，我们同样应用在了 mPaaS 并对外输出，欢迎大家上手体验：

https://tech.antfin.com/docs/2/49549

关于 Android 端启动性能优化的设计思路和具体实践，同样期待你们的反馈，欢迎一起探讨交流。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=Nabc96883-30bb-4886-a5bb-a65252279e42