性能优化：得物App包体积治理之路
背景
包体积优化，或者说包体积瘦身，相较于 crash 治理、卡顿优化、启动优化等比较硬性的指标来说，优先级可能没有那么高。特别是对于一些孵化期和成长期的 App 来说，用户量、DAU 没有上去之前，来进行包体积瘦身收益也不高。但是对于得物这种千万日活的 App 来说，进行包体积的瘦身还是具有蛮大意义的，为此，得物 App 也投入了不少资源来对包体积进行一系列的优化。
在介绍优化手段之前，我们先梳理下包体积瘦身的意义：
包体积瘦身最主要的好处是对应用 下载转化率 的影响，在不考虑外部因素影响下，如果你的 App 相较竞品 App 体积要更小的话，那么用户下载的欲望可能要高一些
包体积变小，运营增长投放的成本也能降低，对用户来说，获取安装包的流量成本也变小，下载等待时间也越短，心理上的下载欲望也会有所提升
包体积越小，代表安装时候所需要的文件拷贝、Library 解压、签名校验等花费的时间越短，也就可以获得更快的安装速度
包体积瘦身也能为 App 的启动和运行性能带来正收益
APK 的组成
解压一个 APK 后，我们会发现 Android 安装包主要由 libs(就是so文件)、assets、res以及code(dex)组成。大部分应用中，这些内容都占了安装包99%的体积。毫无疑问，我们的优化也必然要从这几个方面着手切入。
资源相关优化
RES 资源
资源相关的部分包括 res、assets、编译后的二进制资源文件 resources.arsc 和 清单文件 等，这一部分的优化效果是相对来说最容易、收益最高的。
其中， res 目录下的文件在打包的过程中会由 aapt2 自动生成对应的资源 ID，并且保存在 .R 文件中，但 .R 文件仅仅只是保证编译程序不会报错，实际上在应用运行时，系统会根据 ID 寻找对应的资源路径，而 resources.arsc 文件就是用来记录这些 ID 和 资源文件位置对应关系 的文件。
在绝大部分 App 中， res 目录下体积占比较高的当属图片和xml文件了。AAPT2 在打包 res 下的过程中，又可分为编译和链接两个部分：
在编译阶段，aapt2会解析输入的源文件并生成一个扩展名为 .flat 的中间二进制文件。默认情况下，此阶段会对所有 PNG 文件进行压缩，AAPT2 对于 PNG 图片的压缩可以分为三个方面：
RGB 是否可以转化成灰度
透明通道是否可以删除
是不是最多只有 256 色（Indexed_color 优化）
虽然 AAPT2 默认支持对PNG图片的优化，但是它采用是是相对保守的 Indexed_color 算法，这是一种无损的压缩算法，如果我们想要更高的压缩率，可以使用一些其他的压缩工具，来集成到我们的编译打包流程中。
在链接阶段，AAPT2 会合并在编译阶段生成的所有中间文件（如资源表、二进制 XML 文件和处理过的 PNG 文件），并将它们打包成一个 APK。此外，在此阶段还会生成其他辅助文件，如 R.java 和 ProGuard 规则文件。
了解了资源打包的相关流程，那么对应的优化方案也就有了头绪。我们主要从以下四个方向切入:
减少res下的资源数目
这一部分主要是针对一些图片，可以通过cdn下发的就没必要存放在apk里面了；cdn下发的方案必然会带来流量上的消耗，这一部分的优化是通过图片库接入cdn格式转换、图片裁剪等手段来处理的。
压缩res下的图片体积
开发同学在资源添加的时候会先通过 tinypng等手段来对图片进行压缩，同时在代码合入阶段通过CI检测避免非法大图资源的合入，最后在打包过程中，集成了Gradle 压缩插件 shrink，来进一步对资源进行优化处理。
剔除res下的无用资源
这一部分没有做额外的处理，只是开启了 shrinkResources 选项。
合并res下的相同资源
res 下存在不少命名不同但是内容一样的资源，这种情况在组件化工程中特别常见，这一部分也是通过 shrink 插件来统一处理掉的。
Assets 资源
Assets 目录下的文件是通过 AssetManager 类的接口来获取，aapt2不会对它进行任何优化处理。同时，建立在Assets文件夹中的文件是只读的，自然也就无法通过下发资源的形式来进行处理。针对 Assets 下的资源，采取的方案也是裁剪与压缩两种模式。shrink 插件支持了对 Assets 目录下的图片进行压缩，裁剪则是通过代码调整的方式进行。
Assets 的裁剪主要从两个方面，一是检测出无用的Assets资源(通过ApkChecker,或者 gradle 插件均可做到)，然后删除掉；二是通过代码调整，将本来放在assets下的资源移到其他文件夹中，这样就可以通过资源下发的方式来进行处理。
这里总结下 shrink 插件目前提供了的功能：
res下的资源压缩，包括对png、gif、jpeg的压缩，对png和jpeg图片会首先尝试转换为webp格式
重复资源删除，基于CRC算法
Assets 图片压缩，同类型压缩，不会改变名称和格式
LIB 优化
libs下主要是一些 .so 文件，比较常规的是只保留一种abi架构，即通过 abiFilters 限定只让指定 abi 的 so 参与到最终的 mergeapk 流程。
得物 App 中使用到了大量的 so 来承载业务功能，其中大部分的 so 是通过动态下发的形式处理掉了，so 的动态下发功能主要由自研的 Yeezy动态资源管理平台 承载。除去下发的 so 外，APK 包内依然存在20M 左右的 so 库，这里的大部分是启动和首页就需要用到的；由于 App 体验的原因，这部分不适合进行下发；同时，我们目前存在 32 位和 64 位2套 ABI 架构，如何在兼顾体验与稳定性的同时，优化32位 so 的是我们接下来要处理的一个痛点。
DEX 优化
Dex 是 Android 系统的可执行文件，包含 应用程序的全部操作指令以及运行时数据。当 Java 程序被编译成 class 文件之后，还需要使用 dx 工具将所有的 class 文件整合到一个 dex 文件中，这样 dex 文件就将原来每个 class 文件中都有的共有信息合成了一体，这样做的目的是 保证其中的每个类都能够共享数据，这在一定程度上 降低了信息冗余，同时也使得 文件结构更加紧凑。
目前，得物 App 中接近一半的体积被 .dex 文件占据，同时随着业务迭代，DEX 体积还有逐步增多的趋势。DEX的主要优化一般是通过 ProGuard 来处理的，包括 压缩（Shrinking）、优化（Optimization） 和 混淆（Obfuscation）；对于商业 App 来说，一般很难做到 ProGuard 火力全开，在得物 App 中，Shrinking 和 Optimization 都是处于关闭状态，只有混淆是开启的。
Q：为什么要关闭 Shrinking 和 Optimization 呢？
因为使用到了大量三方库，其中有些库的功能导致无法开启 Shrinking 和 Optimization，比如开启Optimization 将导致热修无法使用；Proguard 中所做的优化包括 内联、修饰符、合并类和方法等 30 多种优化项，在特定的情况下，它尽可能地做了相应的优化。在无法开启 Optimization 的情况下我们可以借助插件在编译过程中，通过ASM接入字节码，从字节码层次来针对性的做一些优化，也就是选择性的将 Proguard 功能迁移到transform中去执行。
这里我们主要参考了 ByteX 和 Redex 中的实现，实现了常量内联、access 内联、R内联、方法删除等功能。可以看出，这一部分的优化依然存在很大的优化空间。同时基于 DEX 文件格式的一些优化，比如移除 release 包不需要的一些信息，比如支付宝debugItem移除 也将在后续版本迭代陆续实验推进。同时，Optimization 的逐步开放性调研，.dex 文件的动态下发均是将来需要持续跟进的。
包体积监控
包体积平台主要完成以下几件事情：
1. 监控包体积变化的趋势，解析 APK 中各类型资源详情
2. 以业务线的维度监控 APK 中各种类型资源的变化
3. 资源文件的追溯
4. APK 中依赖关系的梳理
5. APK 对比，发现迭代过程中产生的问题
引入包体积监控平台后，整体的打包流程如下：
解析Apk
要实现对 Apk 变化趋势的监控，前提条件是实现对每个 apk 的解析，我们的做法是基于开源的ApkChecker重新定制（主要是对并行出包、解析的支持），布置到远端服务上，Jenkins 打包成功后通知后端解析APK，后端调用ApkChecker 实现解析，拿到解析数据后再将数据落库。
业务线维度划分
实现划分基于业务线维度的资源报表，除了拿到解析的 APK 资源数据外，还需要知道数据的来源和归属的业务线；数据的来源可以向前追溯到具体的 AAR，AAR 的依赖和 AAR 中资源详情的采集可以通过在打包的过程中使用一个自定义的 gradle插件-dependency-analysis 拿到的，由于gradle打包过程中会将aar和jar都解压放置在指定的目录中，所以插件只需要到具体路径下拿到解压后的资源数据就可以了；这里我们采取的是收集
RUNTIME_CLASSPATH 类型的原始数据。
收集到了aar的数据并落库后，只需要将aar中的资源与apk中的资源做一层映射，便可建立关联。剩下的便只需将aar与业务线建立关联关系，如此便可实现业务线维度资源报表。
如何建立aar与业务线的关联呢？正好我们在做编译优化的时候，有建立一个组件管理平台--airforce，其中我们引入了一个基线的概念，每个apk版本都将与一个基线版本对应，基线版本下管理着该版本全部aar以及插件classpath配置；如此，只需要后端与airforce建立一次通信便可以拿到组件与业务线的关系了。
报警服务
当一个apk构建出来后，我们希望在开发阶段及时发现、及时修改，避免在灰度和上线的时候出现不可控的体积膨胀问题；报警服务正式为这一目的而存在的。
根据前面的介绍，当一个apk打包出来通知后端进行处理的时候，我们可以拿到apk解析后的数据、拿到资源与aar的关系、拿到aar与业务线的关系，以及aar相关负责人信息。接下来只需要指定报警规则，在解析apk之后进行报警校验，然后将报警数据打通飞书机器人通知到具体开发人员进行处理。
APK详情
包体积监控平台的其中一个目的是为了方便开发人员发现APK中可以优化的点，为了实现这一目标，在前端页面中实现将APK最终产物数据与aar原生产物数据进行聚合展示就比较有意义。
apk的产物分布负责直观的展示apk中这种类型文件的体积占比
依赖关系以业务线的维度展示构建apk的原始aar依赖关系
原始aar列表按解压后的体积降序展示，点击可以直观展示aar中的各资源详情
aar的展示主要可以用于发现功能重复的依赖，比如项目中同时存在Glide和Fresco，则可以考虑移除一个；以及方便业务同学判断so是否可以下发等。
大资源详情对应apk中体积比较大的资源，是资源优化的最要指导
在资源优化阶段，针对大资源的专项优化可以获得非常不错的收益，这一部分优化实施起来相对容易，属于风险小、收益高。优化阶段告一段落之后，则是需要对大资源的膨胀敏感监控，开发阶段及时预警。
优化建议直接展示 ApkChecker 检测出的各项问题
APK对比
项目的迭代过程中，体积是随着需求的增加而不断膨胀的，apk 的对比功能对于发现问题具有指导性的意义。目前 apk 对比功能实现了按照大文件类型的对比、aar依赖体积变更的对比以及 apk 中资源变更的对比。功能的实现难度不大，只需要从数据库中取出差异数据即可实现。
包体积监控平台上线后，版本迭代期间爆发性的体积膨胀得到了较好的控制。
展望
目前的包体积监控平台对资源类型的监控比较完善，但是对代码体积的监控相对就弱了些。后续再对 DEX 进行专项优化的同时也将同步完善 Code 类型文件的监控。在经过一系列的优化尝试之后，目前得物 App 中体积占比最大的 .dex 文件和 .so 文件是亟需优化的重中之重。
优化 DEX 也将围绕裁剪和优化两点展开，裁剪则是找到项目中没有用的代码进行删除，无用代码可以分为两类：一类是在业务角度出发，将一些功能重复的类合并，比如承载图片加载的只需要引入 fresco 从而删除 glide 的依赖；一类是从技术角度出发，找出线上真实无用代码，将找到的无用类通知到具体开发人员评估是否可以删除；优化则是从 DEX 文件格式的角度和 Proguard 优化的角度，参考 redex 等优化功能的实现，以独立插件的形式逐条落地，这一部分的挑战相对更大、采取的策略也将更为谨慎。
包体积瘦身是一个持续性的挑战，一方面业务功能在不断增加、不可避免带来代码量和资源的增加；另一方面是随着优化的进行，可操作空间的逐步压缩，优化的难度也越来越高。同时，如果贸然采用一些黑科技也将为稳定性带来更大的挑战，如何在保障稳定的同时优化包体积是一个需要不断探索的过程。路漫漫其修远兮，吾将上下而求索。
*文/jay