App 的启动速度不仅影响我们调试，也直接关系到用户体验。之前有些很久没有打开过的项目，需要花费很长的时间才完成编译；对应的 App 在点击后，许久才出现启动画面。你是否为这些问题苦恼过呢？
这是我观看 WWDC2016 Sessions406 《Optimizing App Start Time》的博客笔记。虽然没有字幕听起来很吃力，但光看 Slide 还是有不少收获的。原文有点长，包括理论是实践两部分，为了方便阅读这里只放出一部分。
Mach-O 文件是如何被加载的
在 mian() 函数执行之前，操作系统为我们做了什么？
exec() -> main()
exec()执行过程：
内核随机分配一段可用的内存给应用程序。但有个规则，即不分配低地址的内存空间，该地址空间大小由处理器的位数决定，情况如下：
-
32位处理器保留 4K
-
64位处理器保留 4G
低地址保留，用于保存空指针、异常错误信息等。
加载动态库
内存分配完成后，处理器运行动态加载器（Dynamic loader）来加载动态依赖库（dylibs）。
加载过程：
-
映射所有的直接依赖库，递归间接调用的依赖库(Map all dependent dylibs,recurse).
-
重建所有的图片(Rebase all images).
-
绑定所有图片(Bind all images).
-
准备代码层面的加载(ObjC prepare images)
-
执行初始化方法(Run initializes).
直接加载：
-
解析所有的动态库
-
找出需要的 mach-O 文件
-
打开并读取文件
-
认证 mach-O 文件
-
登记代码签名
-
为每个 segment 调用
mmap()映射函数
递归加载：
当所有直接依赖库加载完毕后，还存在直接依赖库依赖于其他库的情况。递归加载间接依赖库，一般 App 需要加载 100 到 400 个动态库！其中绝大多数为系统库，苹果已经最优化了系统库的加载。
2. 重建（Rebasing）
将图片资源根据其地址进行加载，重建信息被编码在 LINKEDIT segment 中。重建的过程按照地址顺序执行，所以可以被内核预取。
3. 绑定（Binding）
应用程序对动态库的引用只是字符层(symbol)面上，绑定过程中需要加载器通过函数名来查找，相对于重建这个过程需要更多的计算。
4. ObjC 准备阶段
-
完成重建和绑定后的配置工作
-
登记定义的 ObjC 类
-
更新实例变量对应的内存位置
-
分类的方法被插入到主类
5. 初始化（Initializer）
-
静态分配内存的对象的初始化
-
调用 +load 方法
-
调用相关联的动态库
-
最后，执行 main（）函数
启动优化
对于不同的设备启动速度都不相同，苹果认为完美的启动时间是在 400 毫秒以内。App 的最大允许启动时间为20秒，如果超过这个时间就会被 Killed。
我们可以通过编辑工程的 Schemes 来打印 App 的启动中各项时间花费，从而来分析和优化启动过程。
在 Arguments -> Environment Variables 中加入 DYLY_PRINT_STATISTICS。
设置后，控制台部分项时间花费输出：
1. 加载动态库
加载动态库需要很大的开销，解决方法是尽可能减少引入不必要的动态库，合并现有可操作的动态库，使用静态文件，使用懒加载等
2. 重建和绑定过程
-
减少指针变量的使用
-
减少 Objective-C 类
-
减少 C++ 虚基类的使用(少见)
-
建议使用 Swift 结构体
-
尽可能将属性设置为只读
3. 初始化
-
将
+load函数的操作尽可能在+initialize方法中执行 -
简化 C++ 构造函数
-
不要在初始化方法里面调用
dlopen() -
不要在初始化方法里面创建线程
+initialized 会在任何类加载之前被调用，而 +load 是所在类被加载到系统的时候被调用，这通常比 +initialized 调用的时机要早。在 +load 函数里面做操作会延缓系统的启动时间。
dlopen() 函数用于打开 Bundle 尽可能的延迟读取本地的 Bundld 资源，也有利于加快启动速度。
线程的创建需要很大的开销，不要在 App 启动的过程创建子线程。
参考阅读
1. https://developer.apple.com/videos/play/wwdc2016/406/
2. http://objccn.io/issue-6-3/
3. https://code.facebook.com/posts/1675399786008080/optimizing-facebook-for-ios-start-time/