iOS开发小技巧

iOS 安装包瘦身 （上篇）

2018-09-18  本文已影响35人  yijian2595

本文来自网易云社区

作者：饶梦云

1. 安装包组成

谈到 App 瘦身，最直接的想法莫过于分析一个安装包内部结构，了解其每一部分的来源。解压一个 ipa 包，拿到其 payload 中 app 文件的数据，整理归类后其大致如下：

从以上结构中可以看出一个 ipa 包大致由 Executable, Resources, Framework,Plugins 四大模块组成，接下来我们就从这四个方向来探讨 App 瘦身的具体方案。

2. 可执行文件瘦身

可执行文件就是我们源代码(.m/.h/.swift ...)的编译结果。在 iOS 或者 macOS 中称之为 Mach-O executable，它是程序的入口。

2.1. 编译器优化

Xcode 支持编译器层面的一些优化优化选项，可以让我们介于更快的编译速度和更小的二进制大小并且更快的执行速度之间自由选择想要进行的优化粒度。

2.1.1. Clang/LLVM 编译器优化选项

我们都知道 Xcode 是使用 Clang 来编译 Objective-C 语言的，Clang 的优化选项在其文档 clang - Code Generation Options 中可以查阅得到。我们的 IDE-Xcode 只提供给我们 6 个等级的编译选项，在 Xcode -> Build Setting -> Apple LLVM 9.0 - Code Generation -> Optimization Level 中进行设置，每个等级的说明，可以参考官方文档：

xcode-clang-optimization

Fastest Smallest[-Os] 极小限度会影响到包大小，而且也保证了代码的执行效率，是最佳的发布选项，一般 Xcode 会在 Release 下默认选择 Fastest Smallest[-Os] 选项，较老的项目可能没有自动勾选。

XCode 中设置的选项最终会反应在 Clang 命令上面，打开 build log 可以看到此选项最终的表现形式：

clang/llvm-optimization-level-command

如果你还需要 clang 的其他选项来编译你的项目，可以在 Other C Flag 中直接添加其参数。举例来说，在 Optimization Level 中设置 Fastest Smallest[-Os] 和在 Other C Flags 中添加 -Os 效果是一样的。

2.1.2. Swift Complier/LLVM 编译优化选项

Swift 语言的编译器是 swiftlang，同时也是基于 LLVM 后端的。Xcode 9.3 版本之后 Swift 编译器会提供新的选项来帮助减少 Swift 可执行文件的大小：

xcode-swift-llvm-optimization

Xcode 9.3 以前和优化选项混杂在一起的编译模式可以独立设置了：

xcode-swift-compilation

在 Relese 模式下 -Osize 和 Whole Module 同时开启效果会发挥的最好，从现有的案例中可以看到它会减少 5%~30% 的可执行文件大小，并且对性能的影响也微乎其微（大约 5%）。参考官方文档 和 SwiftCafe。

此选项虽然是 Xcode 9.3 支持的，但是我们发现 Xcode 9.2 对应的 Swift Compiler 也是支持 Osize 的。所以 Xcode 9.2 版本中可以在 Build Settings -> Other Swift Flags 中添加 -Osize 提前获取编译器优化的好处。

xcode9.2-swiftc-Osize

虽然 Xcode 9.3/Swift4.1 已经发布，但是其编译器不是特别稳定，特别是开启 Osize 选项之后，编译器很多情况下会莫名其妙的崩溃(Segmentation fault)，我们在 bugs.swift.org 上面也找到了很多同类的崩溃。所以假如你使开启 Osize 之后遇到了同类的崩溃，你可以选择放弃 Osize，或者想办法修改代码绕开编译器崩溃。

2.2. 去除符号信息

可执行文件中的符号)是指程序中的所有的变量、类、函数、枚举、变量和地址映射关系，以及一些在调试的时候使用到的用于定位代码在源码中的位置的调试符号，符号和断点定位以及堆栈符号化有很重要的关系。

2.2.1. Strip Style

Strip Style 表示的是我们需要去除的符号的类型的选项，其分为三个选择项：

iOS 的调试符号是 DWARF 格式的，相关概念如下：

dwarf_dsym_executable

使用 Xcode 编译打包的时候会先通过可执行文件的 Debug Map 获取到所有对象文件的位置，然后使用 dsymutil 来将对象文件中的 DWARF 提取出来生成 dSYM 文件。

2.2.2. Strip Linked Product

If enabled, the linked product of the build will be stripped of symbols when performing deployment postprocessing.

并不是所有的符号都是必须的，比如 Debug Map，所以 Xcode 提供给我们 Strip Linked Product 来去除不需要的符号信息(Strip Style 中选择的选项相应的符号)，去除了符号信息之后我们就只能使用 dSYM 来进行符号化了，所以需要将 Debug Information Format 修改为 DWARF with dSYM file。

我之前一直疑惑没有 DWARF 调试信息之后 Xcode 是靠什么来生成 dSYM 的，答案其实还是 DWARF，因为 Xcode 编译实际的操作步骤是：生成带有 DWARF 调试信息的可执行文件 -> 提取可执行文件中的调试信息打包成 dSYM -> 去除符号化信息。去除符号是单独的步骤，使用的是 strip 命令。

另外一个问题是，去除符号化信息之后我们只能使用 dSYM 来进行符号化，那我们使用 Xcode 来进行调试的时候会不会太麻烦了？其实我们完全不用担心这个问题：Strip Linked Product 选项在 Deployment Postprocessing 设置为 YES 的时候才生效，而在 Archive 的时候 Xcode 总是会把 Deployment Postprocessing 设置为 YES 。所以我们可以打开 Strip Linked Product 并且把 Deployment Postprocessing 设置为 NO，而不用担心调试的时候会影响断点和符号化，同时打包的时候又会自动去除符号信息。这个选项也是默认打开的，较老的项目可以选择手动开启。

2.2.3. Strip Debug Symbols During Copy

Specifies whether binary files that are copied during the build, such as in a Copy Bundle Resources or Copy Files build phase, should be stripped of debugging symbols. It does not cause the linked product of a target to be stripped—use Strip Linked Product (STRIP_INSTALLED_PRODUCT) for that.

与 Strip Linked Product 类似，但是这个是将那些拷贝进项目包的三方库、资源或者 Extension 的  Debug Symbol 去除掉，同样也是使用的 strip 命令。这个选项没有前置条件，所以我们只需要在 Release 模式下开启，不然就不能对三方库进行断点调试和符号化了。

如果依赖的 Target 是独立签名的（比如 App Extension），strip 操作就会失效，并伴随着 Warning：warning: skipping copy phase strip, binary is code signed: xxxx。此情况将依赖的 Target 中的 Strip Linked Product 修改为 YES，保证依赖的 Target 是已经去除了符号即可，Waning 忽略掉就可以了。

Cocoapods 管理的动态库(use_framework!)的情况就相对要特殊一点，因为 Cocoapods 中的的动态库是使用自己实现的脚本 Pods-xxx-frameworks.sh 来实现拷贝的，所以并不会走 Xcode 的流程，当然也就不受 Strip Debug Symbols During Copy 的影响。当然 Cocoapods 是源码管理的，所以只需要将源码 Target 中的 Strip Linked Product 设置为 YES 即可。

2.2.4. Strip Swift Symbols

Adjust the level of symbol stripping specified by the STRIP_STYLE setting so that when the linked product of the build is stripped, all Swift symbols will be removed.

开启 Strip Swift Symbols 能帮助我们移除相应 Target 中的所有的 Swift 符号，这个选项也是默认打开的。

补充一点：Swift ABI 稳定之前，Swift 标准库是会打进目标文件的，想要同时移除 Swift 标准库里面的符号的话需要在发布选项中勾选 Strip Swift symbols，如下图所示：

distribution_strip_swift_symbols

2.3. BitCode

BitCode 是 iOS 9 引入的新特性，官方文档解释 BitCode 是一种程序中间码，其实就是 LLVM IR 的一种编码形式 - BitCodeFormart。

bitcode-architecture

上图表示了 IR 和 BitCode 在编译器架构中所在的位置，需要说明的是 BitCode 是以 section 形式保存在可执行文件中。当我们把携带 BitCode 的 App 提交到 AppStore 后，苹果会提取出可执行文件中的 BitCode 段，然后针对不同的 CPU 架构编译和链接成不同的可执行文件变体(Variant)，不同 CPU 架构的设备会自动选择合适的架构的变体进行下载。而在 BitCode 之前没我们都是把所有需要的 CPU 架构集合打包成一个 Fat Binary，结果就是用户最终下载的安装包之中有很多冗余的 CPU 架构支持代码。

从以上编译器架构中我们也可以得出一个结论：开启 BitCode 之后编译器后端(Backend)的工作都由 Apple 接管了。所以假如以后苹果推出了新的 CPU 架构或者以后 LLVM 推出了一系列优化，我们也不再需要为其发布新的安装包了。

2.3.1. BitCode 一致性要求

一致性要求意味着工程开启 BitCode 之后必须要求所有打进 Bundle 的 Binary 都需要支持 BitCode，也就是说我们依赖的静态库和动态库都是含有 BitCode 的，不然就会打包失败。对于 Cocoapods 等源码管理工具来管理的依赖库来说操作会比较简单，我们只需要开启 Pods 工程中的 BitCode 就行。但是对于一些三方的闭源库，我们就无能为力了。

2.3.2. BitCode 的崩溃定位

开启 BitCode 之后需要特别注意崩溃定位的问题：由于最终的可执行文件是 Apple 自动生成的，同时产生新的符号表文件，所以我们使用原本打包生成的 dSYM 符号化文件是无法完成符号化的。所以我们需要在上传至 App Store 时需要勾选 Include app symbols for your application to receive symboilcated crash logs from Apple：

Include app symbols

勾选之后 Apple 会给我们生成 dSYM，然后就可以在 Xcode -> Organizer 或者 iTunes Connect 中下载对应的 dSYM 来进行符号化了。

2.3.3. BitCode 的编译选项优化

上面所说的编译器优化是在编译器前端完成的，所以提交的 BitCode 应该是经过优化的。但是 去除符号信息，是在编译生成可执行文件之后完成的， 苹果在生成可执行文件之后是否给我们去除了符号也不得而知。

本文来自网易云社区，经作者饶梦云授权发布

网易云免费体验馆，0成本体验20+款云产品！

更多网易研发、产品、运营经验分享请访问网易云社区。

相关文章：
【推荐】 ARKit入门

上一篇下一篇

猜你喜欢

热点阅读