如何从资源和代码层面实现App全方位瘦身？

引言

其实关于此类的博客网上有很多，可能有很多是原创，可能有很多是转载，当然也有很多是抄袭，前些天看到头条也有一篇，写的很好，但是觉得对于初学者，实质性意义觉得不大【因为毕竟要代码保密，资源保密】。

本人写此篇博客是因为觉得App已经迭代了接近20个版本，包体积至今没有优化过，于是本人就想着去优化ipa大小【完全使用本人项目开刀】。如果也想跟着尝试，那就Follow，共同优化包体积大小，从下载那一刻优化吧！！！

经过实际验证，本人负责项目从开始89MB，到达优化之后的75MB【项目名称不说啦，但是目的达到了，嘿嘿】，还是提高了不少滴。

共同提高，共同进步永远是我写博客的目的~共勉，欢迎点赞，给个小红心❤️

背景与问题

App Store规定了安装包大小超过200MB的App不能使用OTA【over-the-air】环境下载，也就是只能在WiFi环境下下载。所以200MB就成了App的生死线，一旦超过这条线就很可能会失去大量用户。【如果你的App要兼容iOS7和iOS8的话，苹果官方主二进制text段的大小不能超过60MB。如果没有达到这个标准，你甚至都没法提交App Store】 另外，App包体积过大，对用户更新升级率也会有很大影响。

综上所述，App 包过大既损害用户体验，影响升级率，还会导致无法提交 App Store 的情况和非 WiFi 环境无法下载这样可能影响到 App 生死的问题。那么，怎样对包大小进行瘦身和控制包大小的不合理增长就成了重中之重。

分析与定位

对于一个App 从0-1 以及后续团队不断的迭代，研发人员的不断增多，伴随着也有能力的参差不齐，代码质量的高低不同。如果一味的增加需求，一味的写冗余重复的代码，势必很难维护以及打出的ipa包体积越来愈大。经历过一些版本的迭代，会发现ipa包体积变大了很多，想到了这些，我们应该可以做些什么，或者苹果官方为我们做些什么呢？

• 官方App Thinning做了些啥呀？【从本质了解“官方瘦身”】
• 如果删除无用图片资源，是否能达到包体积大小优化呢？
• 或者压缩图片视频大小等，包体积可以减小嘛？
• 给代码瘦身，找出无用代码，复用代码等
• 其他一些方法

下面就按照上面一步一步跟着，给自己的App包瘦身。

官方App Thinning

App Thinning可以译成“应用瘦身”。指的是App store 和操作系统在安装iOS或者watchOS的 app 的时候通过一些列的优化，尽可能减少安装包的大小，使得 app 以最小的合适的大小被安装到你的设备上。

App Thinning 是由苹果公司推出的一项可以改善 App 下载进程的新技术，主要是为了解决用户下载 App 耗费过高流量的问题，同时还可以节省用户 iOS 设备的存储空间。现在的 iOS 设备屏幕尺寸、分辨率越来越多样化，这样也就需要更多资源来匹配不同的尺寸和分辨率。同时，App 也会有 32 位、64 位不同芯片架构的优化版本。如果这些都在一个包里，那么用户下载包的大小势必就会变大。

官方App Thinning包括了三个过程：slicing，bitcode，和 on-demand resources

3.1 Slicing

App Slicing在节省应用所需资源中发挥着最重要的作用。

App Thinning 会专门针对不同的设备来选择只适用于当前设备的内容以供下载。比如，iPhone 6 只会下载 2x 分辨率的图片资源，iPhone 6plus 则只会下载 3x 分辨率的图片资源。

Slicing 的主要的工作流程图和过程如下：

• 在Xcode中，选择好目标设备并且使用asset catalog提供多分辨率的图片资源，只有使用asset catalog才能正确使用Slicing作用于资源文件
• 在模拟器或者设备上编译并运行app
• Xcode会自动构建针对你运行设备的“简化版app”，同时也是为了减少编译时间和进行本地的测试
• 打包app【为了及时发现不同设备的配置错误，可以在本地为目标设备导出“简化版app”，测试无误后再打包】
• 上传打包好的app到iTunes Connect。App store将会为上传的app归档创建不同的“简化版app”
• 在iTunes Connect中，发布一个预览版给合格的测试者进行测试
• 测试者通过TestFlight下载预览版。TestFlight会自动根据测试者的设备下载合适的“简化版app”

3.2 bitcode

Bitcode是一个编译好的程序的中间表示形式。上传到 iTunes Connect 中的包含Bitcode的app 将会在 App store 中进行链接和编译。苹果会对包含Bitcode的二进制app进行二次优化，而不需要提交一个新的app版本到app store中

3.3 On-Demand Resources

ODR（on-demand resources 随需应变资源)是iOS减少应用资源消耗的另外一种方法。比如多级游戏，用户需要的通常都是他们当前的级数以及下一级。ODR意味着用户可以下载他们需要的几级游戏。随着你的级数不断增加，应用再下载其他级数，并将用户成功过关的级数删掉。

当用户点击应用内容的时候，就会动态从App Store上进行下载，也就是说用户只会在需要的时候占用存储空间。这项功能有趣之处还在于当将这些内容在后台进行下载之后，当存储空间紧张的时候会自动进行删除。

如果要进一步减小 App 包体积的话，还需要在图片和代码上继续做优化。为了减小 App 安装包的体积，我们还能在图片上做些什么？

删除无用图片

删除无用图片应该是图片资源的优化空间最先想到的。那么，我们是如何找到并删除这些无用图片资源的呢？

对于删除图片，本人在项目中的实践采取的是下面的第二种第三种方法，大家跟着操作：

• 删除无用图片的思路
• 一个一个图片查找删除【工作量太大】
• 使用开源组件FengNiao
• LSUnusedResources【最好用】

下面我们按照这个步骤开始着手去做~

4.1 方案思路

删除无用图片的过程可以分为总共6个步骤和图解【思路如下】

• 通过find命令获取App安装包中所有的资源文件，比如<span style="font-size: 14px;">find /Users/zhang**/Project/ -name
• 设置用到的资源的类型，比如jpg、gif、png、webp
• 使用正则匹配在源代码中找到使用到的资源名称，比如<span style="font-size: 14px;">pattern = @"@"(.+?)""。
• 使用find 命令找到所有资源文件，再去掉代码中使用到的资源文件，剩下的就是无用资源
• 对比按照规则设置的资源名，需要在匹配使用资源的正则表达式里添加相应的规则，比如@“image_%d”
• 确认无用资源后，就可以对这些无用资源执行删除操作了。这个删除操作，你可以使用 NSFileManger 系统类提供的功能来完成。

4.2 费时有效操作

可以找到Assets.xcassets，对照着里面的一张张图片，然后在工程目录搜索，如果工程没有使用到的话，那就删除吧，此方法很土但费时，有没有好的操作方法呢？

4.3 开源组件FengNiao

FengNiao–一个删除Xcode工程中无用图片资源的神器！FengNiao一个命令行工具，由iOS界的大神onevcat喵神使用swift开发并开源。

4.3.1 安装FengNiao

下载FengNiao

git clone https://github.com/onevcat/FengNiao.git

进入到FengNiao目录下

执行./install.sh

fengniao会自动编译安装到/usr/local/bin目录下，然后成功结果如下：

4.3.2 使用 FengNiao

cd到项目工程中，直接使用fengniao命令就可以【提供list（列表查看）、delete（直接删除）、ignore（忽略这些文件）三个命令】

通过输入l，就可以列举未使用的图片，大家对着看就好了，嘿嘿嘿，体验还不错！！！

4.4 LSUnusedResources

本人建议这个是最好用的。大家可以查看LSUnusedResources源码

如果你不想自己重新写一个工具的话，可以选择开源的工具直接使用。本人觉得目前最好用的是 LSUnusedResources【运行此代码，最好的是还有人在维护，给作者一个赞】特别是对于使用编号规则的图片来说，可以通过直接添加规则来处理。

使用方式也很简单，可以参看下面的动画演示：【运行代码之后的界面】

4.4.1 下载代码，并运行出来的结果如下

4.4.2 将根目录输入进去，选择匹配法则，就可以可视化无用的图片

经过上面的三个方法，可以将无用图片彻底删除了，嘿嘿，完成优化了3-5MB的大小。不错不错~

图片视频等压缩

无用图片资源处理完了，那么有用的图片还有瘦身的空间吗？答案是有的。

5.1 视频压缩方面

对于本人项目，安装App时，会有几个引导介绍视频，原本每一个视频大约都是2-3MB，但是对于包的减少，本人又让UI和视频组对4个引导视频压缩，最后大约每个引导都是1.3MB以内

此时引导视频优化了4-5MB优化空间，下面进行图片压缩方案探究。

5.2 图片资源压缩

对于 App 来说，图片资源总会在安装包里占个大头儿。对它们最好的处理，就是在不损失图片质量的前提下尽可能地做压缩。

5.2.1 WebP

目前比较好的压缩方案是，将图片转成 WebP。WebP 是 Google 公司的一个开源项目。

• WebP 压缩率高，而且肉眼看不出差异，同时支持有损和无损两种压缩模式。比如，将 Gif 图转为 Animated WebP ，有损压缩模式下可减少 64% 大小，无损压缩模式下可减少 19% 大小。
• WebP 支持 Alpha 透明和 24-bit 颜色数，不会像 PNG8 那样因为色彩不够而出现毛边。

怎么把图片转成WebP？

Google 公司在开源 WebP 的同时，还提供了一个图片压缩工具 cwebp来将其他图片转成 WebP。cwebp 使用起来也很简单，只要根据图片情况设置好参数就行。

cwebp 语法如下：

cwebp [options] input_file -o output_file.webp

比如，你要选择无损压缩模式的话，可以使用如下所示的命令：

cwebp -lossless original.png -o new.webp

其中，-lossless 表示的是，要对输入的 png 图像进行无损编码，转成 WebP 图片。不使用 -lossless ，则表示有损压缩。

5.2.2 腾讯开发的iSpart

iSpart 是一个 GUI 工具，操作方便快捷，可以实现 PNG 格式转 WebP，同时提供批量处理和记录操作配置的功能。如果是其他格式的图片要转成 WebP 格式的话，需要先将其转成 PNG 格式，再转成 WebP 格式。它的GUI界面如下：

不过，WebP 在 CPU 消耗和解码时间上会比 PNG 高两倍。所以，我们有时候还需要在性能和体积上做取舍。

本人建议如果图片大小超过了 100KB，你可以考虑使用 WebP；而小于 100KB 时，你可以使用网页工具 TinyPng或者 GUI 工具ImageOptim进行图片压缩。这两个工具的压缩率没有 WebP 那么高，不会改变图片压缩方式，所以解析时对性能损耗也不会增加。

经过对部分图片的压缩，少了大约2-4MB的优化空间，到目前为止差不多有10-12MB的优化空间。嘿嘿~

代码瘦身

App 的安装包主要是由资源和可执行文件组成的，所以在掌握了对图片资源的处理方式后，需要再一起来看看对可执行文件的瘦身方法

6.1 通过Appcode找出无用代码

如果工程量不是很大的话，我还是建议你直接使用 AppCode 来做分析【本人项目就是使用它】当代码量过百万行时 AppCode 的静态分析会“歇菜”。毕竟代码量达到百万行的工程并不多。而，那些代码量达到百万行的团队，则会自己通过 Clang 静态分析来开发工具，去检查无用的方法和类。

用 AppCode 做分析的方法很简单，直接在 AppCode 里选择 Code->Inspect Code 就可以进行静态分析。

静态分析完以后，我们可以在 Unused code 里看到所有的无用代码，如下：【感觉棒棒哒】

接下来，说一下这些无用代码的主要类型。

• 无用类：Unused class 是无用类，Unused import statement 是无用类引入声明，Unused property 是无用的属性；
• 无用方法：Unused method 是无用的方法，Unused parameter 是无用参数，Unused instance variable 是无用的实例变量，Unused local variable 是无用的局部变量，Unused value 是无用的值；
• 无用宏：Unused macro 是无用的宏。
• 无用全局：Unused global declaration 是无用全局声明。

看似 AppCode 已经把所有工作都完成了，其实不然。下面，列举下 AppCode 静态检查的问题：

• JSONModel 里定义了未使用的协议会被判定为无用协议；
• 如果子类使用了父类的方法，父类的这个方法不会被认为使用了；
• 通过点的方式使用属性，该属性会被认为没有使用；
• 使用 performSelector 方式调用的方法也检查不出来，比如 <span style="font-size: 14px;">self performSelector:@selector(arrivalRefreshTime)；
• 运行时声明类的情况检查不出来。比如通过 NSClassFromString 方式调用的类会被查出为没有使用的类，比如 <span style="font-size: 14px;">layerClass = NSClassFromString(@“SMFloatLayer”)。还有以<span style="font-size: 14px;">[[self class] accessToken] 这样不指定类名的方式使用的类，会被认为该类没有被使用。像 UITableView 的自定义的 Cell 使用 registerClass，这样的情况也会认为这个 Cell 没有被使用。

基于以上种种原因，使用 AppCode 检查出来的无用代码，还需要人工二次确认才能够安全删除掉。

经过Appcode工具，大约找出优化了2-4MB的无用的类和代码。

除了这种方式，还有没有其他方法了呢？答案是有的，但是下面方法本人没有用到项目中尝试，但是还是要和大家说下，大家可以去尝试。

6.2 LinkMap结合Mach-O找出无用代码

可执行文件的瘦身方法。可执行文件就是 Mach-O 文件，其大小是由代码量决定的。通常情况下，对可执行文件进行瘦身，就是找到并删除无用代码的过程。

查找无用代码，按照找无用图片的思路，即：

• 首先，找出方法和类的全集；
• 然后，找到使用过的方法和类；
• 接下来，取二者的差集得到无用代码；
• 最后，由人工确认无用代码可删除后，进行删除即可。

接下来，我们就看看具体的代码瘦身方法吧。

6.2.1 Link Map File配置

点击工程，选择 Build Setting 选项，搜索 map ，可以看到如下界面。将 Write Link Map File 设置为 Yes 后，Build结束后，会在默认路径下生成一个 Link Map File 文件，该文件是 txt 格式的。点击 Path to Link Map File ，可以设置 Debug 或 Release 模式下的生成路径。设置选项如下图所示：

查到Path to Map File路径【本人采用的模拟器】

打开txt文件

6.2.2 Link Map讲解

LinkMap 文件分为三部分：Object File、Section 和 Symbols

其中：

• Object File 包含了代码工程的所有文件；
• Section 描述了代码段在生成的 Mach-O 里的偏移位置和大小；
• Symbols 会列出每个方法、类、block，以及它们的大小。

得到了代码的全集信息以后，我们还需要找到已使用的方法和类，这样才能获取到差集，找出无用代码。所以接下来，说说怎么通过 Mach-O 取到使用过的方法和类。

objc_selrefs 里的方法一定是被调用了的。objc_classrefs 里是被调用过的类，__objc_superrefs 是调用过 super 的类。通过 __objc_classrefs 和 __objc_superrefs，我们就可以找出使用过的类和子类。

6.2.3 用 MachOView查看可执行文件验证上面

如图上所示，可以看到 __objc_selrefs、__objc_classrefs和、__objc_superrefs 等这三个 section。

注意：

但是，这种查看方法并不是完美的，还会有些问题。原因在于， Objective-C 是门动态语言，方法调用可以写成在运行时动态调用，这样就无法收集全所有调用的方法和类。所以，通过这种方法找出的无用方法和类就只能作为参考，还需要二次确认。

其他瘦身

Clang/LLVM 编译器优化选项

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

• None[-O0]: 编译器不会优化代码，意味着更快的编译速度和更多的调试信息，默认在 Debug 模式下开启。
• Fast[-O,O1]: 编译器会优化代码性能并且最小限度影响编译时间，此选项在编译时会占用更多的内存。
• Faster[-O2]：编译器会开启不依赖空间/时间折衷所有优化选项。在此，编译器不会展开循环或者函数内联。此选项会增加编译时间并且提高代码执行效率。
• Fastest[-O3]：编译器会开启所有的优化选项来提升代码执行效率。此模式编译器会执行函数内联使得生成的可执行文件会变得更大。一般不推荐使用此模式。
• Fastest Smallest[-Os]：编译器会开启除了会明显增加包大小以外的所有优化选项。默认在 Release 模式下开启。
• Fastest, Aggressive Optimization[-Ofast]：启动 -O3 中的所有优化，可能会开启一些违反语言标准的一些优化选项。一般不推荐使用此模式。

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

Swift Complier/LLVM 编译优化选项

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

部门协商与程序员编程素质【其他Tips】

• 不要随便依赖第三方类库，可能仅仅用到1个库中的几个方法，就引入巨形库，删除不使用的三方库。功能用的少但是体积大的三方库可以考虑自己重写。合并功能重复的三方库。
• 引导产品、交互、设计，使用同一种方式开发，以复用代码
• 少用多行宏，多用函数封装
• 代码复用，禁止拷贝代码，共用代码下沉为底层组件
• 尽量将图片资源放入 Images.xcassets 中，包括 pod 库的图片。Images.xcassets 中的图片加载后会有缓存，提升加载速度，并且在最终打包时会自动进行压缩，再根据最终运行设备进行 2x 和 3x 分发。
• 对于一些非必要的大资源文件，例如字体库、换肤资源，可以在 App 启动后通过异步下载到本地，而不用直接放在 ipa 包内。

当然还有一个终极大招砍需求，哈哈哈【此种方法可能不太容易实现】

总结

今天这篇文章，主要分享的是 App 安装包的一些瘦身方案。可以把包瘦身方案根据 App 的代码量等因素，划分为两种。

对于上线时间不长的新 App 和那些代码量不大的 App 来说，做些资源上的优化，再结合使用 AppCode 就能够有很好的收益。而且把这些流程加入工作流后，日常工作量也不会太大。【本人目前项目就是这种】

但是，对于代码量大，而且业务需求迭代时间很长的 App 来说，包大小的瘦身之路依然任道重远，这个领域的研究还有待继续完善。LinkMap 加 Mach-O 取差集的结果也只能作为参考，每次人工确认的成本是非常大的，只适合突击和应急清理时使用。最后日常采用的方案，可能还是用运行时检查类的方式，这种大粒度检查的方式精度虽然不高，但是人工工作量会小很多。