背景
app 体积越来越大，App Store 还有 100M 不能使用流量下载的限制。无论是领导或者产品经理，都希望包尽量小，而功能尽量多。
iOS 打包生成的可执行文件 ipa，其实是个压缩包。可以通过 Mac 系统的显示包内容查看其完整的成分。里面包括了资源文件和可执行文件，以及一些开发人员无法控制的如签名和权限文件等。
拿到减小包体积的工作任务时，首先是进行资源文件的压缩和无用资源的删除。接下来，是精简代码量或者通过动态化的方案来代替Native来减小可执行文件大小。这里不讨论动态化，我们使用前者来完成任务。
现状
精简代码量需要有个指标，特别是多人合作的工程里，每个人负责不同的模块。我们需要知道每个模块代码占最终包体的比例和大小。分析代码量，显然是不可以通过统计未编译的代码有多少行来进行，宏和编译选项等因素会导致编译后与编译前差别很大。采用分析最终可执行文件成份的方法。
解决方案
OC 时代，CocoaPods 的各个 pod 是通过静态库方式打包进最后的可执行文件中的，在主工程里的代码和 pods 里的代码，从最终结果看来，没有区别，都在一个可执行文件中。这里，我们借助于编译过程生成的辅助文件 LinkMap。 LinkMap 大体来看由三部分组成——
Object files, Sections, Symbols。Object files 列出了包含的所有的目标文件.o和对应的索引。Sections 从概览上列出可执行文件中代码段和数据段的大小。最后 Symbols 是我们分析的重点，从代码段的起始地址开始，按照地址顺序依次列出了代码中的函数、全局变量等所占的代码大小。每一行由四列，分别是起始地址、大小、对应的文件的索引和具体的函数名等。
统计 Symbols 的每一行，可以得出每个 .o 所占代码的多少，然后再根据 .o 所在的 pod，可以得出每个 pod 所占代码的多少。.o 具体在哪一个 pod 中，Object files可以看到，因为列出了完整的文件路径。最终，通过 CocoaPods 静态库集成的 pods，占可执行文件代码的多少，就统计出来了。
Swift 时代，使用动态库来集成 pods。最后的可执行文件里，会有内嵌的动态库可执行文件。不用 LinkMap 文件，统计动态库的可执行文件可以得出各个模块所占可执行文件代码的多少。
优化及后续
基于以上的分析结果，可以每周发布一个报告，公布各个模块代码量的大小和占比。这样有利于模块负责人及时的删除冗余和废弃代码，及时的精简代码和重构，提升代码质量，减小包体积。
