技术|Android安装包优化

版权声明

1.本文版权归原作者所有，转载需注明作者信息及原文出处。

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

3.作者公众号：V大师在一号线 。联系邮箱：[email protected]。

背景

安装包膨胀的原因

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

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

正是由于这些疏忽，安装包有了不必要的增加，这也是我们需要优化的部分。

安装包优化的价值

可能有的人觉得，现在基本是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标准。当有人不合理地引入资源，又或者业务下线后对无效逻辑置之不顾时，能有规则来约束这种行为。

参考

以上

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