1. App启动过程
解析Info.plist
加载相关信息，例如如闪屏
沙箱建立、权限检查
Mach-O加载
如果是胖二进制文件，寻找合适当前CPU类别的部分
加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）
定位内部、外部指针引用，例如字符串、函数等
执行声明为__attribute__((constructor))的C函数
加载类扩展（Category）中的方法
C++静态对象加载、调用ObjC的+load函数
程序执行
调用main()
调用UIApplicationMain()
调用applicationWillFinishLaunching
2. 如何测量启动过程耗时
mian()之前
在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到 Run→Environment Variables→+，添加name为DYLD_PRINT_STATISTICSvalue为1的环境变量。
在Xcode运行App时，会在console中得到一个报告。例如，我在WiFi管家中加入以上设置之后，会得到这样一个报告：
main()函数之前总共使用了94.33ms
在94.33ms中，加载动态库用了61.87ms，指针重定位使用了3.09ms，ObjC类初始化使用了10.78ms，各种初始化使用了18.50ms。
在初始化耗费的18.50ms中，用时最多的三个初始化是libSystem.B.dylib、libBacktraceRecording.dylib以及GTFreeWifi。
main()函数之后
从main()函数开始至applicationWillFinishLaunching结束，我们统一称为main()函数之后的部分。
3. 影响启动性能的因素
App启动过程中每一个步骤都会影响启动性能，但是有些部分所消耗的时间少之又少，另外有些部分根本无法避免，考虑到投入产出比，我们只列出我们可以优化的部分：
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方法，现在建议使用 +initialize。任何情况下，能用dispatch_once()来完成的，就尽量不要用到以上的方法。
main()函数之后耗时的影响因素
执行main()函数的耗时
执行applicationWillFinishLaunching的耗时
rootViewController及其childViewController的加载、view及其subviews的加载
applicationWillFinishLaunching的耗时
app结构为TabBarViewController->NavgationViewController->ViewController。启动时的顺序是[TabBarViewController viewDidLoad]->[NavgationViewController viewDidLoad]->[ViewController viewDidLoad]->[AppDelegate application:didFinishLaunchingWithOptions:]。（TabBarViewController下多个NavgationViewController只执行要显示的NavgationViewController和ViewController）。
一般而言，大部分情况下我们都会把界面的初始化过程放在viewDidLoad，但是这个过程会影响消耗启动的时间。特别是在类似TabBarController这种会嵌套childViewController的ViewController的情况，它也会把部分children也初始化，因此各种viewDidLoad会递归的进行。
更好一点的解决方法有点类似facebook，主视图会第一时间加载，但里面的数据和界面都会延后加载，这样用户就会阶段性的获得视觉上的变化，从而在视觉体验上感觉App启动得很快。
4优化的目标
由于每个App的情况有所不同，需要加载的数据量也有所不同，事实上我们无法使用一种统一的标准来衡量不同的App。
应该在400ms内完成main()函数之前的加载
整体过程耗时不能超过20秒，否则系统会kill掉进程，App启动失败
如何定制优化的目标呢？首先，要确定启动性能的界限，例如，在各种App性能的指标中，哪一此属于启动性能的范畴，哪一些则于App的流畅度性能？我认为应该首先把启动过程分为四个部分：
1.main()函数之前
2.main()函数之后至applicationWillFinishLaunching完成
3.App完成所有本地数据的加载并将相应的信息展示给用户
4.App完成所有联网数据的加载并将相应的信息展示给用户
1+2一起决定了我们需要用户等待多久才能出现一个主视图，同时也是技术上可以精确测量的时长，1+2+3决定了用户视觉上的等待出现有用信息所需要的时长，1+2+3+4决定了我们需要多少时间才能让我们需要展示给用户的所有信息全部出现。
5.启动优化
1. 移除不需要用到的动态库.
2. 移除不需要用到的类.
3. 合并功能类似的类和扩展（Category）
由于Category的实现原理，和ObjC的动态绑定有很强的关系，所以实际上类的扩展是比较占用启动时间的。尽量合并一些扩展，会对启动有一定的优化作用。
4. 压缩资源图片
压缩图片为什么能加快启动速度呢？因为启动的时候大大小小的图片加载个十来二十个是很正常的，图片小了，IO操作量就小了，启动当然就会快了。
5. 优化applicationWillFinishLaunching
对于 didFinishLaunchingWithOptions，这里面的初始化是必须执行的，但是我们可以适当的根据功能的不同对应的适当延迟启动的时机。
6. 优化rootViewController加载。
总结
利用DYLD_PRINT_STATISTICS分析main()函数之前的耗时
重新梳理架构，减少动态库、ObjC类的数目，减少Category的数目
定期扫描不再使用的动态库、类、函数，例如每两个迭代一次
用dispatchonce()代替所有的__attribute__((constructor))函数、C++静态对象初始化、ObjC的+load
在设计师可接受的范围内压缩图片的大小，会有意外收获
利用锚点分析applicationWillFinishLaunching的耗时
将不需要马上在applicationWillFinishLaunching执行的代码延后执行
rootViewController的加载，适当将某一级的childViewController或subviews延后加载
如果你的App可能会被后台拉起并冷启动，可考虑不加载rootViewController
不应放过的一些小细节
异步操作并不影响指标，但有可能影响交互体验，例如大量网络请求导致数据拥堵。