百度APP iOS端包体积50M优化实践(一)总览

一、前言

GEEK TALK

百度APP作为日活过亿的国民级应用，经过这些年的发展，从最初的搜索，发展到现在包含搜索、Feed、视频、直播、小说、购物、小程序、网盘和众多垂类模块的超级应用，为服务更多用户满足更多用户需求不断迭代，应用像滚雪球一样越滚越大，包体积从最初的几十MB发展到最高时的420MB，每个版本自然迭代会有至少3MB的涨幅，过大的包体积带来的负面作用开始显现，400M的体积对下载转化率和卸载率提出了很大的挑战，因此包体积成为百度超级APP发展的拦路虎。

22年Q3开启包体积优化项目，从编译器优化(OC&Swift&C++优化、LTO优化、剥离调试符号、三方SDK优化)、图片优化(无用图片、HEIC图片优化、Asset Catalog图片优化、图片压缩)、资源瘦身(大资源优化、无用配置文件、重复资源)、代码瘦身(无用类、无用方法、无用模块、精简重复代码、工具类瘦身、AB实验固化)和工程架构(Xcode打包、防劣化)等方向做优化。

在满足正常业务迭代情况下，优化落地收益50M，百度APP包体积从七月初的395M下降到十二月末的352M，同一时间段内，国内大厂主流APP中，微信从502M上涨到530M，抖音从390M上涨到432M，快手从310M上涨到357M。在很少的人力投入下取的这个成果，效率非常显著，此外，我们沉淀了各个优化方向的基建工具，完善了防劣化机制，为包体积持续优化和防止无序增长打下来坚实的基础。 

二、背景

GEEK TALK

2.1 包大小优化的必要性

2.1.1 包体积每增加6M，应用下载转化率下降1%

根据Google Play的统计：包体积每增加 6M，应用下载转化率下降 1%，APK包体大小每减少10MB ，全球平均下载转化率会提升1.75%，不同市场的数据各有不同，具体请参考如下图表。虽然AppStore没有给出类似数据，但是根据同样道理，安装包大小的减少必然会提升应用下载转化率。

2.1.2 App Store OTA下载大小限制，不利于APP的推广

下载包大小超出 200 MB 时 ，会出现两种情况：

• iOS 13 以下的用户，无法通过蜂窝数据下载 APP；
• iOS 13 及以上的用户，需要手动设置才可以使用蜂窝网络下载 APP。

2.1.3 磁盘不足时删除首选

下载包体积太大，会占用更多的设备存储空间，对于低存储的设备的用户也会有一定的影响，可能成为磁盘不够时的首选。

2.1.4 减少用户的下载意愿

如果蜂窝数据选型默认是低数据模式，那么下载包大小就更会影响用户决策，可能会减少用户的下载意愿。

2.1.5 其他负面影响

包体积太大，更多的的代码逻辑，加载的类太多，增加premain时间，带来比较慢的启动速度，同时增加启动阶段SIGKILL发生的概率，让性能等基础体验变差。此外，过于复杂冗余的代码还会增加代码修改的风险，所以包大小不是一个孤立的指标，它从侧面的反映出 APP 的健康状态。

2.2 安装包生成过程

在ipa包上传AppStore后，App Thinning会针对不同设备型号的硬件架构产生不同的编译产物，用户不同设备从AppStore会有不同的下载包，解压缩安装后是最后的安装包。

2.3 包体积指标

2.3.1 下载包大小和安装包大小

• 下载包大小是指APP压缩包(也就是 .ipa 文件)所占的空间，用户在下载APP时，下载的是压缩包，这样做可以节省流量；
• 当压缩包下载完成后，就会自动解压，解压过程也就是通常所说的安装过程，安装大小就是指压缩包解压后所占用的磁盘空间；
• 在Appstore产品信息页->信息->大小，看到数据是安装包大小，不是下载包大小，不同的系统安装包大小是不一样的；

• 那么苹果后台的下载大小和安装大小如何查看？
  开发者在iTues-Connect后台可以看到不同平台的安装包大小和下载包大小，查看路径是App Store Connect->TestFlight->Build活动->选择版本->文件大小。

2.3.2 安装包体积作为衡量标准

对于iOS端来说通常将安装包体积作为衡量标准，这是基于以下两个原因，第一、安装包和下载包大小正相关，安装包体积减小后，下载包体积自然也会减小；第二、AppStore官方页面给出的是每个APP的安装包大小，APP使用者可非常直观地获取这个信息，但是要想获取下载包大小，必须具有开发者权限，这显然不可能。

三、IOS端安装包组成部分

GEEK TALK

组成部分	说明
Mach-O文件	iOS系统上的可执行文件
Watch	APP中带有WatchApp
Widget组件	Widget通过在 iOS 主屏幕放置小组件，让用户可以随时访问 APP中的内容，Widget 可以保持更新，从而让用户获得最新信息，当需要更多细节时，点击Widget 会直接带到 APP中的适当位置
APP自定义动态库	APP中自定义的动态库， 动态库在应用编译打包的时候，仅把链接信息编译到应用二进制可执行文件中，将 framework 的加载推迟到运行时，因此，应用在提交评审时的代码段大小计算，是不会将动态库的代码段计算计算在内，从而能够节省出一大截代码段大小空间
swift系统库	swift系统库，低版本系统上无swift系统库，需iPA包中自带，12.2以上系统自带swift系统库
Assets资源	Assets.car文件，使用Assets.xcassets管理的图片资源会统一打包进入该文件
根目录下的图片资源	直接添加进工程的图片文件，如png、jpeg、svg、webp、AppIcon等图片资源
bundle资源	用bundle管理资源,里面可以是图片,也可以是其他的配置文件
其他配置文件	除Assets、bundle资源和根目录下的图片资源为外，其他配置文件，如plist、js、css、json、端智能模型文件等

四、国内外厂商APP体积分析

GEEK TALK

我们针对国内外主流APP的安装包做一个简单分析，重点统计了IPA包主要组成部分，如Mach-O文件、bundle图片资源和Assets图片资源，原始文件来源是22年9月份AppStore商店安装包，经过分析有如下结论：

• 从APP包体积来看，QQ和微信包体积最大(500M+)，处于第一梯队，百度和抖音居于第二梯队(380M+)，快手(320M)处于第三梯队，美团、淘宝和头条包体积是在250M左右 ，是国内大厂中体积最小的，国外的主流APP如Facebook和YouTube在280M左右，包体积控制的还是比较节制的。
• 国外的APP大量使用动态库，Facebook自定义动态库有53个，主mach-o体积只有8.3M，代码主要在动态库，国内自定义动态库基本6个左右，像美团和百度基本没有自定义动态库；
• Swift的使用是大势所趋，国外大厂在用，国内大厂除了美团没有Swift动态库(暂没发现)，其他厂都有，这与Apple的努力密不可分，2019年Apple发布了 Swift 5.0 版本，宣布了 ABI 稳定后，像手淘也拥抱了Swift;
• bundle和Asset使用对比，Asset是所有大厂APP主流，美团APP用bundle较广泛，bundle图片webP优化较多；
• 从图片的角度来比较，不论是bundle图片资源还是Assets图片资源，百度APP是其他APP的好几倍，冗余资源很多，这是我们的优化方向；
• SVG、iconfont的使用，国内大厂像QQ和淘宝，大量使用SVG矢量图和iconfont字体文件构建纯色图以此来降低图片体积，这也是百度APP需要推动优化的方向。

五、技术方案

GEEK TALK

5.1 资源优化

百度APP有30M的资源，这儿资源是指plist、js、css、json、端智能模型文件等，因这些文件的优化方式跟图片优化差异很大，所以把两者区分开来。内置的大块资源(单个文件大于80K)就有16M，所以具有很大的优化空间，资源优化分为三个部分，分别是大资源优化、无用配置文件和重复资源优化。

5.2 工程架构优化

其他优化手段解决的是存量问题，良好的防劣化机制解决的是增量问题，以避免包体积无序增长，百度APP结合Linkmap和Mach-O文件搭建了体积检测流水线，对每个版本每个库的包体积劣化问题做了挖掘，结合配额和卡口制度，控制体积增长在合理范围内。

此外，苹果公司为进一步提高开发者的生产效率，于22年10月份发布了Xcode14，新版本编译器具有全新的增强功能，更强大的并行编译能力，可明显提升项目构建速度，其中，XCode14的升级对包体积带来比较明显的优化，官方给出数据是应用程序下载包体积减小了 30%，百度APP实践过程中有26M的收益，体积减少了6.5%。

5.3 图片优化

解压IPA包后发现，asset和bundle里面图片有94M,这是我们重点优化的对象，百度APP采用如下方式对不同的图片资源进行了优化。

• 无用图片优化：基于开源工具二次开发，工具针对OC、swift、xib、html、js、css、json、plist文件扫描排查未引用的图片，然后针对如下字符串拼接的常见case二次过滤：暗黑模式(后缀_dark,_day,_night)、后缀是数字的图片序列(覆盖如下后缀_%d,_%ld,_%zd,_%lu)；
• Asset Catalog图片优化：之前在bundle需要放二倍图和三倍图，同一张图片最后在用户手机上会有两份，iOS7系统有了Asset Catalog后，Asset Catalog为不同类型设备(分辨率不同)或者相同类型设备但不同配置(磁盘不同)提供定制化资源下载，当用户下载App时，只有跟用户手机硬件设备参数相匹配的资源才会被下载，其他不会下载，从而降低下载包体积；
• HEIC图片优化：更改PNG和JPEG图片编码格式，选择HEIC方案，基于以下优点：1、体积最小，HEIC比PNG体积减少50%，WebP比PNG优化30%；2、解码效率高，跟WebP相比，HEIC硬解码效率高，略慢于JPEG；
• WebP压缩优化：根据前面的结论有HEIC格式图片后，图片优化工作就已经结束了，其实不然，HEIC是iOS12以后推出来一种新格式，百度APP经过这么多年开发积累了许多老图片，对于带有Alpha通道的并经过压缩的PNG图片，转换为HEIC格式后，在iOS12和13系统存在兼容性问题，Alpha通道全变为0，为此对于这种case，尤其是大图，我们采用WebP压缩优化；
• TinyPng压缩：WebP 在 CPU 消耗和解码时间上会比 PNG 高两倍，因为对于大于100KB的图片我们使用 WebP，对于小于 100KB 图片，使用TinyPng进行压缩，虽然压缩率没有 WebP 那么高，但是没有改变图片编码方式，所以不会增加解析性能损耗。

5.4 编译器优化

编译器是包体积优化方向中性价比最高的，LLVM给我们提供了大量的编译选项，对于OC、C、C++、Swift、资源压缩和符号表都有大量优化选择，百度APP采用的方案如下所示：

5.5 代码优化

代码优化相对而言ROI较低，因为影响范围较广，质量风险较高，优化过程中涉及到所有相关人员参与，无法集中处理。百度APP从无用类优化、无用方法瘦身、无用模块瘦身、精简重复代码、工具类瘦身、AB实验固化等方向做了深度优化。

六、各项优化收益

GEEK TALK

各项主题优化收益如下所示，对于有的优化已经收益落地了，其他的还需要排期，按收益从大到小排序，工程方向优化-》编译器方向-》图片优化-》资源文件优化-》代码瘦身。

七、总结

GEEK TALK

本文主要介绍了iOS包体积优化必要性、下载包和安装包两个指标的区别、安装包组成部分和生成过程、国内外大厂APP包体积分析，然后阐释了百度APP包体积优化的总体技术方案，最后介绍了百度APP具体实践的优化项及收益，后续我们会针对每个优化类型详细介绍其原理与实现，敬请期待。

 END

参考资料：

[1]、App Thinning详解：https://medium.com/bitmountn/app-thinning-reduces-ios-app-size-by-40-aa6d37e86771

[2]、App Thinning官方介绍：https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f

[3]、深入探索 iOS 包体积优化：https://juejin.cn/post/6844904169938092045

[4]、抖音品质建设 - iOS 安装包大小优化实践篇：https://maimai.cn/article/detail?fid=1579866761&efid=3TGrvi9WKC5IclfDM-DFIQ

[5]、正经分析iOS包大小优化：https://mp.weixin.qq.com/s/_Mvl0FGriKsvAyRheU2Z7w

[6]、XCode14介绍：https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes

推荐阅读：

一键三连，好运连连，bug不见👇