iOS包体积优化实践

❝

用最通俗的语言，描述最难懂的技术

前情描述

最近领导给我分配了包体积监控指标，恰好之前我也做过相关包体积的优化，于是便综合之前的实践经验，对此我们的项目的包体积优化做一个整体的记录，希望可以帮助有需要的小伙伴

iOS(安装)包

ipa全称为iPhone Application Archive，这里指的包在iOS其实就是安装包，直观展示就是xxx.ipa文件

iOS包内容

想要对其优化，就要知道包里面都有什么，知道了有什么，针对不同类型的文件，做不同的处理，从而达到一定的优化

我们首先找到一个xxx.ipa文件，然后把后缀改为xxx.zip，然后进行解压缩操作，如下图所示

然后右键选中显示包内容，里面就是安装包包含的所有资源，大概可以分为以下几类

• _CodeSignature文件夹：ipa包签名文件的存放文件夹
• Assets.car：Assets.xcassts在编译过程中生成的最终展示文件，默认里面存放各种分辨率图片（测试项目未使用）
• embedded.mobileprovision：证书配置文件
• Info.plist：项目配置表
• Plugins：App创建的扩展，比如Widget、Push和Share等
• .Iproj：App所支持的语言文件
• exec文件：可执行文件，例如widgetExtension
• 图片资源：.png，.jpg，.webp，.gif
• 其它资源文件
• .xml，.json
• .plist：项目中使用资源的.plist文件
• .bundle：Mac OS下的资源包集合
• .conf：相关的配置文件
• .cer，.der，.p12：钥匙串文件
• .wav：音频文件
• .js，.html
• .nib：Xcode自带的数据文件，包含一个窗口程序和应用程序委托对象
• .sqlite：数据库文件
• .txt：文本文件
• .mom：Xcode创建的数据模型文件

这次测试之前IPA未解压的大小是76.5MB，解压之后的大小是140.1MB

解压后各个部分大小的明细如下

优化策略

上述了解完了IPA各个组成之后，我们按照Xcode编译优化，资源文件优化以及代码优化的顺序来一步一步进行分析

Xcode编译优化

这个部分是最容易的，也是最容易忽略的，下面是笔者进行的总结，我们一个一个分析

编译指令集

首先查看我们目前的架构组成

augus@MacBookPro xxx.app % lipo -info xxx
Architectures in the fat file: sohunews are: armv7 arm64

我们再看下各个架构指令集对应的机型

# armv6: iPhone, iPhone 3G, iPod 1G/2G  
# armv7: iPhone 3GS, iPhone 4, iPhone 4S, iPod 3G/4G/5G, iPad, iPad 2, iPad 3, iPad Mini  
# armv7s: iPhone 5, iPhone 5c, iPad 4  
# arm64: iPhone X，iPhone 8(Plus)，iPhone 7(Plus)，iPhone 6(Plus)，iPhone 6s(Plus), iPhone 5s, iPad Air(2), Retina iPad Mini(2,3)  
# arm64e: XS/XS Max/XR/ iPhone 11, iPhone 11 pro,iPhone 11 Pro Max,iPhone SE (2nd generation),iPhone 12 mini,iPhone 12,iPhone 12 Pro,iPhone 12 Pro Max,Phone 13 mini,Phone 13,iPhone 13 Pro,iPhone 13 Pro Max
# x86_64: 模拟器64位处理器
# i386: 模拟器32位处理器

此次测试中我们是不需要32位架构armv7的，所以我们可以设置在打包的时候进行只打armv64即可。

方法1：Build Settings-Architectures，把你需要的打包标识符下的设置为arm64；Architectures指定工程可以编译出多个指令集的代码包，ipa就会变大；

方法2：Build Settings-Excluded Arcitectures，在你要的打包标识符下面增加两个配置项目Any iOS SDK和Any iOS Simulator SDK，然后分别设置为armv7和arm64；这个选项的意思是Release模式下针对真机armv7指令集排除，针对模拟器把arm64排除。

这个优化之后，ipa压缩包大小为51.4MB，解压缩包大小变为90.9MB，其中exec变为56.6MB，效果很明显

代码优化

Build Settings-Optimization Level在发布模式设置为[-Oz]，其他模式根据场景进行选择，具体参考官方文档(https://help.apple.com/xcode/mac/11.4/#/itcaec37c2a6)进行设置；这个设置指的是生成的代码在速度和二进制大小方面的优化程度

Optimization Level默认是-Os，-Oz是Xcode 11新增的编译优化选项，该设置通过将重复的代码模式隔离到编译器生成的函数中来实现额外的尺寸节省

以下是不同的选项对应的编译速度和二进制文件大小变化趋势，来源于WWDC2019 Session 409 https://developer.apple.com/videos/play/wwdc2019/409/

优化完成之后ipa大小是51MB，解压缩包大小是87.9MB

资源目录优化

Build Settings-Asset Catalog Compiler Options-Optimization设置为space；这个选项可以改变actool在构建Assets.car时选取的编码压缩算法，减少包大小。

使用以下命令检查Assets.car中图片的编码压缩算法

# 可以把对应信息生成.json文件，用于对比不同
xcrun --sdk iphoneos assetutil --info Assets.car > Assets.json

项目之前用的是默认配置，由于Assets.car存放了少量资源，大部分都是存放在项目的根目录；

优化之后的ipa包大小是51.3MB，解压缩包大小是90.8MB，Assets.car大小是469KB

调试符号

Build Settings-Generate Debug Symbols设置为NO；这个选项的意思是是否在源文件编程成.o文件时，添加编译参数-g和-gmodule，就是generate complete debug info，所以产生的.o会变大，从而最终的可执行文件也就会变大。

需要注意的是，如果设置为NO，在Xcode中设置断点不会中断，不能进行断点调试。且最后不能生成dSYM文件，即使Debug Infomation Format设置了，也无法生成，因为生成的前提是得有调试信息，建议不要设置。

无用符号

Build Settings-Deployment Postprocessing，调试模式下NO，发布模式下YES

Deployment Postprocessing是Strip的总开关。也就是说，只有Deployment Postprocessing这里设置了YES，Strip Debug Symbols During Copy和Strip Linked Product设置为YES才会生效，其余情况均不生效

• Strip Linked Product：对最终的二进制文件是否进行去除无用符号
• Strip Debug Symbols During Copy：文件拷贝编译阶段是否进行strip，设置为YES之后，会把拷贝进项目的第三方库、资源或者Extension的调试符号剥离

这个优化之后，ipa压缩包大小为51.4MB，解压缩包大小变为90.9MB，其中exec变为56.6MB，之前已经开启，所以无变化

第三个关于符号的优化是Build Settings-Symbols Hidden by Default，调试模式下为NO，发布模式下为YES。该选项的意思是当启用时，所有的符号多被声明为私有的extern，除非在代码中使用attribute((visibility("default")))明确标记为导出；反之，则所有符号都会被导出。

该测试项目中已开启，包大小无变化

复用字符串

Build Settings-Make Strings Read-Only设置为YES；就是复用字符串字面。

该测试项目中已开启，包大小无变化

无效代码

Build Settings-Dead Code Stripping设置为YES；是否消除无用代码

该测试项目中已开启，包大小无变化

异常捕获机制

Build Settings-搜索exceptions

如果想要对项目瘦身，需要对途中的绿色未知设置为NO

Enable C++ Exceptions和Enable Objective-C Exceptions是指项目对错误的异常处理，比如try catch， throw之类的语句；所以如果你的项目中有类似的处理，关闭这个之后会报错Cannot use '@try' with Objective-C exceptions disabled。如果宏定义有try，关闭之后也会报错

如果你的项目中可以设置关闭捕获异常的开关，还需要另外设置Build Settings-Other Link Flags去添加一个字段

-fno-exceptions代表禁用异常机制，参考这里：

http://gcc.gnu.org/onlinedocs/gcc-4.7.0/libstdc++/manual/manual/using_exceptions.html

现在来总结下编译优化

资源文件优化

资源文件的优化就相对比较简单，但是比较繁琐；与上面的Xcode编译配置不同，一次设置永久有效，资源的优化需要平时开发就需要关注，比如新资源的压缩，无用资源的删除等。

资源文件优化大体分为两个方向，第一个就是无用资源的删除，第二个就是已用资源的压缩。这里建议分先后顺序，就是先做删除，后做压缩，因为如果反过来，就会做一些无用功。

无用资源的删除

• 已定义未使用的代码文件
• 已废弃的业务，代码还在
• 已引用的图片但未使用
• 某些重复资源的导入

已用资源的优化

• 项目中引入的图片、网页、音频等文件的压缩

无用资源的删除

随着项目的迭代，每个项目都会或多或少存在冗余。可能是已经下线的业务，但是没人通知开发，于是代码逻辑一直存在；可能是删除某业务代码的时候，对应的图片资源为删除；又或者是多个开发导入了相同功能的第三方库。

对于这部分的优化分为预防和治理

关于预防

个人认为首先要有规范的流程，按流程执行，减少信息不对等的情况出现

产品和开发，广告和开发，都会导致相关业务的冗余，产品知道具体的业务数据，而开发不知道，所以通过某个固定时间的一次集中同步，让开发可以了解到自己的业务是否活跃，从而对项目进行相应的调整。

开发与开发之间的消息不对等，会导致各自开发自己的轮子，重复造轮子，所以可以通过建立公共文档、开发流程规范、项目使用第三方库规范、设计规范、代码规范都一一列举出来，每个人都能根据对应的文档了解到对应项目的信息，每个人开发都应该有一套统一的标准，这样就很大程度上避免了一人一套代码问题的出现。

具体规范流程可以根据自己公司或自己部分的实际情况来，多问为什么，比如这样

• 为什么会有类似的情况出现？
• 出现之后是否有处理？
• 怎么才能避免类似的事再次出现？

关于治理

已定义未使用的代码

如果你的项目代码在百万级以下，推荐你使用AppCode来静态检查无用代码，如果超过了百万的团队，一般会自己通过Clang静态分析来开发工具，去检查无用的代码和类

使用AppCode做分析很简单，直接使用AppCode打开你需要检查的工程，等待索引建立完成，点击顶部菜单的Code-Inspect Code

然后选择扫描范围，默认是整个工程，可以自定义

然后等待静态分析完成即可，完成之后就会控制台显示Unused code的提示

下面说下无用代码的类型

虽然AppCode完成了大部分的工作，但是还是有一些问题存在，下面是我测试总结的问题

• JSONModel定义了未使用协议会被判定为无用协议
• 如果子类使用了父类的方法，父类的这个方法会判断为未使用
• 通过点语法使用属性，该属性会被认为未使用
• 使用performSelector方式调用的方法检查不出来，比如[self performSelector:@selector(fetchPhotos:)]，会认为fetchPhotos:是未使用
• 运行时声明的类也检查不出来，比如通过NSClassFromString方式调用的类会被查出未使用

id someClass = NSClassFromString(@"SomeClass");
// or
[[self class] getPhotos];

基于上述的原因，我们需要人工二次确认才能够安全删除代码，虽然繁琐，但是很安全。

已废弃业务，代码还在

定期对业务流程进行梳理，结合综合业务数据的埋点，同产品和广告确认功能是否已经下线，从而决定是否移除对应的业务模块

已引入未使用的图片

这里我测试使用的是LSUnusedResources(https://github.com/tinymind/LSUnusedResources)，针对使用编号规则的图片来说，可以直接添加规则来处理，使用也很简单；建议在删除前在项目中进行二次全局搜索确认，是否确实没有使用

某些重复资源的导入

重复资源分为静态库和项目文件

针对静态库，有多个相似功能进行需求整合，把最优解决方案的静态库留下，其余的跟相关产品和广告人员进行移除确认，比如线上崩溃采集听云、bugly和matrix等

针对项目文件，可以使用fdupes工具进行重复文件扫描，该工具的原理是通过校验所有的资源的MD5值，筛选出项目中重复的资源，文件比较顺序是

• 文件大小 > 部分MD5签名对比 > 完整MD5签名对比 > 逐字节对比

fdupes的安装和使用

# Searches the given path for duplicate files. Such files are found by
# comparing file sizes and MD5 signatures, followed by a byte-by-byte comparison.

# install fdupes
$ brew install fdupes

# where xxx is the directory to be scanned, and xxxFdupesResult.txt is the output file of the scan result
$ fdupes -Sr /User/augus/Documents/xxx > /User/augus/Documents/xxxFdupesResult.txt

已用资源的优化

已用资源的优化主要是就是图片、网页、json、音频文件的压缩

网页的压缩，是放入App资源中的js或者html文件，最好是经过 H5端压缩后的

json文件的压缩，如果不是即时使用的，可以放倒云端或者后台，进行网络获取后使用

音频的压缩，需要跟产品和广告进行沟通，在可接受范围内，选择系统可支持的压缩比最高的格式

最后说图片的压缩，分为以下几个部分

• 如果图片小于100KB则使用TinyPng进行再一步压缩，使用TinyPng压缩三次即可达到极限值；这里推荐一个TinyPng的多图压缩的脚本(https://github.com/mokong/BatchProcessImage)，因为在线最多一次最多20张，原理就是封装了官方的一个压缩接口，通过一个邮箱注册一个key，然后每个key就是500次/月。

• 将图片放入xcassets，因为xcassets里的@2x和@3x图片，在上传时，会根据具体设备分开对应分辨率的图片，不会同时包含。而放入.bundle中的都会包含，所以要尽量把图片放入xcassets中。Assets.car编译过程中有时会选择一些图片，拼凑成一张大图来提高图片的加载效率。被放进这张大图的小图会变为通过偏移量的引用，建议使用频率高且小的图片放到xcassets中，xcassets能保证加载和渲染速度最优。

• 大于100KB就不要放入xcassets中了。大的图片可以考虑将图片转成WebP。WebP是Google公司的一个开源项目，能够把图片压缩到很小，但是肉眼看不出来差别，目前iOS常用的图片显示类库都支持该格式解析的拓展。可使用鹅厂的一个工具iSparta(http://isparta.github.io/)进行批量转换。

WebP在CPU消耗和解码时间上会比PNG高2倍，所以我们要在性能和体积上做取舍

监控机制

优化完成之后，如何保证包大小不会再次迅速增大？或者如何迅速定位增大原因，就需要依赖一套合适的监控机制和合理的流程规范来保证。

监控机制保证实时发现问题，每次打包完成后，运行脚本比较包大小差异，如果有增大超过了设置的阈值，则邮件通知相关负责人，负责人排查原因，同时做好记录；每次打包的包大小进行文档记录，造成包大小变化的原因记录

流程规范是用于保证每个项目开发者在开发中有良好的开发习惯，避免包大小突然增大，而一无所知

• 引入新的第三方库，要考虑项目中是否有相同类型的，是否可以自己实现，是否会造成体积增大
• 新增图片资源，关注大小，是否能用代码实现，进行适当压缩
• 及时清理废弃模块
• 每次打包关注包大小变化，文档记录，持续跟踪

结束语

包大小不是一时可以完成，需要平时每个相关人都去注意，有了良好的开发规范，开发流程就能持续进行改进，从而达到一个平衡稳定状态。

参考文档

• Build Setting Reference https://help.apple.com/xcode/mac/11.4/#/itcaec37c2a6
• 包体积大小：瘦身 https://www.zybuluo.com/qidiandasheng/note/1662385)
• 抖音品质建设 - iOS 安装包大小优化实践篇 https://blog.csdn.net/ByteDanceTech/article/details/112504772