21614418141_.pic.jpg
而作为开发者的我们，在App 的某个版本上线之前，可以通过苹果的 App Store Connect后台查看安装包大小的功能：
选择APP -> 打开 “TestFlight” -> 点击构建的版本 -> 点击顶部的”构建版本元数据” -> 在”综合信息“下点击”App Store 文件大小“，会展示出不同变体版本的大小，如下图所示：
image.png
在上图中可以清楚的看到不同变体版本的大小，而且区分了安装大小和下载大小：
-
安装大小：
是指App 在设备上安装后占用磁盘空间的大小，用户在 App Store中用户看到的大小就是安装大小 -
下载大小：
是指对 App 进行下载的压缩大小
2. .app文件&.ipa文件
我们在发布应用时，最后提交的是一个 .ipa 文件，其实它就是一个 zip 压缩包，我们可以使用unzip命令，直接解压就可以得到一个.app文件，这个.app文件其实就是个文件夹，里面包含了二进制文件和资源文件等等：
demo@MacBook-Pro ~ % file MonkeyDemo.app
MonkeyDemo.app: directory
所以.ipa文件和.app文件的关系：.ipa文件其实就是.app文件压缩后的产物。
可以说明用户下载的是.ipa文件，下载完成之后解压为.app文件，下载大小是.ipa文件的大小，导入大小是.ipa解压后得到.app文件的大小。
但是我们通过某种方式从 AppStore 下载的.ipa解压后得到的.app文件的大小和我们直接导出的.ipa解压后得到的.app文件大小是有区别的，这个区别其实是苹果会对已经通过审核的 App进行DRM 加密并重新压缩，这个会影响到二进制文件的压缩，所以 AppStore 显示的二进制文件大小可能会比上传到 App Store Connect的二进制文件更大，如下图：
截屏2021-02-27 下午8.07.48.png
另一方面，苹果在 iOS 9 推出了App Thining，会影响我们导出 ipa 的大小，我们先来了解一下。
3. App Thinning
具体的可以参考：App Thinning官方文档，这里简单了解一下。
App Thinning可以翻译成应用瘦身，指的是App Store和操作系统在安装 app 的时候，会通过一系列的优化，减少安装包的大小，而这一系列的优化，包括了三个过程：slicing、bitcode 和 on-demand resources。
3.1 slicing
这一步其实就是应用裁减，针对于不同的设备，它们可能需要ipa 中的不同的独立资源，所以 App Store会针对不同的设备制作不同的”简化版”的 ipa，也就是常说的”变体”，这个简化版的 ipa 值包含目标设备和操作系统版本所需的可执行架构和资源。
比如我们的图片资源大都放在 Assets.xcassets中，其中包含 @1x @2x @3x 的图片，但是我们 iPhone 5S手机只需要@2x 的图片，这一步做的就是帮我们去除 @1x @3x的图片，也就是说，当用户下载 App 的时候，苹果会根据当前机型生成一套最适合这个机型的一套图片，这样就节省了大量的不必要的图片资源，节省出来很大一部分空间。
还有就是我们导出的ipa 中的可执行文件，一般是含有多个 CPU 架构的：armv7和arm64 ，现在的iPhone一般都是需要 arm64 的，在这一步中苹果就会把armv7 架构干掉。
从这一点来看在
VALID ARCHS中干掉armv7架构，对于包大小的优化来说没啥用了，苹果已经帮开发者做了这一步了。
image.png
从苹果介绍App Slicing时的这张图中也可以看出来。
3.2 BitCode
Bitcode是一个编译好的程序的中间表示形式，开启BitCode，也就是说当未来有新的iPhone使用了新的 CPU 架构时，允许苹果可以重新优化可执行文件，对可执行文件重新编译和链接，不用我们重新提交 App了。
image.png
3.3 On-Demand Resources (iOS)
ODR（on-demand resources 随需应变资源)是iOS减少应用资源消耗的另外一种方法。比如多级游戏，用户需要的通常都是他们当前的级数以及下一级的资源。ODR意味着用户可以下载他们需要的几级游戏资源。随着你的级数不断增加，应用再下载其他级数的资源，并将用户成功过关的级数删掉。
4. 自己导出的 ipa 和从 AppStore 下载的 ipa 对比
4.1 自己导出的 ipa 验证
我们自己导出的 AppStore 正式包是没有经过 App Slicing 的，比如可执行文件中含有多个CPU 架构，可以使用file命令查看，如下：
2021-02-28 09-54-58 % file TestApp
TestApp: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O executable arm_v7] [arm64]
TestApp (for architecture armv7): Mach-O executable arm_v7
TestApp (for architecture arm64): Mach-O 64-bit executable arm64
使用otool 命令验证是否加壳：
otool -l 可执行文件路径 | grep crypt
2021-02-28 09-54-58 % otool -l TestApp | grep crypt
cryptoff 16384
cryptsize 901120
cryptid 0
cryptoff 16384
cryptsize 999424
cryptid 0
可以看到cryptid值为0，说明两种架构下都没有加壳。
在导出Ad Hoc类型的ipa 时，是可以选择导出指定设备所需要的包的，这需要我们在导出时修改配置，导出iPhone 7 Plus的包，如下：
image.png
导出之后会包含一个 Apps 文件夹，里边有多个 ipa:
image.png
可以通过App Thinning Size Report.txt文件，查看Apps 文件夹中不同 ipa 的信息：
image.png
这里为什么有多个，我也不清楚，但是在上面文件中可以看到不同的ipa分别有自己支持安装的设备（Supported variant descriptors）。
我们解压一个ipa ，再次用file 命令查看，可执行文件只包含一个 arm64架构了。
5. 总结
通过上面的验证，我们可以知道用户在App Store上看到的包的大小，其实就是.app文件的二进制部分加壳之后，再经过 app slicing的大小。
了解这个有助于我们对于ipa大小优化的操作进行数值化，验证我们的操作是否有用。
