ipa包大小优化

这里记录下个人根据相关文档(基本参照今日头条分享的文章，链接在底部)对开发的某个app进行包大小优化的实践过程，这里暂且对某个app名字叫做ZZApp

app在App Store展示的大小(设备iPhone 8 Plus)为16.7M
App Store这里显示的大小其实为安装大小，而下载大小用户是看不到的，开发者可在Connect后台查看，包的大小会影响用户下载安装的意愿，开发者在开发中需要关注控制包大小的情况

app在iPhone 8 Plus上显示大小

在Connect查看不同设备的下载或安装包大小

Connect展示的部分设备下载与安装包大小.gif

首先我们应该对下图很熟悉

方式选择

个人分别选择App Store Connect、Ad Hoc、Development方式导出得出ipa包大小如下:

App Store Connect Ad Hoc Development

对App Store Connect方式导出的ipa进行查看:

1. 将xxx.ipa格式修改为zip
2. 将上述得到的zip文件进行解压
3. 解压后打开Payload文件夹，可看到一个与ipa名字一致的app文件(后缀默认隐藏)
4. app文件，右键 -> 显示包内容

5. 包内容中按照大小排序

   
   包内容排序

可以看到，app的大小主要是Assets.car和可执行文件占比较大，通过相关文章可以知道一个安装包，往往包含资源和可执行文件两部分，资源又可以分为 Asset Catalog 的构建产物 Assets.car 文件和其他资源，其中 Assets.car 文件和可执行文件，是需要投入较多精力优化的部分。

有趣的是，Assets.car大小为10.3M而在Xcode中查看Assets.xcassets才5M，通过工具将Assets.car将图标资源导出，对比了下图标资源与Xcode看到的Assets.xcassets是一致的，不清楚apple做了什么Assets.car反而更大了。

---

1. 资源大小优化

1.1 使用合适的资源压缩配置

1、ZZApp使用CocoaPods方式管理第三方库，最低支持版本为iOS10，并且主工程也设置最低版本为iOS10。
2、开启主工程 Xcode Build Settings 中的 ASSETCATALOG_COMPILER_OPTIMIZATION space 选项

Optimization-space

这两项设置可以改变 actool 构建 Assets.car 时选取的编码压缩算法，减小包大小。

然后通过App Store Connect方式打包

开启space后通过App Store Conncet方式打包大小

可以看到仅仅是做了上述步骤，就获得了18 - 17.5 = 0.4M的包大小收益

1.2 使用 RGB with palette 压缩图片

使用ImageOptim工具改变图片的编码方式为 RGB with palette

你可以拖动图标到空白区域内或者选择需要压缩的图标，我这里直接放了近200个图标，等待了近10分钟才全部压缩完毕

ImageOptim ImageOptim压缩完毕

ImageOptim执行完毕底部有标示出节省了2.2MB(总计4.9M)。总体44.8% (每个文件最多70.4%)

运行ZZApp，通过对比，个人认为做到了压缩大小的同时视觉上几乎无差别

我兴致勃勃的再次通过App Store Connect方式打出来ipa包，结果如下

无损压缩

也就是工具明明显示节省了2.2M 但是打出的包，完全没反映出来想要的结果。。。

然后，查看了下文章和ImageOptim设置，发现ImageOptim默认的设置是无损压缩，然后文章中有这么个解释"Xcode 中，构建 Asset Catalog 的工具 actool 会首先对 Asset Catalog 中的 png 图片进行解码，得到 Bitmap 数据，然后再运用 actool 的编码压缩算法进行编码压缩处理。无损压缩通过变换图片的编码压缩算法减少大小，但是不会改变 Bitmap 数据。对于 actool 来说，它接收的输入没有改变，所以无损压缩无法优化 Assets.car 的大小"

尴尬，改变下ImageOptim的设置，为了保持操作的可对比性，我将之前的压缩图标操作全部撤回，然后重新来一遍

ImageOptim设置 ImageOptim有损压缩结果

压缩完毕后，运行app经过对比后，视觉上几乎无差别
再次App Store Connect方式打包

有损压缩

获得了17.6 - 13 = 4.6M 的包大小收益，这个还是很客观的

2. Mach-O 文件优化
   2.1 使用 -Oz 编译参数

Oz 是 Xcode 11 新增的编译优化选项。WWDC 2019 《What's New in Clang and LLVM》中对 Oz 有过介绍。Oz 的核心原理是对重复的连续机器指令外联成函数进行复用，和“内联函数”的原理正好相反。因此，开启 Oz，能减小二进制的大小，但同时理论上会带来执行效率的额外消耗。对性能（CPU）敏感的代码使用需要评估。

在《What's New in Clang and LLVM》时间拉到10:30左右 你可以看到这样的画面

image.png

• -O3 -O2 可以让代码的执行时间变少，但结果就是代码大小增加，典型的空间换时间。
• -Oz -Os 则是牺牲时间，减少了代码大小

对于 Xcode 来说默认的优化等级是 -Os

你可以按照该路径Xcode -> Build Settings -> Apple Clang -> Code Generation -> Optimization Level设置

Optimization Level

但是像视频中所讲，-Oz对性能敏感的代码使用需要谨慎

也可以做更细颗粒度的设置
Build Phases -> Compile Sources -> Compiler Flags针对不同的文件进行设置

image.png

部分类-Oz编译，App Store Connect方式打包 获得了13 - 12.9 = 0.1M 的包带下收益

-Oz编译

2.2 使用链接时优化 LTO

Link-Time Optimization 链接时优化，是 Xcode 自带的一个编译/链接参数。根据 WWDC 2016 《What's New in LLVM》的介绍，LTO 对包大小和运行效率都有正向影响

image.png

这个优化对ZZApp没有什么包大小的收益-_-

image.png

其他的方式，个人这里暂时不做实践了。

---

参考

今日头条 iOS 安装包大小优化 - 新阶段，新实践