技术|Android安装包优化

版权声明

1.本文版权归原做者全部，转载需注明做者信息及原文出处。

2.本文做者：赵裕(vimerzhao),永久连接：https://github.com/vimerzhao/vimerzhao.github.io/blob/master/android/2020-02-11-apk-size-opt.md。

3.做者公众号：V大师在一号线 。联系邮箱：vimerzhao@foxmail.com。

---

背景

安装包膨胀的缘由

业务的增长、产品的演进是安装包大小增长的本质缘由。可是在演进之路上，因为一些所谓的技术债务，如：

• 使用的资源未经裁剪（如全量字体文件、分辨率过大的图片）
• 不合理的大资源（如大的视频、音频能够在线拉取）
• 已下线业务没有及时清理相关代码、资源
• 等等

正是因为这些疏忽，安装包有了没必要要的增长，这也是咱们须要优化的部分。

安装包优化的价值

可能有的人以为，如今基本是4G、WiFi的网络环境，手机设备的性能和存储空间也很是充足，因此用户对安装包大小应该不是十分敏感。可是，这实际上是一种错觉，更多的时候应该看本身的目标市场，若是是一二线城市固然没问题，但若是是三四线城市、农村等下沉市场或者印度、巴西等海外市场，上述假设显然不成立了。

通常来讲，安装包大小会影响如下指标：

• 下载转化率
• 安装成功率
• 推广成本
• 运行内存、空间占用

综上，对于一个“有余力”的团队，安装包大小的优化仍是颇有必要的。

安装包优化的套路

由前面的缘由可知，从业务层面来看，安装包大小的优化是“解铃还须系铃人”，即：

• 压缩资源
• 大资源转成在线拉取
• 排查无用业务并下线

这些方法都比较常规，更像是对症下药，下面梳理一些技术上普适的方法，独立于业务，在上面那些方法都尝试后，还可使安装包大小“更下一层楼”。

安装包的主要构成就是代码和资源，因此优化也是从这两个方面着手。

代码

混淆

通常是经过ProGuard，但不少用很差，且存在管理问题。最后一看项目，不少类被Keep住了，也不知道历史背景是啥。

Dex优化

1. 经过工具移除行号信息，带来的问题是没法回溯Crash位置，但能够解决
2. 多Dex时，经过重排Dex避免交叉索引，实现起来比较复杂
3. Dex压缩，把实际的Dex压缩，首次启动经过一个壳去加载，会影响启动速度，可是能够解决，也比较复杂

so优化

so的优化手段和Java代码其实比较相似，核心仍是经过机制化的手段去裁剪、压缩。

资源

资源自己

• 经过工具扫描无用资源，有些因为项目自身缘由，可能没有显式引用，但外置的编译脚本会修改项目自身脚本，这就很坑了
• 资源格式的优化，如PNG转JPG（除去alpha通道），转webp格式等
• 字体文件只保留使用的，资源自身的二次优化

资源索引

经过AndResGuard工具压缩资源名称，进而下降索引文件的大小。

感悟

核心思想

• 删除不用的（显而易见）
• 压缩/转移有用的（如图片、字体文件，如大资源的转移，混淆信息的map表也是一种转移）
• 精简系统产生的（dex重排）

常规的手段很容易到达瓶颈，高深的手段又有复杂、兼容性等诸多问题，但综合来看，仍是两点：

• 深入理解底层：apk编译流程、dex格式、资源引用、启动流程、加载流程原理等
• 深入理解工具：ProGuard（不少人的ProGuard配置都是Copy修改），ReDex，AndResGuard等

权衡之道

不少时候，优化就是权衡，重要的是取舍：

• 压缩了Dex，就增长了启动速度
• 拿掉了行号，就增长了恢复Crash堆栈的难度
• 混淆了代码，就增长了编译脚本的复杂度
• 等等

根本出路

• 创建监控：团队每一年都会优化一次安装包大小，尤为是删除、压缩资源的时候，老是一头雾水，不明白这个资源引入的目的，也不敢轻举妄动。最后有一套系统，让增量时有记录，让下线时有提醒，及时解决，而不是每到年末还一次技术债。
• 制定标准：某种意义上上，安装包大小的优化不是某我的的事情，而是团队的事情，最好有相关的实践指南或CodeReview标准。当有人不合理地引入资源，又或者业务下线后对无效逻辑置之不顾时，能有规则来约束这种行为。

参考

• Android安装包精简系列之为何要优化精简安装包 | 子勰的博客
• Android安装包相关知识汇总
• 如何优雅地将你的APK安装包减小20% - 简书
• 22 | 包体积优化（上）：如何减小安装包大小？
• 23 | 包体积优化（下）：资源优化的进阶实践

以上

---

欢迎扫码关注做者公众号，及时获取最新信息。