iOS二进制文件重排,启动速度提高超15%

背景

启动是App给用户的第一印象，对用户体验相当重要。抖音的业务迭代迅速，若是听任无论，启动速度会一点点劣化。为此抖音iOS客户端团队作了大量优化工做，除了传统的修改业务代码方式，咱们还作了些开拓性的探索，发现修改代码在二进制文件的布局能够提升启动性能，方案落地后在抖音上启动速度提升了约15%。

本文从原理出发，介绍了咱们是如何经过静态扫描和运行时trace找到启动时候调用的函数，而后修改编译参数完成二进制文件的从新排布。

原理

Page Fault

进程若是能直接访问物理内存无疑是很不安全的，因此操做系统在物理内存的上又创建了一层虚拟内存。为了提升效率和方便管理，又对虚拟内存和物理内存又进行分页（Page）。当进程访问一个虚拟内存Page而对应的物理内存却不存在时，会触发一次缺页中断（Page Fault），分配物理内存，有须要的话会从磁盘mmap读人数据。

经过App Store渠道分发的App，Page Fault还会进行签名验证，因此一次Page Fault的耗时比想象的要多：

Page Fault

重排

编译器在生成二进制代码的时候，默认按照连接的Object File(.o)顺序写文件，按照Object File内部的函数顺序写函数。

静态库文件.a就是一组.o文件的ar包，能够用ar -t查看.a包含的全部.o。

默认布局

简化问题：假设咱们只有两个page：page1/page2，其中绿色的method1和method3启动时候须要调用，为了执行对应的代码，系统必须进行两个Page Fault。

但若是咱们把method1和method3排布到一块儿，那么只须要一个Page Fault便可，这就是二进制文件重排的核心原理。

重排以后

咱们的经验是优化一个Page Fault，启动速度提高0.6~0.8ms。

核心问题

为了完成重排，有如下几个问题要解决：

• 重排效果怎么样 - 获取启动阶段的page fault次数

• 重排成功了没 - 拿到当前二进制的函数布局

• 如何重排 - 让连接器按照指定顺序生成Mach-O

• 重排的内容 - 获取启动时候用到的函数

做为一个开发者，有一个学习的氛围跟一个交流圈子特别重要，这是一个个人iOS交流群：519832104 无论你是小白仍是大牛欢迎入驻，分享经验，讨论技术，你们一块儿交流学习成长！

另附上一份各好友收集的大厂面试题，须要iOS开发学习资料、面试真题，能够添加iOS开发进阶交流群，进群可自行下载！

System Trace

平常开发中性能分析是用最多的工具无疑是Time Profiler，但Time Profiler是基于采样的，而且只能统计线程实际在运行的时间，而发生Page Fault的时候线程是被blocked，因此咱们须要用一个不经常使用但功能却很强大的工具：System Trace。

选中主线程，在VM Activity中的File Backed Page In次数就是Page Fault次数，而且双击还能按时序看到引发Page Fault的堆栈：

System Trace

signpost

如今咱们在Instrument中已经能拿到某个时间段的Page In次数，那么如何和启动映射起来呢？

咱们的答案是：os_signpost。

os_signpost是iOS 12开始引入的一组API，能够在Instruments绘制一个时间段，代码也很简单：

1os_log_t logger = os_log_create("com.bytedance.tiktok", "performance");
2os_signpost_id_t signPostId = os_signpost_id_make_with_pointer(logger,sign);
3//标记时间段开始
4os_signpost_interval_begin(logger, signPostId, "Launch","%{public}s", "");
5//标记结束
6os_signpost_interval_end(logger, signPostId, "Launch");

一般能够把启动分为四个阶段处理：

启动阶段

有多少个Mach-O，就会有多少个Load和C++静态初始化阶段，用signpost相关API对对应阶段打点，方便跟踪每一个阶段的优化效果。

Linkmap

Linkmap是iOS编译过程的中间产物，记录了二进制文件的布局，须要在Xcode的Build Settings里开启Write Link Map File：

Build Settings

好比如下是一个单页面Demo项目的linkmap。

linkmap

linkmap主要包括三大部分：

• Object Files 生成二进制用到的link单元的路径和文件编号

• Sections 记录Mach-O每一个Segment/section的地址范围

• Symbols 按顺序记录每一个符号的地址范围

ld

Xcode使用的连接器件是ld，ld有一个不经常使用的参数-order_file，经过man ld能够看到详细文档：

Alters the order in which functions and data are laid out. For each section in the output file, any symbol in that section that are specified in the order file file is moved to the start of its section and laid out in the same order as in the order file file.

能够看到，order_file中的符号会按照顺序排列在对应section的开始，完美的知足了咱们的需求。

Xcode的GUI也提供了order_file选项：

order_file

若是order_file中的符号实际不存在会怎么样呢？

ld会忽略这些符号，若是提供了link选项-order_file_statistics，会以warning的形式把这些没找到的符号打印在日志里。

得到符号

还剩下最后一个，也是最核心的一个问题，获取启动时候用到的函数符号。

咱们首先排除了解析Instruments(Time Profiler/System Trace) trace文件方案，由于他们都是基于特定场景采样的，大多数符号获取不到。最后选择了静态扫描+运行时Trace结合的解决方案。

Load

Objective C的符号名是+-[Class_name(category_name) method:name:]，其中+表示类方法，-表示实例方法。

刚刚提到linkmap里记录了全部的符号名，因此只要扫一遍linkmap的__TEXT,__text，正则匹配("^\+\[.*\ load\]$")既能够拿到全部的load方法符号。

C++静态初始化

C++并不像Objective C方法那样，大部分方法调用编译后都是objc_msgSend，也就没有一个入口函数去运行时hook。

可是能够用-finstrument-functions在编译期插桩“hook”，但因为抖音的不少依赖由其余团队提供静态库，这套方案须要修改依赖的构建过程。二进制文件重排在没有业界经验可供参考，不肯定收益的状况下，选择了并不完美但成本最低的静态扫描方案。

1//__mod_init_func
20x100008060    0x00000008  [  5] ltmp7
3//[  5]对应的文件
4[  5] .../Build/Products/Debug-iphoneos/libStaticLibrary.a(StaticLibrary.o)

2. 经过文件号，解压出.o。

1➜  lipo libStaticLibrary.a -thin arm64 -output arm64.a
2➜  ar -x arm64.a StaticLibrary.o

3. 经过.o，得到静态初始化的符号名_demo_constructor。

1➜  objdump -r -section=__mod_init_func StaticLibrary.o
2
3StaticLibrary.o:    file format Mach-O arm64
4
5RELOCATION RECORDS FOR [__mod_init_func]:
60000000000000000 ARM64_RELOC_UNSIGNED _demo_constructor

4. 经过符号名，文件号，在linkmap中找到符号在二进制中的范围：

10x100004A30    0x0000001C  [  5] _demo_constructor

5. 经过起始地址，对代码进行反汇编：

1➜  objdump -d --start-address=0x100004A30 --stop-address=0x100004A4B demo_arm64 
2
3_demo_constructor:
4100004a30:    fd 7b bf a9     stp x29, x30, [sp, #-16]!
5100004a34:    fd 03 00 91     mov x29, sp
6100004a38:    20 0c 80 52     mov w0, #97
7100004a3c:    da 06 00 94     bl  #7016 
8100004a40:    40 0c 80 52     mov w0, #98
9100004a44:    fd 7b c1 a8     ldp x29, x30, [sp], #16
10100004a48:    d7 06 00 14     b   #7004

6. 经过扫描bl指令扫描子程序调用，子程序在二进制的开始地址为：100004a3c +1b68（对应十进制的7016）。

1100004a3c:    da 06 00 94     bl  #7016

7. 经过开始地址，能够找到符号名和结束地址，而后重复5～7，递归的找到全部的子程序调用的函数符号。

小坑

STL里会针对string生成初始化函数，这样会致使多个.o里存在同名的符号，例如：

1__ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1IDnEEPKc

相似这样的重复符号的状况在C++里有不少，因此C/C++符号在order_file里要带着所在的.o信息：

1//order_file.txt
2libDemoLibrary.a(object.o):__GLOBAL__sub_I_demo_file.cpp

局限性

branch系列汇编指令除了bl/b，还有br/blr，即经过寄存器的间接子程序调用，静态扫描没法覆盖到这种状况。

Local符号

在作C++静态初始化扫描的时候，发现扫描出了不少相似l002的符号。通过一番调研，发现是依赖方输出静态库的时候裁剪了local符号。致使__GLOBAL__sub_I_demo_file.cpp 变成了l002。

须要静态库出包的时候保留local符号，CI脚本不要执行strip -x，同时Xcode对应target的Strip Style修改成Debugging symbol：

Strip Style

静态库保留的local符号会在宿主App生成IPA以前裁剪掉，因此不会对最后的IPA包大小有影响。宿主App的Strip Style要选择All Symbols，宿主动态库选择Non-Global Symbols。

Objective C方法

绝大部分Objective C的方法在编译后会走objc_msgSend，因此经过fishhook(https://github.com/facebook/fishhook) hook这一个C函数便可得到Objective C符号。因为objc_msgSend是变长参数，因此hook代码须要用汇编来实现：

1//代码参考InspectiveC
2__attribute__((naked))
3static void hook_Objc_msgSend() {
4    save()
5    __asm volatile ("mov x2, lr\n");
6    __asm volatile ("mov x3, x4\n");
7    call(blr, &before_objc_msgSend)
8    load()
9    call(blr, orig_objc_msgSend)
10    save()
11    call(blr, &after_objc_msgSend)
12    __asm volatile ("mov lr, x0\n");
13    load()
14    ret()
15}

子程序调用时候要保存和恢复参数寄存器，因此save和load分别对x0~x9, q0~q9入栈/出栈。call则经过寄存器来间接调用函数：

1#define save() 
2__asm volatile ( 
3"stp q6, q7, [sp, #-32]!\n"
4...
5
6#define load() 
7__asm volatile ( 
8"ldp x0, x1, [sp], #16\n" 
9...
10
11#define call(b, value) 
12__asm volatile ("stp x8, x9, [sp, #-16]!\n"); 
13__asm volatile ("mov x12, %0\n" :: "r"(value)); 
14__asm volatile ("ldp x8, x9, [sp], #16\n"); 
15__asm volatile (#b " x12\n");

在before_objc_msgSend中用栈保存lr，在after_objc_msgSend恢复lr。因为要生成trace文件，为了下降文件的大小，直接写入的是函数地址，且只有当前可执行文件的Mach-O(app和动态库)代码段才会写入：

iOS中，因为ALSR(https://en.wikipedia.org/wiki/Address_space_layout_randomization)的存在，在写入以前须要先减去偏移量slide：

1IMP imp = (IMP)class_getMethodImplementation(object_getClass(self), _cmd);
2unsigned long imppos = (unsigned long)imp;
3unsigned long addr = immpos - macho_slide

获取一个二进制的__text段地址范围：

1unsigned long size = 0;
2unsigned long start = (unsigned long)getsectiondata(mhp,  "__TEXT", "__text", &size);
3unsigned long end = start + size;

获取到函数地址后，反查linkmap既可找到方法的符号名。

Block

block是一种特殊的单元，block在编译后的函数体是一个C函数，在调用的时候直接经过指针调用，并不走objc_msgSend，因此须要单独hook。

经过Block的源码能够看到block的内存布局以下：

1struct Block_layout {
2    void *isa;
3    int32_t flags; // contains ref count
4    int32_t reserved;
5    void  *invoke;
6    struct Block_descriptor1 *descriptor;
7};
8struct Block_descriptor1 {
9    uintptr_t reserved;
10    uintptr_t size;
11};

其中invoke就是函数的指针，hook思路是将invoke替换为自定义实现，而后在reserved保存为原始实现。

1//参考 https://github.com/youngsoft/YSBlockHook
2if (layout->descriptor != NULL && layout->descriptor->reserved == NULL)
3{
4    if (layout->invoke != (void *)hook_block_envoke)
5    {
6        layout->descriptor->reserved = layout->invoke;
7        layout->invoke = (void *)hook_block_envoke;
8    }
9}

因为block对应的函数签名不同，因此这里仍然采用汇编来实现hook_block_envoke：

1__attribute__((naked))
2static void hook_block_envoke() {
3    save()
4    __asm volatile ("mov x1, lr\n");
5    call(blr, &before_block_hook);
6    __asm volatile ("mov lr, x0\n");
7    load()
8    //调用原始的invoke，即resvered存储的地址
9    __asm volatile ("ldr x12, [x0, #24]\n");
10    __asm volatile ("ldr x12, [x12]\n");
11    __asm volatile ("br x12\n");
12}

在before_block_hook中得到函数地址（一样要减去slide）。

1intptr_t before_block_hook(id block,intptr_t lr)
2{
3    Block_layout * layout = (Block_layout *)block;
4    //layout->descriptor->reserved即block的函数地址
5    return lr;
6}

一样，经过函数地址反查linkmap既可找到block符号。

瓶颈

基于静态扫描+运行时trace的方案仍然存在少许瓶颈：

• initialize hook不到

• 部分block hook不到

• C++经过寄存器的间接函数调用静态扫描不出来

目前的重排方案可以覆盖到80%～90%的符号，将来咱们会尝试编译期插桩等方案来进行100%的符号覆盖，让重排达到最优效果。

总体流程

流程

1. 设置条件触发流程

2. 工程注入Trace动态库，选择release模式编译出.app/linkmap/中间产物

3. 运行一次App到启动结束，Trace动态库会在沙盒生成Trace log

4. 以Trace Log，中间产物和linkmap做为输入，运行脚本解析出order_file

总结

目前，在缺乏业界经验参考的状况下，咱们成功验证了二进制文件重排方案在iOS APP开发中的可行性和稳定性。基于二进制文件重排，咱们在针对抖音的iOS客户端上的优化工做中，得到了约15%的启动速度提高。

抽象来看，APP开发中你们会遇到这样一个通用的问题，即在某些状况下，APP运行须要进行大量的Page Fault，这会影响代码执行速度。而二进制文件重排方案，目前看来是解决这一通用问题比较好的方案。

将来咱们会进行更多的尝试，让二进制文件重排在更多的业务场景落地。

点击此处,当即与iOS大牛交流学习