这是我参与11月更文挑战的第2天，活动详情查看：2021最后一次更文挑战

为什么需要优化包体积

上图是Google透露的安装包体积与下载转化率的关系图（来自Google Play）

显然，包体积越大，转化率越低。包体积的影响有：

• 下载转化率：

  • 大部分地区的网络状况并不好（不稳定），越大的安装包下载中越容易受到网络影响造成下载失败，降低用户下载意愿。
  • 网络流量费用，造成手机流量用户下载意愿降低
  • 设备空间限制等
  • 以上问题，都会造成包体积越大，下载转化率越低

• 推广成本：

  • 应用市场等推广应用时，大体积安装包下载时占用的带宽高，也就造成推广费用高。

    • 部分厂商对包体积有限制（如苹果App Store限制超过150MB时，只能使用wifi下载等）

  • 设备预装应用，受限设备预留应用空间限制，会挤压其它应用的空间。

如何分析应用包体积

• 针对应用的情况，一般需要分析：

  • 资源文件：图片、音频、视频
  • 库：动态库、静态库
  • 源代码：代码、函数
  • 其它：签名、证书、配置

ios 可以参考：github.com/huanxsd/Lin…

包体积分析思路

这里主要以ios作为分析，分析主要以源代码为主

资源文件

• 减少不必要的资源文件

• 选择更优压缩率的格式

• 极端的，可以考虑对图片色域做限制，提高压缩效果

库

• 移除不必要的库

• 尝试设备/系统提供公共库，能共用的可以考虑兼容

  • 版本可能不符合预期，需要适配

• 重新编译库，关闭库内不需要的功能

  • 如有，可以选择lite版本的库

• 使用 -Oz 编译

• 关闭异常功能

  • 异常机制会在代码中增加多个数据去维持，关闭异常可能有10%左右的包体积优化

• 开启LTO（仅ios）

代码

• 修改高频调用的inline接口与宏

  • 高频使用的inline接口或宏，在其展开代码量较大时，会造成成百上千倍的包体积增加。

• 结构体内存对齐：

  • 尽可能使结构体对齐4byte或8byte（考虑到现有64位系统越来越多，只对齐8byte基本满足需求）

• 使用合理的 enum class 范围：

  • 对大部分 enum class 来说，都不用上 4byte 的范围，可以考虑缩小到 1byte。

• 使用时间换空间的方式：

  • 比如使用vector替换hashmap等，具体收益不好说，需要拿数据说话

• 针对系统特性的优化：

  • 比如ios以往会对 text 端加密，这样会降低压缩率。可以考虑重命名解决