<资源优化>
1.去除无用资源
通过几次项目的升级后,项目中会出现一些没有用到的图片.这些图片在我们导入到项目中后,之后项目升级过程后并没有再次用到.
那这些图片我们是需要给他删除掉.那么一张一张排查图片比较麻烦.在这里给大家推荐一款工具-LSUnusedResources.
这款工具可以检索到项目中没有用到的资源.并且给出路径地址.我们这个时候就可以根据路径去删除无用的资源.
2压缩资源
使用工具去压缩图片
其实在我们使用这些图片的时候,我们其实是用的一些图片,但是像图片的创建日期,创建人之类的信息其实在我们项目中是没有用到的.
这些信息我们可以通过一些工具进行删除,这里给大家推荐款工具ImageOptim.这款工具可以根据
尽量使用8-bit图片
使用8-bit的PNG图片，比32-bit的图片能减少4倍的压缩率。由于8-bit的图片支持最多256种不同的颜色，所以8-bit的图片一般只应该用于一小部分的颜色图片。例如灰度图片最好使用8-bit。
音频的压缩
参考WWDC中的Audio Development for Games，里面介绍了如何有效的处理音频。常规来说，我们要使用AAC或MP3来压缩音频，并且可以尝试降低一下音频的比特率。
有时候44.1khz的采样是没有必要的，稍微低一点的比特率也不会降低音频的质量。
3冗余字符串
3.1代码上定义的所有静态字符串都会记录在在可执行文件的__cstring段，如果项目里Log非常多，这个空间占用也是可观的，也有几百K的大小，可以考虑清理所有冗余的字符串。
另外如果有特别长的字符串，建议抽离保存成静态文件，因为AppStore对可执行文件加密导致压缩率低，特别长的字符串抽离成静态资源文件后压缩率会比在可执行文件里高很多。
另外如果有特别长的字符串，建议抽离保存成静态文件，因为AppStore对可执行文件加密导致压缩率低，特别长的字符串抽离成静态资源文件后压缩率会比在可执行文件里高很多。
<编译优化>
Build Settings->Optimization Level有几个编译优化选项，release版应该选择Fastest, Smalllest，这个选项会开启那些不增加代码大小的全部优化，并让可执行文件尽可能小。
<可执行文件优化>
ARC->MRC
有人提出用ARC写的代码编译出来的可执行文件是会比用MRC大的，
原因大致是ARC代码会在某些情况多出一些retain和release的指令，例如调用一个方法，它返回的对象会被retain，退出作用域后会被release，MRC就不需要，汇编指令变多，机器码变多，可执行文件就变大了。还有其他细节实现的区别，先不纠结了。
那用ARC究竟会增大多少体积？我觉得从汇编指令的增多减少去算是很难算准确的，这东西涉及细节太多，还是得从统计的角度计算。
做了几个对比试验，统计了几个同时支持ARC/MRC的开源项目在开启/关闭ARC的情况下__TEXT代码段的大小对比。
只对比__TEXT代码段是因为：ARC对可执行文件大小的影响几乎都是在代码段.可执行文件会进行某种对齐，例如有些段在不足32K的时候填充0直到对齐32K，若用可执行文件大小对比结果可能是对齐后的，不准确。
实验数据：
结果是ARC大概会使代码段增加10%的size，考虑代码段占可执行文件大约有80%，估计对整个可执行文件的影响会是8%。