接上篇：iOS 安装包瘦身 （上篇）
2.4. 清理无用代码
2.4.1. Dead Code Stripping
Activating this setting causes the -dead_strip flag to be passed to ld(1) via cc(1) to turn on dead code stripping. Remove functions and data that are unreachable by the entry point or exported symbols
Xcode 默认会开启此选项，C/C++/Swift 等静态语言编译器会在 link 的时候移除未使用的代码，但是对于 Objective-C 等动态语言是无效的。因为 Objective-C 是建立在运行时上面的，底层暴露给编译器的都是 Runtime 源码编译结果，所有的部分应该都是会被判别为有效代码。
2.4.2. 通过扫描查找无用代码
扫描无用代码的基本思路都是查找已经使用的方法/类和所有的类/方法，然后从所有的类/方法当中剔除已经使用的方法/类剩下的基本都是无用的类/方法，但是由于 Objective-C 是动态语言，可以使用字符串来调用类和方法，所以检查结果一般都不是特别准确，需要二次确认。目前市面上的扫描的思路大致可以分为 3 种：基于 Clang 扫描；基于可执行文件扫描；基于源码扫描。
2.4.2.1. 基于 clang 扫描
基本思路是基于 clang AST。追溯到函数的调用层级，记录所有定义的方法/类和所有调用的方法/类，再取差集。具体原理参考 如何使用 Clang Plugin 找到项目中的无用代码，目前只有思路没有现成的工具。
2.4.2.2. 基于可执行文件扫描
Mach-O 文件中的 (__DATA,__objc_classlist) 段表示所有定义的类， (__DATA.__objc_classrefs) 段表示所有引用的类(继承关系是在 __DATA.__objc_superrefs 中)；使用的方法和引用的方法也是类似原理。因此我们使用 otool 等命令逆向可执行文件中引用到的类/方法和所有定义的类/方法，然后计算差集。具体参考iOS微信安装包瘦身，目前只有思路没有现成的工具。
2.4.2.3. 基于源码扫描
一般都是对源码文件进行字符串匹配。例如将 A *a、[A xxx]、NSStringFromClass("A")、objc_getClass("A") 等归类为使用的类，@interface A : B 归类为定义的类，然后计算差集。
基于源码扫描 有个已经实现的工具 - ，但是它的实现原理是查找所有 #import "A" 和所有的文件进行比对，所以结果相对于上面的思路来说可能更不准确。
2.4.2.4. 通过 AppCode 查找无用代码
AppCode 提供了 Inspect Code 来诊断代码，其中含有查找无用代码的功能。
它可以帮助我们查找出 AppCode 中无用的类、无用的方法甚至是无用的 import ，但是无法扫描通过字符串拼接方式来创建的类和调用的方法，所以说还是上面所说的 基于源码扫描 更加准确和安全。
通过扫描的方式去检查无用代码有个痛点就是 类的方法调用是一种引用关系，以上所说的四种思路都是查找到引用末端的未使用的代码，我们很难通过一次扫描就定位到所有未使用的类，自动化实现起来也较难。举个例子来说，假如 A 是一个未使用到的类，但是 A 引用了 B，所以首次检查结果是 A 未被引用，B 被无用类 A 引用了，我们需要把 A 删除了之后我们才能了解到 B 是否是无用的类。当然如果你重新去实现一个引用树的话就另当别论了。
由于扫描无用类实现起来较为麻烦，并且其检查结果也不是特别准确。所以建议还是让开发者养成一个良好的习惯，在迭代或者重构代码的时候把老的代码删除，不要等到量变引起质变的时候才回头去优化。
2.5. 重构重复代码
重复代码堆积太多，不仅意味着 Bad Code Smell，我们的包大小也会受到影响，我们可以使用 PMD 来检查项目中的重复代码，并且做选择性的重构。
2.6. 补充：Cocoapods 中的优化选项配置
Cocoapods 的 project 文件在每次 pod install 或者 pod update 会重置，所以需要 hook pod install 来设置 Pods 中每个 Target 的编译选项：
3.资源瘦身
本文中的资源分为图片资源、音频资源、视频资源、视图资源、字体资源、网页资源等等。资源都是弱类型的，会随着项目工程的增长而持续增长，维护起来费时费力，所以一般都是希望能有工具化、自动化的解决方案。
3.1. 图片资源瘦身
3.1.1. Xcode 支持
3.1.1.1. Compress PNG Files
Xcode 提供的给我们两个编译选项来帮助压缩 PNG 资源：
Compress PNG Files：打包的时候自动对图片进行无损压缩，使用的工具为 pngcrush，压缩比还是相当高的，比较流行的压缩软件 ImageOptim 也是使用 pngcrush 进行压缩 PNG 的。
Remove Text Medadata From PNG Files：能帮助我们移除 PNG 资源的文本字符，比如图像名称、作者、版权、创作时间、注释等信息。
项目引进的 PNG 资源都是自动被 Xcode 进行压缩了，所以完全不需要自己再去用工具压缩一遍。当除非你是使用 bundle 管理的资源，因为 bundle 是直接拷贝进项目，并不会被 Xcode 进行压缩；JPG 或者其他类型的图片资源可以使用 ImageOptim进行无损压缩然后导入到 Xcode 中，为了提高效率建议还是提供 PNG 格式的图片。
3.1.1.2. App Thinning/XCAssets
iOS 9 中引入的 App Thinning 中提到过 Slicing 的技术，当我们把一个完整的安装包提交给 App Store 后，App Store 会为不同的设备准备不同的变体（Variant），设备的在下载 App 的时候它能帮助我们自动选择合适的 Variant 进行下载。
可执行文件的 Slicing 技术就是上面所说的 BitCode，同样资源文件也是支持 Slicing 的。比如 iPhone 6 下载的安装包中就只会包含 2x 图，iPhone 6 Plus 下载的安装包就只会包含 3x 图，但是只有使用 asset catelogs(也就是 XCAssets) 管理的资源才支持 Slicing，所以尽量还是使用 XCAsset 来管理资源图片。同时 XCAsset 也支持 PDFs 矢量图，在上传到 App Store 之后，会根据矢量图自动生成 1x, 2x, 3x 图，然后进行 Slicing。
当然 XCAsset 也有它的存在的问题：
（1）使用 XCAsset 管理的资源会被压缩并打包成一个 Asset.car 文件，我们无法获取相应图片的物理路径，因此我们无法使用 [UIImage imageWithContentsOfFile:] 的方式来获取图片。对于那些需要使用物理路径的方式来访问的图片，建议还是直接拖拽到 App 中进行管理。
（2）iOS 10.3 推出的更换 App Icon 的资源文件只能放在 App 根目录下进行管理。
（3）使用 XCAsset 管理图片后，Xib/Storyboard 中设置的带后缀 .png 图片在 Interface Builder 是不可见的，都是显示的问号，但是运行起来是没有问题的。最好的做法是全局搜索并去掉后缀保证更好的开发体验。
3.1.2. 去除冗余图片资源
3.1.2.1. 去除无用资源
未使用的资源可以使用脚本来进行删除。强烈推荐使用 FengNiao 来自动删除图片，因为其相对比较新，是 2017 年开始开发的，并且是使用 swift 语言开发的，方便进行二次开发。FengNiao 的基本原理是查找出项目中所有使用到的字符串和项目中所有的资源文件。两者进行匹配（完全匹配和模式匹配，模式匹配支持带数字资源的前缀/中缀/后缀匹配），计算差集就为未使用的资源。
相比于之前流行的 LSUnusedResources，FengNiao 支持模式匹配会更加强大：比如我们导入 image_01 image_02 image_03 这样的图片资源作为帧动画素材，使用的时候是 image_%d 或者 image_\(index) 方式，FengNiao 会把这些图片资源作为使用中的资源，不会出现误删的情况。当然如果你还是用了其他 Pattern，可以考虑扩展 FengNiao。
除了这些之外，FengNiao 是命令行工具，我们可以给 Xcode 添加 Run Script，在每次构建的时候自动检测/清理未使用的资源。
由于基于源码的扫描工具结果不是百分百准确的，所以建议最好的做法是在项目编译的时候提供出显式的 Warning，然后再次确认之后再去删除。同时也可以配合资源命名规范来优化工具，如果你们的命名规范和工具的检测规范能够保持一致的话，搜索的结果无疑是最为准确的。
之所以要使用自动化工具来检测重复资源的原因是因为资源是弱类型，我们在项目迭代过程中手动去维护是相当麻烦的一个过程。转换一下思维，如果资源变成强类型了，那我们维护起来就相当容易了。目前就有这样一个工具-R.swift，类似于 Android 开发中的 R 文件，有兴趣的可以去尝试。
3.1.2.2. 去除重复资源
这里所说的重复资源是资源内容相同但是命名不相同的一些资源，对于此类资源，我们可以使用 fdupes 来进行扫描并去除，fdupes 的原理是对比不同文件的签名，签名相同的文件就会判定为重复资源。
然后我们就可以在 Xcode 中添加 Run Script，对于扫描到的相同的资源，我们可以显式的报出 Warning，然后我们在开发阶段解决资源重复的问题。
3.1.3. On-Demand Resources
On-Demand Resources 是 Apple 在 iOS 9 跟 App Thinning 一起引进的一项减少安装包体积技术，大致的概念是苹果帮你把所有 App 中的资源管理在 App Store 云端上，然后你需要把资源标记为不同的 Tag，需要的时候才去下载相应 Tag 的图片。引用苹果文档中的一张图表示。
这种机制对于许多图片资源都放在本地的 App 就会比较有用，比如游戏中的不同关卡可以分为不同的 tag，在用户通关了一关之后才下载下一关资源。
3.2. 视频/音频图片资源远端化
视频/音频等图片资源相对图片来说会大很多，所以建议把视频/音频放在服务端，客户端在使用的时候进行下载或者使用流播放。
3.3. HTML5 远端化
H5 资源也是建议放在服务端，如果对 H5 加载和离线访问有要求的话，可以使用离线缓存的方式来缓存网页资源到本地。
3.4. 视图资源
这里所说的视图资源是指 xib/storyboard。xib 在打包时会被压缩为 nib 文件，storyboard 文件会被压缩为 storyboardc 文件，storyboardc 是个压缩包，内部包含了相应的 nib 和 一个 plist 文件。一般的 nib 文件压缩后在几 KB 到几十 KB 大小，这部分包大小的影响相对于 xib 能提高开发效率来说影响是微乎及微的，网易漫画 App 中使用到了 257 个 xib 文件，但是其在 payload 中的数据仅仅只有 1.7M 大小。
4. Framework
Framework 文件夹存放的是 Embedded Framework，它在打包的时候最终会被拷贝进 Target App Bundle 中的Framework 文件夹中，在 App 启动的时候才会被链接和加载。Embedded Framework 主要分类两类：
（1）SwiftSupport：Framework 文件夹中前缀是 libSwift 的一些 framework。由于目前 Swift ABI 还未稳定，我们发布应用的时候还需要带上一份自己应用中使用到的 Swift 标准库代码，这部分占用最终 ipa 的大小可能在 10M 左右。
（2）其他依赖库：使用 Cocoapods 管理依赖并且设置了 user_framework! 时三方库源码都会打包成 framework，然后导入到工程当中。
4.1. Framework 中的资源
这里所说的 Framework 表示的是: 静态库(.a) Framework(Static Library)
目前绝大部分的 Framework 的做法是直接将资源放进 bundle 中进行管理的，在主工程打包的时候，Xcode 会将这部分资源直接拷贝进 App Target Bundle 中，这样做就存在2个问题：
使用 bundle 管理的资源是不会被 Xcode 优化的(图片压缩等)
使用 bundle 管理的资源不享受 App Thinning/Slicing。
所以尽量还是选择 XCAsset 进行 Framework 的资源管理，静态库和动态库的管理方式有所不同：
静态库(.a)/Framework(Static Library): 静态库的目标文件(.a/.framework) 中是不能包含资源文件的，所以这部分只能使用 bundle 来管理。但是由于 bundle 直拷贝的特性，我们需要把 xib/storyboard/asset catalog 编译后的产物(nib/storyboardc/Asset.car)放进 bundle 里。比较普遍的一个做法是借助 Bundle Target 来编译我们的资源文件，具体做法看这篇文章。
动态库: 动态库相对来说要简单一点，因为动态库本身就是一个 bundle。所以我们直接把资源文件放在目标文件(.framework)中就可以了。
如果你是使用 Cocoapods 管理你的源码，也可以使用 XCAsset 来管理资源，参考 在 Cocoapods中使用 XCAsset。
4.2. Framework 中的可执行文件
这部分可以参考以上的可执行文件瘦身。
5. Plugins
Plugin 内部主要存放的就是 App Extension，App Extension 是独立打包签名，然后再拷贝进 Target App Bundle 的。
5.1. Plugin 中的静态库
静态库最终会打包进可执行文件内部，所以如果 App Extension 依赖了三方静态库，同时主工程也引用了相同的静态库的话，最终 App 包中可能会包含两份三方静态库的体积。
5.2. Plugin 中的动态库
动态库是在运行的时候才进行加载链接的，所以 Plugin 的动态库是可以和主工程共享的，把动态库的加载路径 Runpath Search Paths 修改为跟主工程一致就可以共享主工程引入的动态库。
5.3. Plugin 中的 Swift Standard Library
在 Swift ABI 稳定之前，Swift 标准库会被拷贝进 App 当中。Swift 标准库是动态链接库，也是可以在主工程和其他的 App Extensions 之间共享的，前提当然是所有 Target 使用的 Swift 版本是一致的，否则就会出现意料之外的 bug。 设置共享分为两步：
设置 Extension 中的 Always Embed Swift Standard Libraries 为 NO，让编译器不再为 Extension 生成 Swift 标准库
设置 Extension 中的动态库的查找路径为主工程的 Framework 文件夹
6. 在网易漫画中的实践
我们在网易漫画 App 中逐渐进行了实践，此次主要进行的是可执行文件的瘦身：编译优化以及去除符号；资源瘦身：冗余资源清除以及主工程图片分片（App Thinning）。下面是优化前后的部分数据
当然以上并非此次瘦身的全部内容，Framework 瘦身，冗余代码清除等比较难的点后续也会陆续展开实践，同时也会在本文中进行更新。Executable 的数据显示的比较夸张的主要原因是我们在做瘦身的时候同时去除了之前使用到的直播 SDK，实际可执行文件的提升效果应该也在 30% 左右。IPA 文件从最初的 70+M 到现在 39.4M，总的来说效果还是相当明显。
7. 结论
将 Build Settings -> Clang/LLVM Generate Code -> Optimize Level 设置为 Fastest, Smallest(-Os)。
将 Build Settings -> Swift/LLVMGenerate Code -> Optimize Level 设置为 Optimize for Size(-Osize)。
将 Build Settings -> Strip Linked Product 和 Strip Swift Symbols 设置为 YES，Deployment Postprocessing 设置为 NO，发布代码的时候也需要勾选 Strip Swift Symbols。
Strip Debug Symbols During Copy 在 Release 模式下设置为 YES。
有条件的话，适配 BitCode。
无论在主工程或者 Framework 中都使用 XCAsset 来管理资源。
使用工具扫描删除无用资源，推荐选择 FengNiao，并添加 Run Scripts。
使用工具扫描重复资源，推荐选择 fdupes，并添加 Run Scripts。
如果你大量资源都放在本地，推荐使用 On-Demand Resources 方式来管理资源。
在 Swift ABI 稳定之前Extension 和主 App 之间共享 Swift Standard Libraries。
开启 Compress PNG Files/Remove Text Metadata From PNG Files。
将 Dead Code Stripping 设置为 YES。
使用工具扫描和清理无用代码，同时养成良好习惯，在迭代或者重构的时候删除旧的代码。
使用工具扫描重复代码并重构它。
视频/音频/H5 等资源远端化。
使用 xib/storyboard 来开发视图界面会一定程序增加安装包的大小。
使用 Swift 来开发程序会一定程序增加安装包的大小，对包大小有严格要求的话也可以衡量是否使用 Swift。
如果你对包大小有严格要求的话，选择合适大小的三方库来进行开发。
本文作者：饶梦云
相关阅读：
参考文献：
https://juejin.im/post/5800ef71a0bb9f0058736caa
http://www.cocoachina.com/ios/20151211/14562.html
https://swiftcafe.io/post/swift-optimization
http://blog.cnbang.net/tech/2544/