众所周知，App 的启动速度对用户体验会有一定的影响，因此，为追求用户体验，启动速度的优化必然是App开发过程中，不可或缺的一个环节。那么我们需要先分析App在启动过程中都做了些什么事？
App启动分析
App启动分为 冷启动 和 热启动
- 冷启动：点击 App 启动前，它的进程不在系统里，需要系统新创建一个进程分配给它的情况。这是一次完整的启动过程
- 热启动：App 在冷启动后，用户将App 退到后台，即在App的进程还在系统里的情况下，用户重新启动进入 App 的过程，这个过程做的事情非常少，启动速度非常快。
因此，我们主要针对 App 冷启动进行优化。
一般而言，App 启动时间，指的是从用户点击 App 开始，到用户看到第一个界面之间的时间，总结来说：App 的启动主要包括三个阶段：
- main() 函数执行前
- main() 函数执行后
- 首屏渲染完成后
main() 函数执行前
1、pre-main耗时检测
通过设置环境变量来统计 pre-main 的耗时
选择 Edit Scheme - Arguments - Environment Variables
添加 name DYLD_PRINT_STATISTICS value ： ${DEBUG_ACTIVITY_MODE}
运行Xcode，控制台输出如下：
Total pre-main time: 746.33 milliseconds (100.0%)
dylib loading time: 113.32 milliseconds (15.1%)
rebase/binding time: 4.98 milliseconds (0.6%)
ObjC setup time: 369.16 milliseconds (49.4%)
initializer time: 258.71 milliseconds (34.6%)
slowest intializers :
libSystem.B.dylib : 14.13 milliseconds (1.8%)
libMainThreadChecker.dylib : 153.40 milliseconds (20.5%)
Spirit : 64.53 milliseconds (8.6%)
可见，在 main() 函数执行前，系统主要会做下面几件事情：
dylib loading：加载可执行文件（App 的.o 文件的集合），加载动态链接库rebase/binding：对动态链接库进行 rebase 指针调整和 bind 符号绑定；Objc setup：Objc 运行时的初始化处理，包括 Objc 相关类的注册、category 注册、selector 唯一性检查等；initializer：初始化，包括了执行 +load() 方法、attribute((constructor)) 修饰的函数的调用、创建 C++ 静态全局变量。
相应地，这个阶段对于启动速度优化来说，可以做的事情包括：
减少动态库加载：每个库本身都有依赖关系，苹果公司建议使用更少的动态库，并且建议在使用动态库的数量较多时，尽量将多个动态库进行合并。数量上，苹果公司建议最多使用6 个非系统动态库。- 减少加载启动后不会去使用的类或者方法。
+load()方法里的内容可以放到首屏渲染完成后再执行，或使用+initialize()方法替换掉。因为，在一个 +load() 方法里，进行运行时方法替换操作会带来4 毫秒的消耗。不要小看这 4 毫秒，积少成多，执行 +load() 方法对启动速度的影响会越来越大。- 控制 C++ 全局变量的数量。
当我们做了以上工作，对 pre-main 的时间有所优化之后，如果还想再进行优化，那就需要使用 LLVM 为我们提供的优化方式：二进制重排
二进制重排
背景：APP启动时需要优先执行的函数分散在各个 Page，就会导致多次
Page Fault造成时间的损耗
- Page Fault
APP 进程通过 虚拟内存 和物理内存之间的映射来进行访问（直接访问物理内存是不安全的，虚拟内存地址分配还会涉及到 ASLR），为了提高效率和方便管理，又对虚拟内存进行分页（Page）。当进程访问一个虚拟内存Page而对应的物理内存却不存在时，会触发一次缺页中断（Page Fault），分配物理内存，有需要的话会从磁盘mmap 读入数据。
通过 App Store 渠道分发的 App，Page Fault 还会进行签名验证，所以一次 Page Fault 的耗时比想象的要多：
- 查看 Page Fault
Instruments -> System Trace
File Backed Page In 即为 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 即可，这就是二进制文件重排的核心原理。
LinkMap
LinkMap 是iOS编译过程的中间产物，记录了二进制文件的布局，需要在Xcode的Build Settings里开启Write Link Map File：
Path to Link Map File：
选中编译后的 app，Show In Finder -- 找到build目录 -- 具体路径如下:
Build/Intermediates.noindex/Spirit.build/Debug-iphonesimulator/Spirit.build/Spirit-LinkMap-normal-x86_64.txt
LinkMap 主要包括三大部分：
- Object Files 生成二进制用到的link单元的路径和文件编号
- Sections 记录Mach-O每个Segment/section的地址范围
- Symbols 按顺序记录每个符号的地址范围
ld
Xcode 使用的链接器件是ld，ld有一个不常用的参数 -order_file，order_file 中的符号会按照顺序排列在对应section的开始
Clang 插桩获取启动调用的函数符号
LLVM支持我们在添加编译选项
-fsanitize-coverage=trace-pc-guard的时候，编译时帮我们在函数中插入__sanitizer_cov_trace_pc_guard，当函数调用的时候，会callq__sanitizer_cov_trace_pc_guard利用
__builtin_return_address(0)来获得当前函数返回地址，也就是调用方的地址。通过 dladdr 来将指针解析成 Dl_info 结构体信息，其中dli_sname 就是符号的名称
Build Settings：
在App 的 Target - Build Settings - Other C Flags Debug 添加 -fsanitize-coverage=func,trace-pc-guard
OC - Swift 混编，则在
Other Swift FlagsDebug 添加-sanitize-coverage=func和-sanitize=undefined
Cocoapods 管理代码，用的是静态库的方式的话，那么可以通过hook来修改所有的pod库的编译选项；将以下内容拷贝到你的Podfile文件下面，执行
pod install --no-repo-update
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
macho_type = config.build_settings['MACH_O_TYPE']
#if macho_type == 'staticlib'
# 将依赖的 pod 项目的 Other C Flags 加上 '-fsanitize-coverage=func,trace-pc-guard' 选项
config.build_settings['OTHER_CFLAGS'] ||= ['$(inherited)', '-fsanitize-coverage=func,trace-pc-guard']
config.build_settings['OTHER_SWIFT_FLAGS'] ||= ['$(inherited)', '-fsanitize-coverage=func,trace-pc-guard']
#end
end
end
end
获取 APP 启动调用的函数符号：
- 集成工具：
pod 'ClangTrace', :git => 'https://github.com/huipengo/ClangTrace.git', :configurations => ['Debug']
会在app的沙盒的tmp目录下生成 trace.order 文件
真机获取 order 文件
- Xcoode 选择
Window->Devices And Simulators->Devices -
INSTALLED APPS->ClangTrace->Download Container
Xcode 的连接器 ld 默认忽略
order file中不存在的方法
如果在Other Linker Flags：Debug 中添加-order_file_statistics，会以warning的形式把这些没找到的符号打印在日志里
设置 order file
Xcode 项目选择 TARGETS -> Build Settings -> Order File 填写 order file 路径 $(SRCROOT)/trace.order
PS：配置好 order file 之后，记得清理前面 Build Settings 和 Podfile 中与 Clang 相关的配置
报如下错：
ld: library not found for -lClangTrace
clang: error: linker command failed with exit code 1 (use -v to see invocation)
解决办法：删除如下标记
参考：观看逻辑教育hank老师的启动优化视频整理记录下
抖音研发实践：基于二进制文件重排的解决方案 APP启动速度提升超15%
