Android安装包优化

赵裕(vimerzhao)
本文约 1600 字，阅读需 4 分钟。

背景

安装包膨胀的原因

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

  • 使用的资源未经裁剪（如全量字体文件、分辨率过大的图片）

  • 不合理的大资源（如大的视频、音频可以在线拉取）

  • 已下线业务没有及时清理相关代码、资源

  • 等等

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

安装包优化的价值

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

参考

以上

总阅读量次。