影响启动性能的因素
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
方法，似乎大家已经习惯不用它了。任何情况下，能用
dispatch_once()
来完成的，就尽量不要用到以上的方法。
main()函数之后耗时的影响因素
- 执行main()函数的耗时
- 执行applicationWillFinishLaunching的耗时
- rootViewController及其childViewController的加载、view及其subviews的加载
applicationWillFinishLaunching的耗时
总结 ：
- 利用DYLD_PRINT_STATISTICS分析main()函数之前的耗时
-
- 重新梳理架构，减少动态库、ObjC类的数目，减少Category的数目
- 定期扫描不再使用的动态库、类、函数，例如每两个迭代一次
- 用dispatchonce()代替所有的__attribute__((constructor))函数、C++静态对象初始化、ObjC的+load
- 在设计师可接受的范围内压缩图片的大小，会有意外收获
- 利用锚点分析applicationWillFinishLaunching的耗时
-
- 将不需要马上在applicationWillFinishLaunching执行的代码延后执行
- rootViewController的加载，适当将某一级的childViewController或subviews延后加载
- 如果你的App可能会被后台拉起并冷启动，可考虑不加载rootViewController
- 不应放过的一些小细节
-
- 异步操作并不影响指标，但有可能影响交互体验，例如大量网络请求导致数据拥堵
- 有时候一些交互上的优化比技术手段效果更明显，视觉上的快决不是冰冷的数据可以解释的，好好和你们的设计师谈谈动画