上一篇笔记记录了 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 了半天没找着……😢
