iOS App Package Size Optimization: A Technical Approach

百度APP iOS端包体积优化实践系列文章回顾：

针对无用方法清理，调研了各家厂商目前已公布的方案，主流方案基于Mach-O + LinkMap文件的分析，但是主要存在以下问题：

准确度低

针对系统方法需要手动过滤

针对load、initilize、attribute 相关调用无法识别

针对string反射调用无法识别，Target-Action 注册，Observer注册方法等无法识别

复杂语法场景下无法识别，如继承链中的方法调用，子类实现父类方法等场景

系统通知等场景

因为目前已公布方案存在如上不足，同时因为下线代码敏感度非常高，相关业务都很慎重。因此推动相关无用方法清理，识别准确度将非常重要，直接关系到相关业务下线无用代码的积极性，因此弃用了上述方案。

针对第二部分方案不足之处进行分析，可以看到其准确度低的核心问题是，针对产物进行分析，拿不到所有需要的信息，或者说还没有发现有效的手段去获取所期望获得的信息。而想要解决上面提到的问题，最佳途径就是获取到尽可能多的代码信息。既然从产物回溯不到所需要的，那么就可以考虑从源头也就是源码层面找到我们所需要的详细信息。

源码肯定包含了所有的信息，但是针对源码如何分析呢，主要有以下三种：

通过脚本直接分析源码

需要匹配源码的所有语法规则，才能够针对源码进行有效的分析，相当于写一个源码解析器，所以这个方案放弃

通过脚本直接分析AST（抽象语法树）

编译过程中产生的抽象语法树（AST）包含了需要的所有信息，并且clang也提供了命令行，使用该命令行能够直接获取到AST数据。但是clang 命令获取AST数据是以单个类为维度的，类与类之间的关系很难获取到，如继承关系，分类和主类的关系是无法获取的，所以这个方案同样放弃

通过libtooling 和 Swift Compiler自建编译套件分析AST

既然通过clang命令生成的AST产物分析仍然不能满足需求，那么直接介入编译过程，从编译内部生成AST过程中获取需要的信息，最终这个方案被采用。通过libtooling 和 Swift Compiler自建编译套件针对AST进行分析，获取所需要的所有信息。