版权声明
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优化
- 通过工具移除行号信息，带来的问题是无法回溯Crash位置，但可以解决
- 多Dex时，通过重排Dex避免交叉索引，实现起来比较复杂
- 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 | 包体积优化（下）：资源优化的进阶实践
以上
欢迎扫码关注作者公众号，及时获取最新信息。
