一安装包大小优化Asset Catalog Compiler - Options Optimization
Build Setting > Asset Catalog Compiler - Options
在Optimization优化设置项有三个选项，不指定、time和Space。
Optimization nothing是Xcode默认的设置。
与预想的不同，在选择Optimization time时，编译时长并没有得到优化。
但在Optimization space时，编译耗时基本没有波动，但编译生成的app大小有不小程度的优化。
二 安装包大小优化Flatten Compiles XIB Files
是否扁平化编译XIB文件。
官方解释是：指定是否在编译时剥离nib文件以优化它们的大小，设为YES时编译出来的nib文件会被压缩但是不能编辑。
三安装包大小优化清理未被使用的图片资源LSUnusedResources
项目的开发过程总是会经历较长期的迭代，不断的添加功能的同时会引入大量的图片资源。需求变更、业务逻辑修改等需要移除某些功能模块时就会导致这些前期加入的图片资源问价被忽略而遗留在编译的安装包中，长此以往会使得安装包变得格外臃肿。特别是类似于手Q项目的开发，开发人员多，产品迭代频繁，开发时间紧俏，开发人员轮换等特点更有可能导致这样的后果。
一个较为传统的清理方法时将图片资源的文件名一一复制粘贴到Xcode的全局变量查找中去查找该字符串，如果返回的结果为零，则该资源很有可能没被使用。之所以是“很有可能”，是因为在代码中，资源有时是通过字符串拼接的方式进行引用的。
在这里提供一个github上的开源工具 LSUnusedResources ，这个工具是对github上的另一个开源工具Unused的优化改进（匹配速度、结果准确性），作者针对源码、Xib、Storyboard 和 plist 等文件，先全文搜索其中可能是引用了资源的字符串，然后用资源名和字符串做匹配，从而找出未被使用的资源，比Unused的查找速度要快得多。
使用起来也比较简单：
1
、将工程目录路径拷贝到Folder或通过Browse浏览文件目录；
2
、在Resource指定要查找的资源类型；（经过本人测试，发现该工具在未指定Resource类型时所查找出来的资源不是很准确，列举出 的资源事实上是正在使用的，所以我在测试时指定查找了png类型的文件。）
3
、单击Search以查阅结果。
注：为了避免对资源的误删操作，建议在该工具输出结果后对结果中的资源名复制并在Xcode的全局查找
中进行校验。
下载安装：LSUnusedResources.app.zip
Github
地址：LSUnusedResources参考链接：查找XCode工程中没被使用的图片资源
四 安装包大小优化 Deployment Postprocessing和Strip Linked Product
Xcode中Strip Linked Product 的默认设置为YES，但是Deployment Postprocessing的默认设置为NO。在Deployment Postprocessing 是Deployment的总开关，所以在打开这个选项之前 Strip Linked Product是不起作用的。
注：当Strip Linked Product设为YES的时候，运行app，断点不会中断，在程序中打印[NSThread callStackSymbols]也无法看到类名和方法名。而在程序崩溃时，函数调用栈中也无法看到类名和方法名
打开这两个选项之后进行编译，编译出的安装包大小有了较大程度的优化：
五 安装包大小优化 Linking->Dead Code Stripping
将Dead Code Stripping 设置为YES 也能够一定程度上对程序安装包进行优化，只是优化的效果一般，对于一些比较小的项目甚至没有什么优化体现，所以这里也就没有上测试数据。
Dead Code Stripping 是对程序编译出的可执行二进制文件中没有被实际使用的代码进行Strip操作。
对于更深层次的解读，在参考链接的文章里有详细描述。
六 安装包大小优化 第三方库
导入类似分享、地图等第三方库时，尽量根据需要的功能导入相应的包来代替全部的功能
例如 友盟精简版和全部功能至少有30M的空间差别。
网友评论