per-main 阶段
加载类的所有可执行文件
加载 dyld
使用 dyld 递归的加载应用所有依赖的 dylib
具体过程可以看看这个大佬的文章：启动过程及优化，本文内容大多摘自本文。
对于代码的优化
1.减少应用的类、分类、方法。
2.减少C++虚函数的使用（一般也不用，虚函数是和继承相关的）。
3.使用 Swift structs。
4.尽量少的在 + (void)load 方法中做事情。
5.减少构造器的个数，在构造器中少做事情。 6.减少 C+ +静态全局变量。
对于动态库的优化
1.尽量少的使用dylib。
2.尽量不使用内嵌的dylib。
3.合并已有的dylib使用静态库。
4.懒加载dylib。(如果使用此方法加载非系统库是不能上架appstore的,而且此方法在调用时不胜其烦，不推荐)
- 看看这为大佬的文章，懒加载动态库。
main 阶段
dyld 调用 main()
调用 UIApplicationMain()
调用 applicationWillFinishLaunching
调用 didFinishLaunchingWithOptions
这阶段的优化，简言之，减少从 main()、AppDelagate启动函数、首页的 viewDidLoad、首页的 viewWillAppear完毕 这一些列过程中做的事情。现将此阶段可能实现的功能进行总结：
1.创建widown并显示。
2.初始化第二、三方库。
3.设置全局性的东西，例如系统风格。
4.检查是否需要引导页。
5.检查是否需要登录。
6.检查是否需要更新。
优化方案：
1.梳理各个二、三方库，将可以延迟初始化的库延迟加载，例如分享之类的库可以放到首页的 viewDidAppear 中。
2.将可以延后的逻辑延后，例如是否需要登录应该放到需要登录的业务触发时（用户点击评论、购买），是否需要更新、注册推送通知等逻辑也可以延后。
3.在这些过程内避免复杂/多余的计算。
4.在首页的viewDidLoad、viewWillAppear方法中少做太多事情，这俩个方法执行完毕首页才会显示，可将一些操作异步执行或者放到 viewDidAppear 中。
5.部分视图可以延迟创建/懒加载。
6.采用性能更好的API。
7.首页控制器可以使用纯代码来构建。
8.如果应用首页需要显示的内容来自于远端的话，可能用户打开应用之后是白屏，因为数据请求可能还没有回来。这种情况可以将首页数据进行缓存，先显示缓存数据，再获取远端数据刷新页面。另外还可以适当提前首页获取数据的时机，例如在启动时就去获取数据，网络请求是异步的也不会卡住主线程，以此从体验上加快首页的显示速度。
