废话不说，直接上干货！
一、APP启动过程
1.解析Info.plist
- 加载相关信息，例如如闪屏
- 沙箱建立、权限检查
2.Mach-O加载
- 如果是胖二进制文件，寻找合适当前CPU类别的部分
- 加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）
- 定位内部、外部指针引用，例如字符串、函数等
- 执行声明为attribute((constructor))的C函数
- 加载类扩展（Category）中的方法
- C++静态对象加载、调用ObjC的 +load 函数
3.程序执行
- 调用main()
- 调用UIApplicationMain()
- 调用applicationWillFinishLaunching
二、监测启动时间
1.开启时间分析功能
在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到Run → Environment Variables → +，添加name为DYLD_PRINT_STATISTICSvalue为1的环境变量。
运行后会在控制台看到如下内容：
Total pre-main time: 94.33 milliseconds (100.0%)
dylib loading time: 61.87 milliseconds (65.5%)
rebase/binding time: 3.09 milliseconds (3.2%)
ObjC setup time: 10.78 milliseconds (11.4%)
initializer time: 18.50 milliseconds (19.6%)
slowest intializers :
libSystem.B.dylib : 3.59 milliseconds (3.8%)
libBacktraceRecording.dylib : 3.65 milliseconds (3.8%)
MyTest : 7.09 milliseconds (7.5%)
得出结论：
- main()函数之前总共使用了94.33ms
- 在94.33ms中，加载动态库用了61.87ms，指针重定位使用了3.09ms，ObjC类初始化使用了10.78ms，各种初始化使用了18.50ms。
- 在初始化耗费的18.50ms中，用时最多的三个初始化是libSystem.B.dylib、libBacktraceRecording.dylib以及MyTest。
三、影响APP启动性能的因素
1.main()函数之前耗时的影响因素
- 动态库加载越多，启动越慢。
- ObjC类越多，启动越慢
- C的
constructor函数越多，启动越慢 - C++静态对象越多，启动越慢
- ObjC的
+load越多，启动越慢
实验证明，在ObjC类的数目一样多的情况下，需要加载的动态库越多，App启动就越慢。同样的，在动态库一样多的情况下，ObjC的类越多，App的启动也越慢。需要加载的动态库从1个上升到10个的时候，用户几乎感知不到任何分别，但从10个上升到100个的时候就会变得十分明显。同理，100个类和1000个类，可能也很难查察觉得出，但1000个类和10000个类的分别就开始明显起来。
同样的，尽量不要写__attribute__((constructor))的C函数，也尽量不要用到C++的静态对象；至于ObjC的+load方法，似乎大家已经习惯不用它了。任何情况下，能用dispatch_once()来完成的，就尽量不要用到以上的方法。
2.main()函数之后耗时的影响因素
从main()函数开始至didFinishLaunchingWithOptions结束，我们统一称为main()函数之后的部分。
- 执行
main()函数的耗时 - 执行
didFinishLaunchingWithOptions的耗时 -
rootViewController及其childViewController的加载、view及其subviews的加载
3.didFinishLaunchingWithOptions的耗时
其实 didFinishLaunchingWithOptions 方法里我们一般都有以下的逻辑：
- 初始化第三方 SDK
- 配置 APP 运行需要的环境，比如
rootViewController加载 - 自己的一些工具类的初始化
四、制定优化目标
分为四个部分：
-
main()函数之前 -
main()函数之后至didFinishLaunchingWithOptions完成 - App完成所有本地数据的加载并将相应的信息展示给用户
- App完成所有联网数据的加载并将相应的信息展示给用户
五、优化方案
1.main()函数之前的优化
- 移除不需要用到的动态库。
- 移除不需要用到的类。
- 合并功能类似的类和扩展（Category）。
- 压缩资源图片。
- 减少load 方法中执行的代码。
2.main()函数之后至didFinishLaunchingWithOptions完成的优化
这一步主要优化didFinishLaunchingWithOptions方法中的代码和rootViewController加载的优化。
-
didFinishLaunchingWithOptions优化
对于didFinishLaunchingWithOptions，这里面的初始化是必须执行的，但是我们可以适当的根据功能的不同对应的适当延迟启动的时机。对于我们项目，我将初始化分为三个类型：
日志、统计等必须在 APP 一起动就最先配置的事件
项目配置、环境配置、用户信息的初始化 、推送、IM等事件
其他 SDK 和配置事件
对于第一类，由于这类事件的特殊性，所以必须第一时间启动，仍然把它留在 didFinishLaunchingWithOptions 里启动。第二类事件，这些功能在用户进入 APP 主体的之前是必须要加载完的，所以我们可以把它放在第二批，也就是用户已经看到广告页面，再进行广告倒计时的时候再启动。第三类事件，由于不是必须的，所以我们可以放在第一个界面渲染完成以后的 viewDidAppear 方法里，这里完全不会影响到启动时间。
-
rootViewController加载优化
这个只能看具体的逻辑和业务了，尽量把不必要的业务和网络请求等延后加载。
