。

但是优化后APP包体积在iPhone11上仍有350M的空间占用。

与此同时百度APP作为百度的旗舰APP#xff0c;业务迭代非常多…一、前言

百度APP包体积经过一期优化如无用资源清理无用类下线Xcode编译相关优化体积已经有了明显的减少。

但是优化后APP包体积在iPhone11上仍有350M的空间占用。

与此同时百度APP作为百度的旗舰APP业务迭代非常多且迅速体积优化和防劣化仍然是当前阶段的一个核心任务。

因此百度APP开启了粒度更小修复风险更高的无用方法清理相关工作。

期望通过无用方法清理有效降低百度APP的包体积同时删除项目中的无用方法冗余代码提高代码的整洁度。

百度APP

针对无用方法清理调研了各家厂商目前已公布的方案主流方案基于Mach-O

1.准确度低

4.针对string反射调用无法识别Target-Action

注册Observer注册方法等无法识别

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

因为目前已公布方案存在如上不足同时因为下线代码敏感度非常高相关业务都很慎重。

因此推动相关无用方法清理识别准确度将非常重要直接关系到相关业务下线无用代码的积极性因此弃用了上述方案。

三、方案选择

针对第二部分方案不足之处进行分析可以看到其准确度低的核心问题是针对产物进行分析拿不到所有需要的信息或者说还没有发现有效的手段去获取所期望获得的信息。

而想要解决上面提到的问题最佳途径就是获取到尽可能多的代码信息。

既然从产物回溯不到所需要的那么就可以考虑从源头也就是源码层面找到我们所需要的详细信息。

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

编译过程中产生的抽象语法树AST包含了需要的所有信息并且clang也提供了命令行使用该命令行能够直接获取到AST数据。

但是clang

命令获取AST数据是以单个类为维度的类与类之间的关系很难获取到如继承关系分类和主类的关系是无法获取的所以这个方案同样放弃

Swift

既然通过clang命令生成的AST产物分析仍然不能满足需求那么直接介入编译过程从编译内部生成AST过程中获取需要的信息最终这个方案被采用。

通过libtooling

Swift

Compiler自建编译套件针对AST进行分析获取所需要的所有信息。

四、方案设计

Design分别是编译前端Frontend编译优化模块编译器后端Backend。

那么这三段结构如何对应到Xcode呢如图4-2所示

4-2

日常使用Xcode编译时Xcode调用了两个编译器前端分别为Clang

Swift通过两个编译器前端构建出通用的编译产物然后统一经过LLVM后端编译器进行目标文件生成。

通过Xcode的编译log可以看到针对Objective-CC

使用了clang进行编译针对上述三种不同语言分别用不同编译参数控制

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

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend针对这两个可执行文件大家可以自行解包Xcode进行命令行调用也可以通过其

Swift

Transformations当然SIL部分不是重点。

从图4-3中可以看到Clang

Swift

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

4-3

针对一门程序语言的使用而言如图4-4所示包含两个层面一个层面是声明另一个层面是调用。

声明类协议属性方法函数等等同时声明的内容是为了被使用所以同样声明的内容皆可调用只不过是内部调用还是公开调用问题。

从技术角度而言声明的所有内容

无用方法。

当然技术层面的判别最终还是要进行业务判定因为有的属于基础能力对外提供至于是否要删除则需要进一步探讨。

本文主要探讨技术层面问题。

4-4

从clang源码中可以知道声明和调用分别对应LLVM源码中的基类Decl

Expr整体技术方案如下图

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

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

4-5

编译工具的呈现形式是一个类似Xcode自带clang的可执行文件如图4-6

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

4-6

的部分功能利用其编译过程中产生的AST对象进行抽象语法树分析获取到所需要的编程语言的所有语法信息。

4.3.1.1

编译工具的搭建需要依赖LLVM提供的静态库或动态库这些库通过自己构建LLVM源码来获得。

可以从github获取LLVM源码路径进入LLVM

github界面后有可能会困惑需要构建哪个分支或者tag的代码呢哪个版本和Xcode使用的clang是对应的目前Xcode的版本是

14.2

14因此构建了release/14.x没有找到对应关系推理得出构建成功后执行构建的clang

--version

clang支持的部分参数开源clang是不支持的。

尽管苹果有一些定制但是总体影响有限。

因此也不必过于在意小版本号是否一致。

初步验证了一下构建最新的release/16.x

clang16

构建方式一个是Xcode方式需要Xcode调试源码可以选择Xcode模式但是最终集成到编译工具中的静态库一定要构建成Release模式这样工具体积会降到最低一些警告类异常也会被屏蔽掉。

可以参照LLVM

guide

构建过程进行构建其中涉及的组装命令可以自行拼接也可以用下面的命令

git

https://github.com/llvm/llvm-project.git

llvm-project

这个build文件夹可以自行命名不固定。

针对不同目标可以创建不同文件夹进行不同构建如

mkdir

identifier:objc(协议or类)类名(类方法or实例方法)方法名称,

isInstance:true,

}{declaration:{identifier:objc(协议or类)类名(类方法or实例方法)方法名称,isInstance:true,kind:16,location:{

line:行数

},name:方法名称,paramters:参数名称,returnType:返回值类型,sourceCode:源代码

},kind:1,location:{col:5,filename:当前所在文件名,line:15

属性调用识别问题

ivar所以当只发生一种调用时就算这个属性被调用当前属性不属于无用方法。

需要在结果中把另外两个方法剥离。

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

实现一些方法在语法上也是可行的。

所以进行方法提取时候关注实现文件同时也要关注头文件。

针对继承问题

子类实现父类方法等场景在识别方法时全部回溯其父类以其父类名称作为

上文数据结构中

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

在提取方法时判断当前interface

遵循了哪些协议遍历协议中的方法判断其是否为协议方法是则标记为已调用。

子类实现父类协议问题

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

interface

但是实际场景中有很多代码在实现协议时并没有标注conformprotocol

如果组件中少量这种问题当推动相关方修复此问题需要明确遵循协议。

但是如果有的组件这种场景较多短期不会修复所有那么就需要进行临时性适配。

针对这类组件收集其当前组件所声明的协议的所有协议方法用收集的协议方法和当前组件提取的所有声明做差集存在误伤的可能但结果是置信的组件只是一个维度也可以针对其关联组件进行相关处理因为有时他实现的组件不一定在当前组件内这就需要当前组件的依赖关系了。

六、总结

这项技术实际上在百度APP早已经应用因为笔者之前负责百度APP的接口变更审核组件完整性校验隐私合规调用链分析等均是依赖于此项技术无用方法识别只是笔者在做体积优化时想到的其功能的一个延展。

当然如上描述的技术问题细节处理无用方法显然更细腻case更多。

后续文章会针对Swift无用方法分析接口变更审核组件完整性校验隐私合规调用链分析等一一作出介绍。

——END——**

[1]libclanghttps://clang.llvm.org/doxygen/group__CINDEX.html

[2]libtooling

官方文档https://clang.llvm.org/docs/LibTooling.html

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

推荐阅读