优化应用的启动时间（实践篇）

上一篇笔记记录了 session 的理论部分，这里接着记录实践部分。

重述

简要地捋一下应用启动的过程：首先是 dyld 解析得到所需的共享库，然后将库映射到应用的地址空间里面，通过 rebasing 和 binding 修正函数和数据指针的地址，接着注册 ObjC 的类、调用所有的 initializers，最后才是调用 main() 函数。

测量

应用的启动的方式有两种——冷启动和热启动：前者是启动应用时没有任何数据被内核缓存，比如说重启设备后再打开应用就是冷启动；后者在启动时已经有数据被缓存，尽管你能退出这个应用，但是内核还是不一定会清除掉缓存。

要想测量调用 main() 函数之前的所耗费的时间，用我先前写的 TICK TOCK 这两个宏是不可能的。但是在 Xcode 中，可以添加一个环境变量 DYLD_PRINT_STATISTICS：

DYLD_PRINT_STATISTICS.png

那么在启动的时候就能看动态库加载、rebase/binding 等等各部分的时间（Xcode 8，iOS 10 环境下）：

pre_main_comsuming_hot.png pre_main_comsuming_cold.png

提升

Dylib Loading

• 因为系统中的 dylibs 的数据都是经过 pre-calculate 的，在加载的时候会特别的快（不太清楚这一点，找不到相关资料）。而使用内嵌到 App Bundle 的 dylib 的开销很高，而且 App Store 似乎不允许这么做；
• 合并一些动态库以减少数量，异或考虑使用 .a 静态库。而实际中前者几乎是不可行的，合并一些静态库还是可以的；
• 使用 dlopen() 加载 dylib，不过这也只是把一些工作延后而已，而且还可能会有其他的问题。

Rebas/Binding

• 减少 __DATA segment 中的数据指针，类似下面这种：

data_pointer.png

• 减少 ObjC 的元数据（class, categories, selector)；
• 减少 C++ 虚函数；
• Swift 的结构体使用更少需要被修正的指针数据，所以尽量使用 Swift；（现在还不是很了解 Swift 😢）。

ObjC Setup

• 启动时 Objc runtime 要注册 class 和 cacategory，开发的时候注意下别弄冗余的类就行了；
• 接下来更新 Non-fragile ivars 的偏移量，响应地就减少一点实例变量；
• 关于 Selector Uniquing, [objc explain]: Selector uniquing in the dyld shared cache 里面有说到这是 Objective-C 启动开销比较大的一块，方法少一点就快一点。
• 感觉对于 ObjC Setup 的这一块没多少可优化的。

Initializers

Initializers 分为显式的和隐式的，这些都会在启动的时候被调用。我觉得这一块才是实际开发中值得注意的一部分：
对于显式的 initializers：

• 使用 +initialize 而不是 +load。前者在类接收到第一个发送给它的消息之前，后者这是在类被注册的时候。
• 减少使用 __attribute__((constructor)) 修饰的函数，这些函数会在 ObjC Setup 阶段完之后调用。如果只是想执行一次这个函数，用 dispatch_once(), pthread_once(), std::once() 这些 site initializers 代替它会比较好，一是将工作放到了启动之后，二是系统对 dispatch_once() 有优化。另外要写 C++ 跨平台的代码就用 std::once() 吧。

对于隐式的 initializers：

• C++ 中那些 static non-trivial constructors 可以用上面说的 site initializers 代替，或者用 Swift 重写；
• 不要在 initializers 中调用 dlopen()，也不要创建线程；

总结

在调用 main() 函数之前，我觉得能做的、对性能提升比较大的是在 initializers 这一块。类、实例变量等等的数目对启动的影响不大。而在进入 -application:didFinishLaunchingWithOptions: 之后，将一些不是必须在主线程进行的 IO 或计算任务放到低优先级的子线程中执行比较好，这样可以尽快的返回。

话说，site initializers 是什么意思啊，Google 了半天没找着……😢