支付宝 App 构建优化解析：经过安装包重排布优化 Android 端启动性能

时间 2019-11-07

标签支付宝 app 构建优化解析经过安装重排 android 启动性能栏目 Android 繁體版

原文原文链接

1. 前言

本章节咱们将围绕《支付宝 App 构建优化解析》另启新系列，细分拆解客户端在“代码管理”、“证书管理”、“版本管理”、“构建打包”等维度的具体实现方案展开讨论，带领你们进一步了解支付宝在 App 构建模块下的持续优化。android

本节将主要记录经过对支付宝 Android Apk 文件的从新布局，来改善 IO 性能的过程。算法

2. 背景

支付宝 App 在 Android 平台上，因为大量业务快速上线，Android 长尾机型等缘由，形成启动阶段及部分核心链路上，性能体验不理想，进而影响用户的使用的感觉。从纯业务角度，能够经过优化 UI 布局，优化代码结构，优化 bundle 加载等方式，对性能体验有所改善。做为工程技术团队，按照传统思惟来看，彷佛没法对性能优化作多少贡献。通过一些方案调研后，咱们尝试经过对编译产物的优化，干预构建流程，以提高 App 性能。shell

3. 原理

布局先后，Apk 中实际的文件并无本质改变，只有位置发生了变化。那么为何这样的调整会有性能形成影响？这个原理要追溯到 Linux 的文件系统机制。缓存

以下图所示，Linux 底层文件系统中 VFS 上次 App 进程之间，存在一层 pagecache，pagecache 由内存中的物理 page 组成，其内容对应磁盘上的 block。Pagecache 的大小是动态变化的，能够扩大，也能够在内存不足时缩小。Cache 缓存的存储设备被称为后备存储（backing store），一个 page 一般包含多个 block，这些 block 不必定是连续的。性能优化

当内核发起一个读请求时（例如进程发起 read() 请求），首先会检查请求的数据是否缓存到了 pagecache 中。若是有，那么直接从内存中读取，不须要访问磁盘，这被称为 cache命中（cache hit）。若是 cache 中没有请求的数据，即 cache 未命中（cache miss），就必须从磁盘中读取数据。cookie

而后内核将读取的数据缓存到 cache 中，这样后续的读请求就能够命中 cache 了。Page 能够只缓存一个文件部分的内容，不须要把整个文件都缓存进来。对磁盘的数据进行缓存从而提升性能主要是基于两个因素：架构

第一，磁盘访问的速度比内存慢好几个数量级（毫秒和纳秒的差距）。app
第二是被访问过的数据，有很大几率会被再次访问。框架

结合 Android 系统实际来看，上层 App 每次读取磁盘时，文件系统默认会按 16 * 4k block 去磁盘读取数据，并把数据放到 pagecache 中。若是下次读取文件已经在 pagecache 中，则不会发生真实的磁盘 IO，而是直接从 pagecache中读取，大大提高读的速度。有缓存就有回收，pagecache 的另外一个重要工做是释放 page，从而释放内存空间。Cache 回收的任务是选择合适的 page 释放，而且若是 page 是 dirty 的，须要将 page 写回到磁盘中再释放。ide

理想的作法是释放距离下次访问时间最久的 page，可是很明显，这是不现实的。基于 LRU改进的 Two-List 是 Linux 使用的策略。这个回收策略很是相似业务开发领域，常见的图片加载的缓存策略。LRU 算法是选择最近一次访问时间最靠前的 page，即干掉最近没被光顾过的 page。原始 LRU 算法存在的问题是，有些文件只会被访问一次，可是按照 LRU 的算法，即便这些文件之后不再会被访问了，可是若是它们是刚刚被访问的，就不会被选中。

Two-List 策略维护了两个list，active list 和 inactive list。在 active list 上的 page 被认为是 hot 的，不能释放。只有 inactive list 上的 page 能够被释放的。首次缓存的数据的 page 会被加入到 inactive list 中，已经在 inactive list 中的 page 若是再次被访问，就会移入 active list 中。两个链表都使用了伪 LRU 算法维护，新的 page 从尾部加入，移除时从头部移除，就像队列同样。

若是 active list 中 page 的数量远大于 inactive list，那么 active list 头部的页面会被移入 inactive list 中，从而维持两个表的平衡。简单的说，经过文件重布局的目的，就是将启动阶段须要用到的文件在 APK 文件中排布在一块儿，尽量的利用 pagecache 机制，用最少的磁盘 IO 次数，读取尽量多的启动阶段须要的文件，减小 IO 开销，从而达到提高启动性能的目的。

4. 落地方案

在了解原理以后，就须要考虑怎么用工程化的方案在支付宝 App 上落地，主要从如下三个流程来设计方案并落地。

度量：

重布局的前提必须是精确的度量，定位到那些能够调整，须要调整的文件。这个过程须要足够的准确，不然会致使重布局以后的效果不佳。度量的最终目的是要，统计到支付宝启动阶段，哪些文件加载了，而且是发生真实的磁盘IO，仍是命中了 pagecache 缓存。咱们提供了一个度量工具，经过修改 kernel 源码，dump 出文件系统的 IO 行为，在特定的 Android ROM 上打个补丁，用来统计启动时刻文件行为。部分数据以下：

数据中，第一列的数据表示发生 IO 行为的文件，第二列表示该文件中此偏移量对应的部分发生了 IO 行为。

第三列表示发生 IO 的位置，若是为 0，则表示发生了真实的磁盘 IO；若是为 1，则表示从pagecache 缓存中读取了内容。

经过数据能够发现，Apk 中部分文件，其实是发生了磁盘 IO，能够尝试将启动阶段， Apk 中所用到的文件排布到一块儿，指望经过少许的 IO，就将全部的文件所有读到。以后的工做，须要经过解析 zip 包结构，将上述结果中，文件偏移量对应到详细的文件名。首先须要获得安装包中的文件排布状况，能够经过相似 010 Editor 的工具获得，为了工程化的考虑，也能够参考 zip 格式定义经过脚本分析 zip 文件实现。

而后经过解析结果和先前的统计结果对应分析，就能找到 zip 中哪些文件，在启动阶段被读到，为重布局提供数据支撑。

重布局：

在获得一个启动阶段的文件列表后，第二步工做，就是根据这个文件列表，在构建打包阶段，在 Apk 中把这部分文件排布在一块儿。这里须要修改 7z 压缩工具的源码。支付宝构建流程，为了提高压缩效率，减小包大小，使用 7z 工具进行最后压缩出 Apk 的过程。这里在简单阐述下，重排布的缘由，不管是那种压缩工具，zip 中文件顺序是文件系统的默认顺序，即按照阿拉伯数字和字母顺序。若是想指定文件排在一块儿，必然要打破这种规则。修改 7z 源码的过程，简单思路以下，扩展一个命令行参数，咱们使用了上箭头'^'(表意性强，提早的意思)，能够传入 list.txt，而后 7z 执行输出文件流时候，按照 list 中的文件顺序，改变最后的输出顺序，从而达到重排布的目的。例如以下命令，就是将 source 目录中，全部文件压缩，而且把 list 中指定文件排布在 zip 包的开始位置。

7z a -tzip archive.zip source* ^list.txt

经过这种方式，就实现了文件重排布的简单过程，固然在支付宝的构建流程中，较为复杂，中间还涉及到重打包，重签名等一系列流程。后续内容会提到。这里有一个小插曲，在刚开始调整文件顺序时，咱们经过测量发现效果并很差。后来发现了缘由，原先咱们调整的文件列表，只是度量阶段发现，全部发生磁盘 IO 的文件，把他们排布到一块儿，错误的认为，只要他们调整了，总体 IO 状况就会改善。但是忽略了“此消彼长”的问题，若是只调整这些文件，那么原先排布在这些文件后面，利用预读机制进缓存 cache 的文件，若是在启动阶段用到，可能会发生新的磁盘 IO。正确的调整方式，应该能精确按时间顺序统计启动阶段的全部文件，排布在一块儿，这样发生少许 IO，就能所有读到 cache 中。简单看下某一次实验主 Apk 中文件调整先后的效果以下，几个和配置相关的移到文件头部。

调整前

调整后

回归测试：

按照全部计划将文件所有调整完毕后，就到了验证效果的环节。主要有如下几种验证方式和思路：

线下录屏，而后拆解视频帧，测直观的启动时间。
线下使用工具度量 IO 状况，观察启动阶段磁盘 IO 数量是否减小，量化一个“cache miss 率”的概念。
线下经过埋点的方案，经过脚本，屡次模拟冷启动，取平均值测量，消除可能偏差，观察趋势。
线上灰度在其余优化和代码相似状况下，只经过调整 IO，比较两个版本的启动时间变化。在重布局方案实验阶段，使用一二两种方案较多，后续工程化落地和常态化优化时，应采用三四种方案。

5. 演进

经过上述落地方案，在线下以及某些线上灰度版本中完成初步实验后，咱们考虑工程化，常态化的进行这件事情。在工程化以前，先对度量流程进行了扩充，探索出了一种较为简单的度量手段。

度量优化：

原先的度量方案，具有较深的技术含量，在这个方案中，须要对 Linux 底层文件系统非要熟悉和了解，而且还需具有修改源码的能力，此方案是由其余资深专家指导下实现，短时间内，团队暂时没法独立这个方案。为了让总体方案可控，咱们想到了直接在 Android 源码的资源加载流程中记录日志，而后经过日志直接分析，这样启动阶段文件加载一目了然，固然缺陷也很明显，没法经过判断文件读取是经过磁盘 IO 仍是 pagecache 缓存。干预资源加载记录，要不经过 hook 方式，要不就是直接改 framework，刷个 ROM，考虑到工程化自动化测试的因素，采用了修改 framework 的方式，方便后续有测试平台，直接使用特定手机跑脚本执行便可。以 Android 7.0 版本为例，主要修改 drawable 相关流程和 xml 相关流程。其余版本若是作测试度量机型的化，修改方式相似。

xml 加载流程修改，在解析 xml 文件流程，直接打日志。

/** * Loads an XML parser for the specified file. * * @param file the path for the XML file to parse * @param id the resource identifier for the file * @param assetCookie the asset cookie for the file * @param type the type of resource (used for logging) * @return a parser for the specified XML file * @throws NotFoundException if the file could not be loaded */
    @NonNull
    XmlResourceParser loadXmlResourceParser(@NonNull String file, @AnyRes int id, int assetCookie, @NonNull String type) throws NotFoundException {
        if (id != 0) {
            try {
                synchronized (mCachedXmlBlocks) {
                    if (!getResourcePackageName(id).equalsIgnoreCase("android")) {
                        Log.i("AlipayRes", "ResourceId: " + Integer.toHexString(id) + " ResourcePackage name: " + getResourcePackageName(id) + " Loading xml: " + file);
                    }
                    final int[] cachedXmlBlockCookies = mCachedXmlBlockCookies;
                    final String[] cachedXmlBlockFiles = mCachedXmlBlockFiles;
                    final XmlBlock[] cachedXmlBlocks = mCachedXmlBlocks;
                    // First see if this block is in our cache.
                    final int num = cachedXmlBlockFiles.length;
                    for (int i = 0; i < num; i++) {
                        if (cachedXmlBlockCookies[i] == assetCookie && cachedXmlBlockFiles[i] != null
                                && cachedXmlBlockFiles[i].equals(file)) {
                            return cachedXmlBlocks[i].newParser();
                        }
                    }
            ……
            ……
    }
复制代码

drawable 修改

/** * Loads a drawable from XML or resources stream. */
    private Drawable loadDrawableForCookie(Resources wrapper, TypedValue value, int id, Resources.Theme theme) {
        if (value.string == null) {
            throw new NotFoundException("Resource \"" + getResourceName(id) + "\" ("
                    + Integer.toHexString(id) + ") is not a Drawable (color or path): " + value);
        }

        final String file = value.string.toString();

        if (TRACE_FOR_MISS_PRELOAD) {
            // Log only framework resources
            if ((id >>> 24) == 0x1) {
                final String name = getResourceName(id);
                if (name != null) {
                    Log.d(TAG, "Loading framework drawable #" + Integer.toHexString(id)
                            + ": " + name + " at " + file);
                }
            }
        }

        if (DEBUG_LOAD) {
            Log.v(TAG, "Loading drawable for cookie " + value.assetCookie + ": " + file);
        }
        if (!getResourcePackageName(id).equalsIgnoreCase("android")) {
            Log.i("AlipayRes", "ResourceId: " + Integer.toHexString(id) + " ResourcePackage name: " + getResourcePackageName(id) + " Loading drawable: " + file);
        }
        ……
        ……
    }
复制代码

刷入 ROM，替换修改后 framework 后，冷启动支付宝，清楚缓存，经过日志过滤便可获得完整启动文件加载列表。

adb shell am force-stop com.eg.android.AlipayGphone
adb shell
echo 1 > /proc/sys/vm/drop_caches
复制代码

工程化：

因此单点能力都基本具有单点能力都具有后，须要找到一个能尽量自动化的方案。具体流程图以下。后续对于 ReApk （优化Apk）流程，能够扩展其余的构建构建产物优化方案。

6. 结果与展望

目前总体方案，已上线支付宝钱包 Android App，该单项，启动性能，在总体全量用户下有 5% 左右的优化效果，低端机上效果较明显，根据不一样机型，能有10%左右的启动性能优化效果。

Facebook 的工具链优化方案 Redex，对于 dex 的优化，从度量到回归测试，开源出了一整套解决方案，对于 zip 的重布局，但愿将来能将此整套方案，作到尽量的“开箱即用”，赋能公司内外更多的 App。

7. 小结

经过本节内容，咱们初步了解了支付宝在 Android 客户端如何经过安装包重排布来优化 IO 性能。因为篇幅限制，不少技术要点咱们没法一一展开。而相应的技术内核，咱们一样应用在了 mPaaS 并对外输出，欢迎你们上手体验：

tech.antfin.com/docs/2/4954…

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

往期阅读

《开篇 | 模块化与解耦式开发在蚂蚁金服 mPaaS 深度实践探讨》

《支付宝移动端动态化方案实践》

《支付宝客户端架构解析：iOS 容器化框架初探》

《支付宝客户端架构解析：Android 容器化框架初探》

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