百度APP iOS端包体积50M优化实践(六)无用方法清理

一、前言

百度APP包体积经过一期优化，如无用资源清理，无用类下线，Xcode编译相关优化，体积已经有了明显的减少。但是优化后APP包体积在iPhone11上仍有350M的空间占用。与此同时百度APP作为百度的旗舰APP，业务迭代非常多且迅速，体积优化和防劣化仍然是当前阶段的一个核心任务。因此百度APP开启了粒度更小，修复风险更高的无用方法清理相关工作。期望通过无用方法清理，有效降低百度APP的包体积，同时删除项目中的无用方法，冗余代码，提高代码的整洁度。

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

• 《百度APP iOS端包体积50M优化实践(一)总览》

• 《百度APP iOS端包体积50M优化实践(二) 图片优化》

• 《百度APP iOS端包体积50M优化实践(三) 资源优化》

• 《百度APP iOS端包体积50M优化实践(四) 代码优化》

• 《百度APP iOS端包体积50M优化实践(五) HEIC图片和无用类优化实践》

二、方案调研

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

1.准确度低

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

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

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

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

6.系统通知等场景

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

三、方案选择

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

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

• 通过脚本直接分析源码

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

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

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

• 通过libtooling 和 Swift Compiler自建编译套件分析AST （Swift相关会在下一篇文章中介绍）

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

四、方案设计

如上所述百度APP最终采用了libtooling 和 Swift Compiler 静态分析方案，那么下面就从原理和实现层面分别进行阐述。

4.1 编译流程简介

4.1.1 Xcode编译总体结构

本节先简单聊一下编译器的结构，编译流程，和静态分析是什么？

△图 4-1

如图4-1 所示 LLVM 采用如上三段结构（Three Phase Design），分别是编译前端（Frontend），编译优化模块，编译器后端（Backend）。那么这三段结构如何对应到Xcode呢，如图4-2所示：

△图 4-2

日常使用Xcode编译时，Xcode调用了两个编译器前端，分别为Clang 和 Swift，通过两个编译器前端构建出通用的编译产物，然后统一经过LLVM后端编译器进行目标文件生成。

通过Xcode的编译log，可以看到针对Objective-C，C， C++ 使用了clang进行编译，针对上述三种不同语言分别用不同编译参数控制：

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

针对swift 文件则采用了swift编译器进行了编译：

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend

针对这两个可执行文件大家可以自行解包Xcode，进行命令行调用，也可以通过其 --help指令查看其支持哪些编译参数或者功能。Xcode 内部编译器实际上是苹果对LLVM 和 Swift 开源版本的定制化版本， 和开源版本有一定的差异性。

4.1.2 Clang 和 Swift 编译流程

如下图所示Clang 和 Swift 前端编译流程，可以看到Swift 编译处理流程多了SIL部分，实际里面还有一个SIL Guaranteed Transformations，当然SIL部分不是重点。从图4-3中可以看到Clang 和 Swift compiler 都会生成AST 且发现AST中包含了我们需要的绝大部分信息，并且Clang 和 Swift Compiler 也暴露了相关获取AST信息的接口，那么剩下的工作只有四点：

1.搭建编译套件工程，确保它正常run起来

2.获取AST，并且根据Objective-C 或者 C，C++的语法特性获取所需要的数据

3.针对获取的数据进行业务分析处理

4.开源版本LLVM和Xcode实际使用版本具有一定差异性，因此部分编译相关内容需要进行相关适配

△图 4-3

4.2 总体方案设计

针对一门程序语言的使用而言，如图4-4所示，包含两个层面，一个层面是声明，另一个层面是调用。声明类，协议，属性，方法，函数等等，同时声明的内容是为了被使用，所以同样声明的内容皆可调用，只不过是内部调用还是公开调用问题。从技术角度而言，声明的所有内容 减去 被调用的声明内容，剩下的就是未被调用的内容，也就是我们需要的 无用方法。当然技术层面的判别最终还是要进行业务判定，因为有的属于基础能力对外提供，至于是否要删除则需要进一步探讨。本文主要探讨技术层面问题。

△图 4-4

从clang源码中可以知道声明和调用分别对应LLVM源码中的基类Decl 和 Expr，整体技术方案如下图 4-5所示，针对无用方法分为处理分为四层：

1.Basic 层：组装编译工具所需的编译参数 + 进行语法规则匹配

2.Transformer层：针对语法规则匹配数据进行转换，转换通用型数据格式

3.通用数据层：通过Transformer层产出的数据进行分类存储，所存储数据包含了代码的所有数据，如针对属性，方法，协议等数据均进行了分类存储

4.业务应用层：针对通用数据层产出的存储数据进行业务分析即可

△图 4-5

4.3 详细方案实现

4.3.1 Objective-C 编译工具搭建

编译工具的呈现形式是一个类似Xcode自带clang的可执行文件，如图4-6 红框所示内容。

/Users/UserName/Documents/XcodeEdition/Xcode14.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

△图 4-6

简单来说通过源码构建的编译工具具有Xcode clang 的部分功能，利用其编译过程中产生的AST对象进行抽象语法树分析，获取到所需要的编程语言的所有语法信息。

4.3.1.1 LLVM 源码构建

编译工具的搭建需要依赖LLVM提供的静态库或动态库，这些库通过自己构建LLVM源码来获得。可以从github获取LLVM源码路径，进入LLVM github界面后有可能会困惑需要构建哪个分支或者tag的代码呢，哪个版本和Xcode使用的clang是对应的？目前Xcode的版本是 14.2 或者 14.3 ，使用命令 clang --version 可以看到Xcode用到的是clang 14，因此构建了release/14.x（没有找到对应关系，推理得出），构建成功后执行构建的clang --version 会发现开源版本clang 和 Xcode的小版本号是不一样的，这是因为Xcode 用的clang 苹果会基于开源代码进行定制，这从Xcode中clang 的依赖库或头文件数量。另外从编译log也可以看到，Xcode clang支持的部分参数，开源clang是不支持的。尽管苹果有一些定制，但是总体影响有限。因此也不必过于在意小版本号是否一致。（初步验证了一下构建最新的release/16.x clang16 也可以）。

△图 4-6

具体构建命令主要分两种，一个是Ninja 构建方式，一个是Xcode方式，需要Xcode调试源码可以选择Xcode模式，但是最终集成到编译工具中的静态库，一定要构建成Release模式，这样工具体积会降到最低，一些警告类异常也会被屏蔽掉。可以参照LLVM 开源库中的start guide 构建过程进行构建，其中涉及的组装命令可以自行拼接也可以用下面的命令：

构建过程
git clone https://github.com/llvm/llvm-project.git
cd llvm-project
mkdir build （这个build文件夹可以自行命名，不固定。针对不同目标可以创建不同文件夹进行不同构建，如 mkdir ninjaBuild 或 mkdir xcodeBuild）
cd build （or cd xcodeBuild）
cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Release ../llvm
cmake --build .

编译Xcode版本，Ninja替换为Xcode即可。

4.3.1.2 工程搭建

LLVM提供了两种工具 libclang 和 libtooling，百度APP采用的是 libtooling，其异同点如下所示：

• libclang：（网络资料，未实测）

  1.提供稳定的 C 接口，具有遍历语法树，获取 Token，代码补全等能力。

  2.接口稳定，clang 版本更新对齐影响不大

  3.libclang 不能获取到 AST 的所有信息

• libtooling：（实测）

  1.提供 C++ 接口，产出的工具不依赖于编译器，可作为独立命令使用

  2.接口不稳定，AST 有升级需要更新相关依赖库

  3.libtooling 可以获得 AST 的所有信息

最终选择 libtooling 形式，核心原因就是 libtooling 可以获取 AST 的所有信息，同时能够不依赖于Xcode 独立运行。工程的搭建本身并不复杂，还是属于API 使用层面，可以直接参照 libtooling的官方文档。

△图 4-6

总体代码流程如图 4-8所示，主要核心点是五个部分：

• 参数解析

• 创建 ClangTool 参照LLVM源码 ClangTooling -> Tooling.h Line309

• 创建 ASTFrontendAction，用于获取 AST 数据，创建 ASTConsumer 和 进行 ASTMatcher 绑定

• 针对 ASTMatcher 匹配项进行各语法规则匹配

• 根据匹配数据进行数据过滤及业务处理

4.3.1.3 数据存储结构设计

数据存储结构采用 json 格式，以下为基础数据格式示例，可以根据实际需求拓展：

"objc(协议or类)@类名(类方法or实例方法)@方法名称":{
"identifier":"objc(协议or类)@类名(类方法or实例方法)@方法名称",
"isInstance":true,
"kind":16,
"location":{
"col":36,
"filename":"文件名称",
"line":147},
"name":"方法名称",
"paramters":"参数",
"returnType":"返回值类型",
"sourceCode":"源码"
}

{"declaration":{"identifier":"objc(协议or类)@类名(类方法or实例方法)@方法名称","isInstance":true,"kind":16,"location":{            "col":列数,"filename":"声明所在类名",            "line":行数        },"name":"方法名称","paramters":"参数名称","returnType":"返回值类型","sourceCode":"源代码"    },"kind":1,"location":{"col":5,"filename":"当前所在文件名","line":15    }}

五、遇到的问题及解决方案

1. 属性调用识别问题

针对 Objective-C 的属性，在编译后对应两个方法 get 和 set 一个是 ivar，调用方有可能只调用 get 或者 set 或者 ivar，所以当只发生一种调用时，就算这个属性被调用，当前属性不属于无用方法。需要在结果中把另外两个方法剥离。

2. 提取方法内容时同样需要对头文件进行提取

方法的实现不一定只在.m 文件中，如C++的头文件是可以进行方法实现的，Objective-C 的.h 文件 通过 inline 实现一些方法，在语法上也是可行的。所以进行方法提取时候关注实现文件，同时也要关注头文件。

3. 针对继承问题

子类实现父类方法等场景，在识别方法时，全部回溯其父类，以其父类名称作为 上文数据结构中 identifier 中类名部分，这样所有的方法都可以和其声明类匹配。

4. 过滤系统方法调用

LLVM提供了接口判断当前方法是否属于系统类。

5. 过滤业务类实现系统方法问题

针对当前类中所有的方法均在当前类 和 回溯其继承链条中的父类， 分别判断其是否属于系统方法，如果属于系统方法则直接过滤掉。

6. 针对协议方法的实现，目前还没有有效手段识别，当前方案是直接过滤掉协议方法，所有协议方法均视为已经调用

在提取方法时，判断当前interface 遵循了哪些协议，遍历协议中的方法，判断其是否为协议方法，是则标记为已调用。

7. 子类实现父类协议问题

回溯当前类的继承链条，在继承链条中判断遍历其所遵循的协议，判断其是否为协议方法。

8. 正常业务实现协议，应该明确标注当前类遵循了协议 如 interface ，但是实际场景中有很多代码在实现协议时并没有标注conformprotocol 这样就对协议方法的判断产生影响，如 6.7方案均失效了

如果组件中少量这种问题，当推动相关方修复此问题，需要明确遵循协议。但是如果有的组件这种场景较多，短期不会修复所有，那么就需要进行临时性适配。针对这类组件收集其当前组件所声明的协议的所有协议方法，用收集的协议方法和当前组件提取的所有声明做差集，存在误伤的可能，但结果是置信的（组件只是一个维度，也可以针对其关联组件进行相关处理，因为有时他实现的组件不一定在当前组件内，这就需要当前组件的依赖关系了）。

无用方法case很多，列举部分供大家参考。

六、总结

这项技术实际上在百度APP早已经应用，因为笔者之前负责百度APP的接口变更审核，组件完整性校验，隐私合规调用链分析等均是依赖于此项技术，无用方法识别只是笔者在做体积优化时想到的其功能的一个延展。当然如上描述的技术问题，细节处理无用方法显然更细腻，case更多。后续文章会针对Swift无用方法分析，接口变更审核，组件完整性校验，隐私合规调用链分析等一一作出介绍。

** ——END——**

参考资料：

[1]libclang：https://clang.llvm.org/doxygen/group__CINDEX.html

[2]libtooling 官方文档：https://clang.llvm.org/docs/LibTooling.html

[3]LLVM源码：https://github.com/llvm/llvm-project

推荐阅读：

基于异常上线场景的实时拦截与问题分发策略

极致优化 SSD 并行读调度

AI文本创作在百度App发文的实践

DeeTune：基于 eBPF 的百度网络框架设计与应用

百度自研高性能ANN检索引擎，开源了