常见操作
1、删除项目中冗余的图片资源 工具-LSUnusedResources
- Tips:
- 要选中
ignore similar name防止误删 - 实际中会出现误报情况
-
[UIImage imageNamed:[NSString stringWithFormat:@"01_0000%d.png",i]这种情况下01_00004.png没有排除掉 - SVGA动画使用的图片没有排除掉，删除的时候要检查下路径
-
- 要选中
- 总结
- 定期检查
- 注意防止误删
2、删除项目中要砍掉的功能
3、各种冗余的文件/xib/storyboard
4、移除迭代掉的三方SDK
5、删除重复的资源
fdupes 是Linux下的一个工具，可以在指定的目录及子目录中查找重复的文件。fdupes通过对比文件的MD5签名，以及逐字节比较文件来识别重复内容。
6、删除无用代码
- 总结
在项目里新建一个类，给它添加几个方法，但不要在任何地方import它，build完项目后观察linkmap，你会发现这个类还是被编译进可执行文件了。
按C++的经验，没有被使用到的类和方法编译器都会优化掉，不会编进最终的可执行文件，但object-c不一样，因为object-c的动态特性，它可以通过类和方法名反射获得这个类和方法进行调用，所以就算在代码里某个类没被使用到，编译器也没法保证这个类不会在运行时通过反射去调用，所以只要是在项目里的文件，无论是否又被使用到都会被编译进可执行文件。
对此我们可以通过脚本，遍历整个项目的文件，找出所有没有被引用的类文件和没有被调用的方法，在保证没有其他地方动态调用的情况下把它们去掉。如果整个项目历时很长，历时代码遗留较多，这个清理对可执行文件省出的空间还是挺可观的。
无用的代码可能包括包括：类，分类，协议，方法，实例变量，局部变量等。我们可以利用工具进行查找。
-
开启编译器警告来查找无用的方法，实例变量，局部变量
image.png
如上图，开启Unused Functions, Unused Ivars, Unused Variables。
- 查找没有使用的类
Github上有个工具可以使用：fui
App Thinning
Apple Guides and Sample Code 中介绍 App Thinning的三个组成部分: App Slicing, Bitcode和On Demand Resources这三个部分:
App Slicing
切片是为不同的目标设备创建和交付应用程序包变体的过程。
从iOS9.0开始, App Store将根据您的应用支持的设备来创建和提供不同的变体。图片资源根据其分辨率和设备系列进行切片。GPU资源根据设备功能进行切片。
用户在支持的设备上安装应用程序, 应用商店会下载基于用户设备的应用程序变体。
查询自己的APP同一个应用的相同版本，在同使用2x图片的机型(iPhone5s/iPhone6)上的包体大小相同，却比使用3x图片的iPhone6plus略小 。也就证明了以上观点。
On Demand Resources(随需应变资源)
按需资源是一种资源，例如图像和声音，您可以使用标记关键字和组内请求。商店托管Apple服务器上的资源并为您管理下载。按需资源可实现更快的下载速度和更小的应用程序大小，从而改善首次发布体验。
例如，游戏应用可以将资源划分为游戏级别，并且仅当应用预期用户将移动到该级别时才请求下一级资源。同样，只有当用户购买相应的应用购买时，应用才能请求应用内购买资源。
要在应用程序中设置按需资源,请参阅Apple Guides and Sample Code 中"On-Demand Resources Guide ".
Bitcode(位码):
Bitcode通过消除针对不同架构的优化，以及只下载相关优化，从而使下载变得更小。
位码是编译程序的中间表示形式。你上传到iTunes Connect中包含位码的应用程序将被编译并链接到商店。包括位码将允许苹果在未来重新优化你的应用程序二进制而不需要提交一个新的应用程序版本到App Store。
Xcode默认启用Bitcode， 但笔者在一次集成三方SDK时，文档上要求关闭Bitcode。 因此，是否开启该属性也要灵活决定。
综上可见, 苹果官方对于应用瘦身的机制已然相当完善， 开发者养成良好的编程习惯至关重要。
其他瘦身方式
1、非组件化开发的项目，冗余庞杂在所难免。 在这里，组件化的优势就显现出来。
2、反复无常的需求变动，加之研发本身的惰性: 需求的经常变更多少会摧残研发敏感的心灵, 一个功能今天要明天不要后天放一放也是蛮常见.久而久之,一个熬夜写出来&自己又实在喜欢的功能板块在面临夭折时,研发可能就会先放着不管.这样的操作多了,时间一长,几经转手,这样的代码/文件就会沉睡在项目中。
一系列惨痛的教训告诉我们: 当删则删,良好的编程习惯非常重要! 做好提交工作,写清楚提交内容即可!
3、Use Asset Catalog 图片资源管理
4、无损压缩图片
ImageOptim是一款优秀的无损图片压缩工具，它通过优化压缩参数，移除无用的文件元数据和不必要的颜色配置来实现图片的无损压缩。
压缩完之后效果还是很明显的，可能是美术提供之前没压缩过。
但发现实际生产的安装包体积没有变小，因为COMPRESS_PNG_FILES和STRIP_PNG_TEXT设置成了YES，Xcode会重新压缩一次图片，但是压缩之后的图反而比ImageOptim处理之后的图更大。改成NO就能让项目中的PNG保持不变。
两种方案：
- ImageOptim压缩 ->
COMPRESS_PNG_FILES和STRIP_PNG_TEXT设置为NO -
COMPRESS_PNG_FILES和STRIP_PNG_TEXT设置成YES
哪种方案优，还未验证
5、 可执行文件瘦身
LinkMap文件是Xcode产生可执行文件的同时生成的链接信息，用来描述可执行文件的构造成分，包括代码段（__TEXT）和数据段（__DATA）的分布情况。只要设置Project->Build Settings->Write Link Map File为YES，build完后就可以在设置的路径看到LinkMap文件了。
我们可以用脚本从linkmap中统计出每个.o目标文件占用的体积和每个.a静态库占用的体积。
编译选项
1、编译器优化级别
Build Settings->Optimization Level有几个编译优化选项，release版应该选择Fastest, Smalllest，这个选项会开启那些不增加代码大小的全部优化，并让可执行文件尽可能小。
2、ARC->MRC
ARC大概会使代码段增加10%的size，考虑代码段占可执行文件大约有80%，估计对整个可执行文件的影响会是8%。
可以评估一下8%的体积下降是不是值得把项目里某些模块改成MRC，这样程序的维护成本上升了，一般不到特殊情况不建议这么做。
3、类/方法名长度 （class-dump大概率会影响上线App Store，延迟审核）
观察linkmap可以发现每个类和方法名都在__cstring段里都存了相应的字符串值，所以类和方法名的长短也是对可执行文件大小是有影响的，原因还是object-c的动态特性，因为需要通过类/方法名反射找到这个类/方法进行调用，object-c对象模型会把类/方法名字符串都保存下来。
对此我们可以考虑在编译前把所有类和方法名进行混淆，跟压缩js一样，把长名字替换成短名字，这样做的好处除了缩小体积外，还对安全性有很大提升，别人拿到可执行文件对它class-dump出来的结果都是混淆后的类和方法名，就无法从类和方法名中猜出某个方法是做什么的，就难以挂钩子进行hack。不过这样做有个缺点，就是crash堆栈反解出来的堆栈方法名会是混淆后的，需要再加一层混淆->原名的转换，实现和使用成本有点高。
实际上这部分占用的长度比较小，中型项目也就几百K，对安全性要求高的情况可以试试。
