项目中在对IPA体积的优化
首先需要了解下ipa包的组成：
ipa是一个压缩包， 安装包里的主要构成是（图片+文档+二进制文件）
接下来会对各个部分分别尝试优化处理已减小安装包体积：
1.图片： 使用这个脚本工具可以大范围检测程序中没有用到的图片
http://blog.csdn.net/songhongri/article/details/21833069
使用方法： 1.将.sh文件放到所检测工程的目录下，
2.cd 到该目录项
3.执行脚本：sh
unusedImage.sh
在我自己工程里运行结果如下：
可以看到有好多资源都没有应用到。
注意：这里在删除未应用的图片时注意第三方库里的不能删除，保险起见相同文件夹下的最好在工程里手动再搜索一次，确定没有使用到，就可以删除了。这里对图片整理删除前后打包的IPA大小做一对比：
可以看到IPA减小了1M· 最关键的在于，我将未使用到的图片整理后发现；大小基本和IPA减小的一致
这就比较好玩了，也说明了每减少一张图片，就实实在在的减少了ipa的大小。
2.文档资源的优化
文档资源主要是排查：
是否有不必要的文档资源，如果过期的旧版本所需要的文档资源 清理即可。
优化文档资源大小，主要是优化精简文档内容。
3.二进制包优化
二进制包是由各种代码文件，静态库 动态库 经过编译后生成的可执行文件。
这里推荐一个归类工具：
https://github.com/huanxsd/LinkMap
，使用方法很详细，结果类似如图：
通过对上面的文件进行分析，就知道每个类在最终的可执行文件中占据的大小。 然后有针对性的进行优化就可以了。
4.Xcode编译选项优化：
在Build Setting 中对以下几点进行设置
Strip Linked Product 设置为YES 需要注意的是Strip Linked Product也受到Deployment Postprocessing设置选项的影响。在Build Settings中，我们可以看到， Strip Linked Product是在Deployment这栏中的，而Deployment Postprocessing相当于是Deployment的总开关。记得把Deployment Postprocessing也设置为YES， 该选项对安装包大小的影响非常大， 以刚刚的项目为例，如果不开启此设置，ipa大小是35.8M，比设置为yes大了4.8M PS：Deployment Postprocessing这个配置项如果使用xcode打包，xcode会默认把这个变量置为YES， 如果使用脚本打包，记得设置。
Symbols Hidden by Default设置为YES
Make Strings Read-Only 设置为YES
最后的一些建议：
iOS的项目，在安装包没有大到一定程度之前，研发和产品一般都关注较少，我们在平时的开发中也会有一些不好的习惯，在这里枚举一下：
1.不要为了一片树叶 引入一片森林。 有时候你只想接入一个base64编码的函数，结果接入了一个有几十个类文件的util库，除了你用到的这个函数，其余的可能再也不会有人用到， 另一个研发为了另一个RSA加密需求，结果又引入了另一个一个extensions库 。那些类文件都是成本，类文件，函数，甚至不同长度的函数名字都对最终的安装包大小产生影响。 积少成多， 安装包会越来越大。 而且代码量越大，app启动时候DYLD链接的工作量越大，启动耗时也会变长。
2.对于要接入到app的资源文件，要check一下大小，一个100*100大小的图片如果几十MB 肯定设计师在切图的时候有些问题，打包后也要check一遍。对于集体打包到Assert.car里的文件，可以找工具解开看一下。 我们遇到过打了一次包后 发现安装包大了几十MB，经过分析，发现是有一张图片意外的大，找人优化后 变成几百k。
3.注意平时的开发习惯，废弃模块及早清理。
4.同质的开源库（譬如AFnetworking vs ASIHttpRequest），只接入一种。
5.建立预警机制， 一般上线后，都是脚本打包，除了正常的生成ipa包之外，也要生成分析文件， 列出相对上一次上线包大了多少，类文件增加了多少。这样的机制也有助于防止安装包悄无声息的变成巨物。