iOS app瘦身优化之路

缩减iOS安装包大小是很多中大型APP都要做的事，一般首先会对资源文件下手，压缩图片/音频，去除不必要的资源。这些资源优化做完后，我们还可以尝试对可执行文件进行瘦身，项目越大，可执行文件占用的体积越大，又因为AppStore会对可执行文件加密，导致可执行文件的压缩率低，压缩后可执行文件占整个APP安装包的体积比例大约有80%~90%，还是挺值得优化的。

瘦身的第一步

对于app瘦身之前做过图片优化，采用脚本的方式把一些在pods中的图片迁移至imageSet下，但是这样的优化是有瓶颈的，因为它受制于图片的多少、图片在pods下的存储方式，而由于pods之间的依赖关系复杂以及有些pods中的图片为了避免全局重复问题采用resource_bundle方式来管理，这样对于图片优化极为不利，所以可以优化的空间还是有上限。这是瘦身的第一步，现在已经完成了，并且对部分采用resource_bundle方式的以的pods加以修改。这个可以参考这篇文章：点击打开链接

瘦身的第二步

考虑到整个app依赖pods多达119个，可想而之就是这些依赖是不是都全部用上了，这个是有些疑惑的，如果能够剔掉一部分无用的依赖pods，这对于瘦身也是大有益处的。但是不幸的是，在网上怎么查找也没有找到相关工具可以检测到哪些是无用的pods，这样扔下一个难题，只好采用最笨的方式去挨个手动查找了。首先去podfile里面找那些没有被依赖的pods，然后去项目中找到这些pods，然后通过找到使用这些pods的入口类，然后在在全局搜索这个类，如果有其他代码使用这个类，那么这个pod是有用的，如果找不到其他任何代码对些有引用，那可以判断这个pod是无用依赖，这样可以将此pod进行踢除。难点在于如何快速确定一个pod的入口类，这个是比较难确定。但是如果去掉的pods能通过编译并且能正常安装和运行，那说明这个pods肯定是无用的。所以根据这一操作，现在粗略去掉了六个pods以及大象相关的pods，这项工作需要比较细心，而且耗费时间，但是也是一种可行方式。现在项目所有依赖库个数减少到了97个。

瘦身的第三步

从编译选项着手，编译选项方面又可以分为下面两个方面：

1.编译器优化级别

Build Settings->Optimization Level有几个编译优化选项，release版应该选择Fastest, Smalllest，这个选项会开启那些不增加代码大小的全部优化，并让可执行文件尽可能小。

2.去除符号信息