抖音研发实践：基于二进制文件重排的解决方案 APP启动速度提升超15%

最后

经过日积月累， 以下是小编归纳整理的深入了解Java虚拟机文档，希望可以帮助大家过关斩将顺利通过面试。
由于整个文档比较全面，内容比较多，篇幅不允许，下面以截图方式展示 。

由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

编译器在生成二进制代码的时候，默认按照链接的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

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

---

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/p的地址范围

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

---

ld

–

Xcode使用的链接器件是ld，ld有一个不常用的参数-order_file，通过man ld可以看到详细文档：

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

可以看到，order_file中的符号会按照顺序排列在对应p的开始，完美的满足了我们的需求。

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. 扫描linkmap的__DATA，__mod_init_func，这个p存储了包含C++静态初始化方法的文件，获得文件号[ 5]。

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 -p=__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。

最后

既已说到spring cloud alibaba，那对于整个微服务架构，如果想要进一步地向上提升自己，到底应该掌握哪些核心技能呢？

就个人而言，对于整个微服务架构，像RPC、Dubbo、Spring Boot、Spring Cloud Alibaba、Docker、kubernetes、Spring Cloud Netflix、Service Mesh等这些都是最最核心的知识，架构师必经之路！下图，是自绘的微服务架构路线体系大纲，如果有还不知道自己该掌握些啥技术的朋友，可根据小编手绘的大纲进行一个参考。

如果觉得图片不够清晰，也可来找小编分享原件的xmind文档！

且除此份微服务体系大纲外，我也有整理与其每个专题核心知识点对应的最强学习笔记：

• 出神入化——SpringCloudAlibaba.pdf

• SpringCloud微服务架构笔记（一）.pdf

• SpringCloud微服务架构笔记（二）.pdf

• SpringCloud微服务架构笔记（三）.pdf

• SpringCloud微服务架构笔记（四）.pdf

• Dubbo框架RPC实现原理.pdf

• Dubbo最新全面深度解读.pdf

• Spring Boot学习教程.pdf

• SpringBoo核心宝典.pdf

• 第一本Docker书-完整版.pdf

• 使用SpringCloud和Docker实战微服务.pdf

• K8S(kubernetes)学习指南.pdf

另外，如果不知道从何下手开始学习呢，小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

使用SpringCloud和Docker实战微服务.pdf

• K8S(kubernetes)学习指南.pdf

[外链图片转存中…(img-ZBY7DQT7-1715545381718)]

另外，如果不知道从何下手开始学习呢，小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！

[外链图片转存中…(img-SEA8uij8-1715545381718)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取