通过安装包重排布优化 Android 端启动性能

  • 时间:
  • 浏览:0
  • 来源:大发5分快乐8APP下载_大发5分快乐8APP官方

……

通过你这人方法 ,就实现了文件重排布的简单过程,当然在支付宝的构建流程中,较为僵化 ,里面还涉及到重打包,重签名等一系列流程。后续内容会提到。

这里另一个多小插曲,在开始英语 英语 调整文件顺序时,大伙儿通过测量发现效果从不好。之前 发现了导致 ,那我大伙儿调整的文件列表,要是我度量阶段发现,所有占据 磁盘 IO 的文件,把大伙儿排布到共同,错误的认为,只要大伙儿调整了,整体 IO 具体情况就会改善。那我忽略了“此消彼长”的大大问题 ,之前 只调整哪此文件,没人 那我排布在哪此文件里面,利用预读机制进缓存 cache 的文件,之前 在启动阶段用到,之前 会占据 新的磁盘 IO。正确的调整方法 ,应该能精确按时间顺序统计启动阶段的所有文件,排布在共同,那我占据 少量 IO,就能全部读到 cache 中。

简单看下某一次实验主 Apk 中文件调整前后的效果如下,2个和配置相关的移到文件头部。

final String name = getResourceName(id);

if ((id >>> 24) == 0x1) {

*/

if (id != 0) {

if (DEBUG_LOAD) {

1. 前言

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

原文发布时间为:2018-11-29

}

……

final String[] cachedXmlBlockFiles = mCachedXmlBlockFiles;



之前 内核将读取的数据缓存到 cache 中,那我后续的读请求就不能命中 cache 了。Page 不能只缓存另一个文件部分的内容,不时需把整个文件都缓存进来。对磁盘的数据进行缓存从而提高性能主要是我基于另一个因素:

XmlResourceParser loadXmlResourceParser(@NonNull String file, @AnyRes int id, int assetCookie,

按照什么都有计划将文件全部调整完毕后,就到了验证效果的环节。主要有以下几种验证方法 和思路:

* Loads an XML parser for the specified file.

……

5. 演进

2. 背景

布局前后,Apk 中实际的文件并没人 本质改变,不不能位置占据 了变化。没人 为哪此那我的调整会有性能造成影响?你这人原理要追溯到 Linux 的文件系统机制。

* @return a parser for the specified XML file

……

/**

if (!getResourcePackageName(id).equalsIgnoreCase("android")) {

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

当内核发起另一个读请求时(同类程序发起 read() 请求),首先会检查请求的数据否有缓存到了 pagecache 中。之前 有,没人 直接从内存中读取,不时需访问磁盘,这被称为 cache命中(cache hit)。之前 cache 中没人 请求的数据,即 cache 未命中(cache miss),就时需从磁盘中读取数据。

try {

private Drawable loadDrawableForCookie(Resources wrapper, TypedValue value, int id,

支付宝 App 在 Android 平台上,之前 少量业务快速上线,Android 长尾机型等导致 ,造成启动阶段及部分核心链路上,性能体验不理想,进而影响用户的使用的感受。

从纯业务淬硬层 ,不能通过优化 UI 布局,优化代码社会形态,优化 bundle 加载等方法 ,对性能体验有所改善。作为工程技术团队,按照传统思维来看,似乎无法对性能优化做2个贡献。经过有些方案调研后,大伙儿尝试通过对编译产物的优化,干预构建流程,以提升 App 性能。

@NonNull

adb shell am force-stop com.eg.android.AlipayGphone

adb shell

调整前

* @param assetCookie the asset cookie for the file

final int num = cachedXmlBlockFiles.length;

return cachedXmlBlocks[i].newParser();

3. 原理

* @param type the type of resource (used for logging)

* Loads a drawable from XML or resources stream.

drawable 修改

}

刷入 ROM,替换修改后 framework 后,冷启动支付宝,清楚缓存,通过日志过滤即可得到全部启动文件加载列表。

}

if (TRACE_FOR_MISS_PRELOAD) {



for (int i = 0; i < num; i++) {

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

if (name != null) {

echo 1 > /proc/sys/vm/drop_caches

在得到另一个启动阶段的文件列表后,第二步工作,要是我根据你这人文件列表,在构建打包阶段,在 Apk 中把这部分文件排布在共同。这里时需修改 7z 压缩工具的源码。支付宝构建流程,为了提升压缩传输时延,减少包大小,使用 7z 工具进行最后压缩出 Apk 的过程。这里在简单阐述下,重排布的导致 ,无论是那种压缩工具,zip 中文件顺序是文件系统的默认顺序,即按照阿拉伯数字和字母顺序。之前 想指定文件排在共同,必然要打破你这人规则。

修改 7z 源码的过程,简单思路如下,扩展另一个命令行参数,大伙儿使用了上箭头'^'(表意性强,提前的意思),不能传入 list.txt,之前 7z 执行输出文件流那我,按照 list 中的文件顺序,改变最后的输出顺序,从而达到重排布的目的。同类如下命令,要是我将 source 目录中,所有文件压缩,之前 把 list 中指定文件排布在 zip 包的开始英语 位置。

}

重布局的前提时需是精确的度量,定位到哪此不能调整,时需调整的文件。你这人过程时需足够的准确,之前 会导致 重布局那我的效果不佳。

度量的最终目的是要,统计到支付宝启动阶段,哪此文件加载了,之前 是占据 真实的磁盘IO,还是命中了 pagecache 缓存。大伙儿提供了另一个度量工具,通过修改 kernel 源码,dump 出文件系统的 IO 行为,在特定的 Android ROM 上打个补丁,用来统计启动时刻文件行为。部分数据如下:

 ●  工程化:

什么都有单点能力都基本具备单点能力都具备后,时需找到另一个能尽之前 自动化的方案。具体流程图如下。

后续对于 ReApk (优化Apk)流程,不能扩展有些的构建构建产物优化方案。

那我的度量方案,具备较深的技术含量,在你这人方案中,时需对 Linux 底层文件系统不不能熟悉和了解,之前 还需具备修改源码的能力,此方案是由有些资深专家指导下实现,短期内,团队暂时无法独立你这人方案。

为了让整体方案可控,大伙儿想到了直接在 Android 源码的资源加载流程中记录日志,之前 通过日志直接分析,那我启动阶段文件加载一目了然,当然不足英文也很明显,无法通过判断文件读取是通过磁盘 IO 还是 pagecache 缓存。

干预资源加载记录,要不通过 hook 方法 ,要不要是我直接改 framework,刷个 ROM,考虑到工程化自动化测试的因素,采用了修改 framework 的方法 ,方便后续有测试平台,直接使用特定手机跑脚本执行即可。

以 Android 7.0 版本为例,主要修改 drawable 相关流程和 xml 相关流程。有些版本之前 做测试度量机型的化,修改方法 同类。

}

 ●  线下使用工具度量 IO 具体情况,观察启动阶段磁盘 IO 数量否有减少,量化另一个“cache miss 率”的概念。 ●  线下通过派发的方案,通过脚本,多次模拟冷启动,取平均值测量,消除之前 误差,观察趋势。

 ●  线上灰度在有些优化和代码同类具体情况下,只通过调整 IO,比较另一个版本的启动时间变化。 在重布局方案实验阶段,使用一二某种方案较多,后续工程化落地和常态化优化时,应采用三某种方案。

 ●  第二是被访问过的数据,有很为宜率会被再次访问。

结合 Android 系统实际来看,上层 App 每次读取磁盘时,文件系统默认会按 16 * 4k block 去磁盘读取数据,并把数据放上去 pagecache 中。之前 下次读取文件之前 在 pagecache 中,则不不占据 真实的磁盘 IO,要是我直接从 pagecache中 读取,大大提升读的传输时延。有缓存就有回收,pagecache 的那我重要工作是释放 page,从而释放内存空间。Cache 回收的任务是挑选 为宜的 page 释放,之前 之前 page 是 dirty 的,时需将 page 写回到磁盘中再释放。

如下图所示,Linux 底层文件系统中 VFS 上次 App 程序之间,占据 一层 pagecache,pagecache 由内存中的物理 page 组成,其内容对应磁盘上的 block。Pagecache 的大小是动态变化的,不能扩大,不不能在内存不足英文时缩小。Cache 缓存的存储设备被称为后备存储(backing store),另一个 page 通常涵盖多个 block,哪此 block 不一定是连续的。

* @param id the resource identifier for the file

if (cachedXmlBlockCookies[i] == assetCookie && cachedXmlBlockFiles[i] != null

*

}

本文作者:瑞涵

synchronized (mCachedXmlBlocks) {

@NonNull String type)

Log.i("AlipayRes", "ResourceId: " + Integer.toHexString(id) + " ResourcePackage name: " + getResourcePackageName(id) + " Loading xml: " + file);

*/

if (!getResourcePackageName(id).equalsIgnoreCase("android")) {

}

final XmlBlock[] cachedXmlBlocks = mCachedXmlBlocks;

4. 落地方案

之前 active list 中 page 的数量远大于 inactive list,没人 active list 头部的页面会被移入 inactive list 中,从而维持另一个表的平衡。简单的说,通过文件重布局的目的,要是我将启动阶段时时需到的文件在 APK 文件中排布在共同,尽之前 的利用 pagecache 机制,用为宜的磁盘 IO 次数,读取尽之前 多的启动阶段时需的文件,减少 IO 开销,从而达到提升启动性能的目的。

* @param file the path for the XML file to parse



throw new NotFoundException("Resource \"" + getResourceName(id) + "\" ("

+ Integer.toHexString(id) + ") is not a Drawable (color or path): " + value);

}

}

理想的做法是释放距离下次访问时间最久的 page,之前 很明显,这是不现实的。基于 LRU改进的 Two-List 是 Linux 使用的策略。你这人回收策略非常同类业务开发领域,常见的图片加载的缓存策略。LRU 算法是挑选 最近一次访问时间最靠前的 page,即干掉最近没被光顾过的 page。原始 LRU 算法占据 的大大问题 是,有些文件只会被访问一次,之前 按照 LRU 的算法,即使哪此文件那我再要是我会被访问了,之前 之前 它们是那我被访问的,就不不被选中。

第一列表示占据 IO 的位置,之前 为 0,则表示占据 了真实的磁盘 IO;之前 为 1,则表示从pagecache 缓存中读取了内容。

}

// First see if this block is in our cache.

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



/**

// Log only framework resources

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

数据中,第一列的数据表示占据 IO 行为的文件,第二列表示该文件中此偏移量对应的部派占据 了 IO 行为。

throws NotFoundException {

&& cachedXmlBlockFiles[i].equals(file)) {

本节将主要记录通过对支付宝 Android Apk 文件的重新布局,来改善 IO 性能的过程。

if (value.string == null) {

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

在了解原理那我,就时需考虑为社 么用工程化的方案在支付宝 App 上落地,主要从以下另一个流程来设计方案并落地。

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

Log.i("AlipayRes", "ResourceId: " + Integer.toHexString(id) + " ResourcePackage name: " + getResourcePackageName(id) + " Loading drawable: " + file);

Log.d(TAG, "Loading framework drawable #" + Integer.toHexString(id)

* @throws NotFoundException if the file could not be loaded

final int[] cachedXmlBlockCookies = mCachedXmlBlockCookies;

Resources.Theme theme) {

调整后

+ ": " + name + " at " + file);

通过数据不能发现,Apk 中部分文件,实际上是占据 了磁盘 IO,不能尝试将启动阶段, Apk 中所用到的文件排布到共同,期望通过少量的 IO,就将所有的文件全部读到。那我的工作,时需通过解析 zip 包社会形态,将上述结果中,文件偏移量对应到全部的文件名。首先时需得到安装包中的文件排布具体情况,不能通过同类 010 Editor 的工具得到,为了工程化的考虑,不不能参考 zip 格式定义通过脚本分析 zip 文件实现。

}

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



Log.v(TAG, "Loading drawable for cookie " + value.assetCookie + ": " + file);

本文来自云栖社区战略协作伙伴“安卓巴士Android开发者门户”,了解相关信息不能关注“安卓巴士Android开发者门户”。