Android安装包优化

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

总阅读量次。