原因
一般来说App在早期的时候，启动是不需要去优化的，不会有明显的性能问题。随着时间的推移，项目的迭代，资源的替换，导致整个项目冗余的文件、资源和一些非系统库越来越多，启动时需要做的事，需要启动的内容也越来越多。所以就导致性能越来越差，启动也就越来越慢。
App启动类型
我们一般把App启动分为两种：
冷启动
进程没有在运行，也没有在后台。这个时候点击桌面应用图标，加载并创建应用进程，直到App内容显示完毕。
热启动
这个时候的App是还在运行的，比如你刚刚打开的应用，然后摁下Home键回到了桌面，然后你又点击图标启动了App。
热启动通常情况下都是没什么问题的，启动起来也都比较快。主要优化的目标还是冷启动。我们先了解一个冷启动的过程中，系统都做了什么：
启动时间
- 加载系统
dylib和可执行文件的时间。（pre-main）
- 从
main到applicationWillFinishLaunching结束的时间。（main-启动完成）
启动时间分析
1.开启时间分析功能
在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到 Run → Environment Variables →+，添加name为DYLD_PRINT_STATISTICS value为1的环境变量。
2.解读
main()函数之前总共使用了137.26ms
在137.26ms中，加载动态库用了39.94ms，指针重定位使用了31.29ms，ObjC类初始化使用了8.21ms，各种初始化使用了57.82ms。
在初始化耗费的57.82ms中，用时最多的几个初始化是libSystem.B.dylib、libBacktraceRecording.dylib、libglInterpose.dylib以及libMTLInterpose.dylib。
3.耗时的影响因素
1. main()函数之前耗时的影响因素
- 动态库加载越多，启动越慢。
- ObjC类越多，启动越慢
- C的
constructor函数越多，启动越慢 - C++静态对象越多，启动越慢
- ObjC的
+load越多，启动越慢
2. main()函数之后耗时的影响因素
从main()函数开始至applicationWillFinishLaunching结束，我们统一称为main()函数之后的部分。
- 执行main()函数的耗时
- 执行applicationWillFinishLaunching的耗时
-
rootViewController及其childViewController的加载、view及其subviews的加载
解决策略
我们可以通过开启时间分析功能，首先来查看并判断出在启动时间内，主要消耗时间的流程是在main()函数之前还是main()函数之后。
我们上面也对关于main()函数之前和之后的影响因素进行了分析。既然知道了影响因素，那我们要做的事情就很明了了。
1. 对于main() 之前的耗时因素进行优化：
- 减少非系统库的依赖
- 合并非系统库
- 使用静态资源，比如把代码加入主程序
- 减少Objc类数量， 减少selector数量
- 减少C++虚函数数量
- 转而使用swift struct（其实本质上就是为了减少符号的数量）
- 减少不必要的framework，因为动态链接比较耗时
- 检查 framework应当设为optional和required，如果该framework在当前App支持的所有iOS系统版本都存在，那么就设为required，否则就设为optional，因为optional会有些额外的检查
- 合并或者删减一些OC类，清理项目中没用到的类。
2. 对于main() 之后的耗时因素进行优化：
- 纯代码方式而不是storyboard加载首页UI，storyboard启动起来更加消耗资源。
- 对实现了+load()方法的类进行分析，尽量将load里的代码延后调用。由于我们的项目现在主要语言是swift，苹果在swift里面已经拒绝开发者使用+load方法，更加鼓励我们去使用initializer,所以这一条我们不用太担心。
- 对于viewDidLoad以及viewWillAppear方法中尽量去尝试少做，晚做，不做。
对于 didFinishLaunchingWithOptions，这里面的初始化是必须执行的，但是我们可以适当的根据功能的不同对应的适当延迟启动的时机。对于我们项目，我将初始化分为三个类型：
日志、统计等必须在 APP 一起动就最先配置的事件
项目配置、环境配置、用户信息的初始化 、推送、IM等事件
其他 SDK 和配置事件
对于第一类，由于这类事件的特殊性，所以必须第一时间启动，仍然把它留在 didFinishLaunchingWithOptions 里启动。第二类事件，这些功能在用户进入 APP 主体的之前是必须要加载完的，所以我们可以把它放在第二批，也就是用户已经看到广告页面，再进行广告倒计时的时候再启动。第三类事件，由于不是必须的，所以我们可以放在第一个界面渲染完成以后的 viewDidAppear 方法里，这里完全不会影响到启动时间。
参考文章：
[贝聊科技]一次立竿见影的启动时间优化
