开源｜WBBlades：基于Mach-O文件解析的APP分析工具

原创邓竹立 58技术

开源项目专题系列

（三）

1.开源项目名称：WBBlades

2.github地址：

https://github.com/wuba/WBBlades

3.简介：WBBlades是58同城推出的一款Mach-O文件解析的APP分析工具集，包含以Pod为维度的APP大小分析、无用类检测以及无符合表情景下的崩溃解析。目前WBBlades已经成为58同城客户端在并行研发和多app研发场景下性能检测与质量保证的不可或缺工具。

WBBlades中的工具，基于相同的Mach-O文件解析技术，主要具备以下特点:

Ø App大小分析工具

无需编译链接，可直接对静态库文件进行分析，相对基于linkmap文件的分析更高效和灵活；
实现了模拟链接器的工作流程，对静态库二进制进行数据提取和合并，从而直接输出静态库链接后的大小，模拟后的大小与真实编译链接的大小无显著性差异。

Ø 无用类检测工具

相比已公开的常见方案，支持对类的继承、动态调用、自身类调用、属性及成员变量等情景下的无用类检测，无用类识别精度更高。

Ø 无符号表崩溃解析工具

在无符号表的情况下，通过对二进制文件的解析实现OC代码的日志符号化；
易扩展、易推广，具备可在终端上独立运行能力，可通过脚本调用、传参。

背景介绍

WBBlades工具集基于不同时间点的需求背景，不断探索，产出了相应的工具。

1. 大小分析工具

首先诞生的APP大小分析工具。58同城作为一个平台型的APP，经常需要接入或更新SDK，在接入SDK之前，我们需要明确SDK或更新的大小成本，并与相关方评估成本和收益。在此之前，如果要评估一个SDK的接入大小，我们往往需要编译SDK提供的demo，通过demo的大小来估算SDK的大小，或者通过linkmap来分析SDK的大小。其弊端在于对demo进行编译链接，长此以往是个耗费体力和时间的工作。

我们期望能够根据静态库文件直接分析出静态库链接后的大小，无需编译链接，因此我们仿照模拟链接器的工作流程，对静态库二进制进行数据提取和合并，从而直接输出静态库链接后的大小；此外，我们将工具推广到58同城APP的大小分析，通过对cocoapods所产生的静态库产物进行大小分析，从而实现了58同城APP的大小分布统计，实现了一套方案多处复用。

2. 无用类检测

通过对58同城APP大小分布统计，我们发现58同城的APP代码大小和资源大小比例为：13:5，打破了我们以往认为资源瘦身是最有效的手段的思维惯式。58同城的几个主要业务线代码和资源大小在arm64+3x屏手机上数据对比如下图所示：

图 1业务线代码与资源大小对比

因此，从代码的角度实现瘦身是十分必要的。我们首先调研了业界的常用技术手段，分别是：

脚本分析源代码
基于linkmap+Clang的检测技术
针对framework目标文件优化的技术方案
基于otool+Mach-O的检测技术

前三种技术方案的优缺点由于篇幅限制，在此不做赘述。第四种方案也是业界使用最广泛的方案，通过otool命令提取可执行文件的classlist section 和 classref section。形成classlist和classref的地址差集。但是此方案存在以下问题：

（1）动态调用的类并不会被加入到classref中。

（2）作为基类、作为属性、成员变量不会被加入到classref。

（3）调用了load方法，将自身注册到其他数据中（如RN的module注册）不会被放入到classref中。

（4）类自身内部调用，外界并没有调用，这个类也被放入classref中。

为了解决上述问题，我们通过解析Mach-O文件，从一定程度上解决前3个问题，并通过对反汇编引擎capstone的应用，解决问题（4）。

3. 日志解析工具

58同城在业务开发阶段提供给测试同学的测试包都是通过Jenkins服务打包。随着业务的发展，58同城APP的大小越来越庞大，这就导致测试同学从Jenkins服务器上下载APP的时间较长。为了能够尽可能的减小下载大小，58同城将APP的符号表在打包期间从应用程序中剥离出来形成dSYM文件，保存在打包服务器中。因此测试同学下载的Jenkins包是不包含符号表信息的。由于剥离出来的dSYM文件较大，为了节省服务器空间，dSYM在保留2天后会自动清除。假设有这样一个场景，即测试同学下载了一个测试包，在测试到第三天时发生了不可稳定复现的崩溃，在这种即没有dSYM文件也没有bugly的symbol文件的情况下，如何才能恢复堆栈符号？为此，我们通过解析Mach-O文件，查找崩溃偏移地址位于哪个函数的指令区间范围内，从而实现崩溃日志的符号化。

技术原理

WBBlades工具集的技术原理是一致的，都是基于Mach-O文件的解析。整个项目的核心是基于类是如何在Mach-O文件中存储的。在了解类在Mach-O文件中存储结构后，我们就能通过Mach-O文件获取当前项目中有哪些类，每个类的类名及方法名，以及方法的指令存储范围。如果能清楚准确的知道以上信息，那么项目代码基本上可以说是半透明的了，我们能做的事情也就非常多了。

Mach-O文件可以分为两大段：文本段和数据段。在文本段中主要存储的是字符串及指令，类名、方法名最终都是以字符串的形式存储在文本段中。方法编译后也以指令的形式存储在文本段中，以arm64架构为例，方法编译后，会形成N条4字节的指令存储到__text section中。而在DATA段中，本质上存储的都是地址，这些地址通过直接或多次寻址后会索引到TEXT段。例如（__DATA,__objc_classlist）节，该节数据存储的是所有类的地址（这里所说的地址是指距Mach-O文件起始地址的偏移地址）。arm64的二进制文件中，此地址指向一个class64的结构体。class64结构体起始8字节用于记录类的isa指针，指向类的元类。末尾8字节用于记录data，指向类的class64Info结构体。class64Info存储类名的字符串地址及方法列表地址。class64结构体和class64Info结构体如下：

struct class64 {    unsigned long long isa;//元类在文件中的地址    unsigned long long superClass;    unsigned long long cache;    unsigned long long vtable;    unsigned long long data;//class64Info在文件中的地址};struct class64Info {    unsigned int flags;    unsigned int instanceStart;    unsigned int instanceSize;    unsigned int reserved;    unsigned long long  instanceVarLayout;    unsigned long long  name;//类名在文件中的地址    unsigned long long  baseMethods;//方法列表在文件中的地址    unsigned long long  baseProtocols;    unsigned long long  instanceVariables;    unsigned long long  weakInstanceVariables;    unsigned long long  baseProperties;};

方法列表中存储的是类的实例方法，如果想要查找类方法，那么需要先跳转到元类的class64Info结构体，再查找方法列表。根据上面的寻址后，我们能够找到每个类的所有类方法和实例方法。那么方法在方法列表中是如何存储的呢？首先来看一张简图：

图 2 方法列表

从上图可以看出，在方法列表中，前8字节为method64_list_t结构体，用于说明方法的数量，此后文件中连续存储method64_t结构体，通过method64_t我们可以找到这个方法的名称和函数起始地址。在这里，我们先简单总结下前面的内容：首先根据Mach-O文件的（__DATA,__objc_classlist）节获取所有类的地址，根据地址从Mach-O文件中读取class64结构体，根据class64结构体data成员记录的地址获取class64Info结构体。最后再根据class64Info结构体的baseMethods成员获取到实例方法列表（类方法需要读取元类数据，读取方法相同）。获取到方法列表的起始地址后，即可根据method64_list_t + N*method64_t的方式从文件中读取每个方法的函数地址。获取到的函数地址即为函数距离Mach-O文件的偏移地址，如函数地址为0xAAAA，则说明在Mach-O文件，从0xAAAA字节开始是某函数的地址，此后连续N字节为该函数的函数指令。

图 3 如何在Mach-O文件中获取函数地址

假设函数起始地址为0xAAAA，函数结束地址为0xBBBB，那么当崩溃堆栈显示偏移地址为0xAABB时，则说明崩溃指令位于该函数之类范围内，也就是说此函数发生崩溃。那么问题来了，根据上面所述的方法，可以通过Mach-O文件定位到函数的起始地址，可以通过崩溃日志确定崩溃发生时的指令偏移地址，那么如何才能确定函数的结束地址呢？在iOS系统中，一条arm64的指令为4字节，当函数结束时会执行一条ret指令，当我们从函数起始地址开始扫描，扫描到ret指令时即可认为函数结束。ret指令为无操作码指令，其指令固定为0xC0035FD6。我们从0xAAAA开始读取指令，每次按序获取4字节并读取这4字节的内容，如果内容为0xC0035FD6则认为函数结束。同理，在遍历类的过程中我们也可以获取成员变量、继承关系等信息。

在这里留个悬念，上文中主要是以OC语言作为示例，并且本质上是利用了OC语言的动态特性来实现文件解析的。换言之，如果是C/C++语言，那么上面的过程是无法生效的，那么作为苹果极力推崇的Swift，上面的寻址过程是否能生效呢?感兴趣的同学可以按上文中的过程尝试下。

技术方案对比

1. 大小分析

主流的大小分析方案是通过linkmap文件分析，本方案与linkmap文件分析相比，使用较为简单，无需编译链接即可分析统计。