这是一次安装包大小优化的实践。
随着业务的增加，工程中引入越来越多的业务代码和第三方库， 整个安装包越来越大。以今日头条/tinymind/LSUnusedResource 编译运行看到的页面是这样的：
指定搜索路径， 第二行（EXClude）指定哪些文件夹路径不被扫描。
然后这些资源可以清除掉了。但是存在着图片被误删除的可能性，譬如代码中使用图片的方式是：[UIImage imageNamed:[NSString stringWithFormat:”icon_%d.png”,index]]； 这种情况下，图片可能被误删，所以删除的时候不妨10张一组的进行，用眼睛过滤一遍。
* 删除完图片，是否还可以对已有的图片做优化呢。
现在网上有非常多的关于ImageOptim对资源图片进行无损压缩的方式， 在文章开头部分我们也对ImageOptim的优化能力进行了一些验证，通过上面的实验，我觉得结论不能确定，但值得一试。
- 是否有不必要的文档资源，如果过期的旧版本所需要的文档资源 清理即可。
- 优化文档资源大小，主要是优化精简文档内容。
二进制包是由各种代码文件，静态库 动态库 经过编译后生成的可执行文件。 以头条二进制包125MB为例， 他是如何组成的#
上图可以看到armv7 占可执行文件的58MB。 arm64占可执行文件的66MB。 加起来=125MB。 进一步分析
通过右侧的pfile偏移可以大概算出每个段的大小，但不直观， 我们可以通过开启一些编译选项，生成可执行文件结构，然后借助一些工具生成更加直观的
-
这个LinkMap里展示了整个可执行文件的全貌，列出了编译后的每一个.o目标文件的信息（包括静态链接库.a里的），以及每一个目标文件的代码段，数据段存储详情
如上图，weinAppID这个函数占得内存大小为1*16 + 13 = 29字节。样看下去也挺麻烦的， 找个工具归类一下。
-
下载这个mac工程 然后运行。
譬如内部播放器sdk MediaPlayer在arm64架构下大小为4.92MB， armv7也可以分析另一份armv7 linkmap文件大概4.5MB 二者加起来就是在二进制占据的总大小—10MB左右。 通过对上面的文件进行分析，就知道每个类在最终的可执行文件中占据的大小。 然后有针对性的进行优化就可以了。
如果项目是很早之前（xcode4，5）建立的，迭代到现在 的确可以检查一下有利于减少安装包的编译选项：
-
优化效果还是非常明显的。 PS：Deployment Postprocessing这个配置项如果使用xcode打包，xcode会默认把这个变量置为YES， 如果使用脚本打包，记得设置。
将Enable C++ Exceptions和Enable Objective-C Exceptions设为NO，去掉异常支持； 如果你的项目比较大，有很多try cache， 想去掉这些异常可能是一个比较大的工作量，我在头条项目里尝试去掉了所有异常，打包测试，安装包大小没有 变化， 因为只是一个项目的测试，我只能比较怀疑去掉异常对最终安装包大小的优化能力。
iOS的项目，在安装包没有大到一定程度之前，研发和产品一般都关注较少，我们在平时的开发中也会有一些不好的习惯，在这里枚举一下：
- 不要为了一片树叶 引入一片森林。 有时候你只想接入一个base64编码的函数，结果接入了一个有几十个类文件的util库，除了你用到的这个函数，其余的可能再也不会有人用到， 另一个研发为了另一个RSA加密需求，结果又引入了另一个一个extensions库 。那些类文件都是成本，类文件，函数，甚至不同长度的函数名字都对最终的安装包大小产生影响。 积少成多， 安装包会越来越大。 而且代码量越大，app启动时候DYLD链接的工作量越大，启动耗时也会变长。
- 对于要接入到app的资源文件，要check一下大小，一个100*100大小的图片如果几十MB 肯定设计师在切图的时候有些问题，打包后也要check一遍。对于集体打包到Assert.car里的文件，可以找工具解开看一下。 我们遇到过打了一次包后 发现安装包大了几十MB，经过分析，发现是有一张图片意外的大，找人优化后 变成几百k。
- 注意平时的开发习惯，废弃模块及早清理。
- 建立预警机制， 一般上线后，都是脚本打包，除了正常的生成ipa包之外，也要生成分析文件， 列出相对上一次上线包大了多少，类文件增加了多少。这样的机制也有助于防止安装包悄无声息的变成巨物。
