iOS独立开发的二进制重排实践｜新瓶装旧酒

这是我参与8月更文挑战的第10天，活动详情查看：8月更文挑战

Hi 👋

• Wechat: RyukieW
• 📦 技术文章归档
• 🐙 Github

个人我的项目	扫雷Elic 无尽天梯	梦见帐本
类型	游戏	财务
AppStore	Elic	Umemi

前言

近两年二进制重排在启动优化上仍是常常被提到的，虽然听着很厉害的样子，但实际上是个老概念了。

继上一次「iOS官方瘦身方案ODR（二）：换肤系统改造｜践行 On-Demand Resources」后，再次拿本身我的项目小白鼠「梦见帐本」来实践一下。

1、 为何要二进制重排呢？

1.1 虚拟内存和分页

咱们知道，现代操做系统通常都采用虚拟内存管理机制，用分段（segment）和分页（page）管理虚拟内存。

分段便是区分数据段、代码段、堆内存、栈内存等，不一样的段数据的读写权限不同。以 iOS 为例，代码段（_TEXT）是可读可执行但不能写的。

分页则是为了方便高效的进行内存管理。因为采用了虚拟内存管理机制，就要创建虚拟内存到物理内存的映射表，称为页表。若是在设计上将每个字节的虚拟内存和物理内存一一对应，这样粒度足够细，虽然不会产生内存浪费（内存碎片），但须要维护巨大的页表；但若是一页数据过大，好比5M，那么存储1个字节就要分配一个5M的页面，是很是大的浪费。内存页过大或太小都有弊端，目前大多数系统的页大小都设置在了4096字节，经过页号和页内偏移进行寻址。可使用pagesize命令查看当前系统的页大小。

1.2 Page Fault

使用虚拟内存的目的之一是解决物理内存资源紧张的问题。dyld 在加载二进制时，会使用 mmap 将 Mach-O 文件映射到虚拟内存地址空间中，此时并不会占用过多的物理内存。当读取一个虚拟内存地址时，若是该地址在物理内存中并不存在，会触发一次缺页中断（Page Fault），这个时候才将文件内容读取至物理内存中。

缺页中断发生时会执行下面的操做：

分配内存

由内存管理单元找到空闲内存并分配。

IO操做

从磁盘中读文件并写入内存中。

解密验签

若是是从 AppStore 上下载的 APP，iOS 系统还有对每一页（仅针对 _TEXT 段的数据，_DATA 段数据不须要）进行解密和签名验证。

以上操做在每一次 Page Fault 时都会发生，若是在启动 APP 时，存在大量的 Page Fault 状况，势必影响启动速度。

2、 什么是二进制重排

频繁的发生 Page Fault 会影响启动速度，那么，是否能够干预 Mach-O 的 _TEXT 段函数的映射顺序，将 APP 启动时须要用到的方法集中在一页或几页呢？答案是确定的，二进制重排的原理就是字面上的理解，经过减小 Page Fault 发生次数，减小启动耗时。

理论上 Page Fault 确实会影响启动速度，但影响的大小要区分看待。通常来讲，是要在常规的优化手段都作完以后，再考虑进行二进制重排。且对于小型APP来讲，若是自己启动时执行的方法并不算多，那么二进制重排的意义就不是很大。

对于 iOS 13 系统来讲，因为启用了 dyld3，Page Fault发生时已经不须要执行解密验签（提早生成了 lauch closure 文件），对性能的影响就更小了。

3、 System Trace 查看耗时

建议重装应用

• 选中指定的设备，选中安装的 App 点击 [*] 按钮，应用第一个页面（非启动页）显示后中止。
• 找到本身的项目
• 选中 Main Thread
• 选中 Virtual Memory

File Backed Page In 次数就是 Page Fault 的次数。「梦见帐本」耗时 341ms。

点击这里的小箭头，能够看到调用堆栈

固然，咱们不可能人工的来整理这些。那么有什么办法能够获取到全部调用呢？

4、 获取启动时调用的全部方法

现有方案对比

• hook objc_msgSend
  • 只能捕获基于 objc 的方法调用
• 静态扫描 MachO 文件里的符号和函数数据 + 解析 Trace 文件
  • 容易获取 +load、C++构造函数
  • initialize hook不到
  • 部分block hook不到
  • C++经过寄存器的间接函数调用静态扫描不出来
• 编译器插桩 Clang
  • 能够拿到 OC、 Swift、 C、 block 所有调用

5、 Clang 插桩

5.1 基于 Clang SanitizerCoverage 的方案

SanitizerCoverage 是 Clang 内置的一个代码覆盖工具。它把一系列以 __sanitizer_cov_trace_pc_ 为前缀的函数调用插入到用户定义的函数里，借此实现了全局 AOP。其覆盖了/ Swift/Objective-C/C/C++ 等语言，Method/Function/Block 全支持。

开启 SanitizerCoverage 的方法是：

• 在 build settings 里的 Other C Flags 中添加 -fsanitize-coverage=func,trace-pc-guard
• 若是含有 Swift 代码的话
  • 须要在 Other Swift Flags 中加入 -sanitize-coverage=func 和 -sanitize=undefined
• 全部连接到 App 中的二进制都须要开启 SanitizerCoverage，这样才能彻底覆盖到全部调用
  • 例如Pod库，就要在Target里设置

在SanitizerCoverage中能够看到 LLVM 官方对 SanitizerCoverage 的详细介绍，包含了示例代码。

5.2 获取 order 文件

这里直接使用了AppOrderFiles来进行获取。就不贴代码了，源码也很少，有兴趣能够自行查看。

在 AppDelegate 中调用：

// 我是放在 `func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool` 最后调用的
AppOrderFiles { path in
    if let path = path { print("AppOrderFiles: \(path)") }
}
复制代码

安装运行一次后，从 Xcode 获取应用的设备的 .xcappdata 文件中按照路径，取到 app.order 文件。

5.3 设置 order 文件路径

不必加入 Bundle

5.4 验证顺序 LinkMap

开启 LinkMap 文件输出

编译获取 LinkMap

先在项目的 Product 文件夹中找到 .app 的目录

再按如图所示路径找到 linkmap 文件

对比 linkmap 和 order 文件

搜索 Address Size File Name

发现顺序是同样的了

5.5 System Trace 检查效果

只有 141ms 了，优化了一大半。具体效果根据不一样项目会有所不一样。

参考

• App 二进制文件重排已经被玩坏了
• SanitizerCoverage
• AppOrderFiles
• Improving App Performance with Order Files
• 抖音研发实践：基于二进制文件重排的解决方案 APP启动速度提高超15%
• iOS启动优化之二进制重排