关于iOS APP启动速度优化的文章很多，大都解释了main()函数调用之前的很多的原理性东西，所以本文对这一部分不会做过多介绍，主要和大家讨论一下我们实际应该做的一些事情。
明确优化方向
在进行优化之前，我们需要明确优化的方向。是什么影响了我们的APP的启动时间？切忌挖空心思的研究优化main()函数调用之前的占用时间，反而忽略了-applicationDidFinishLaunching:withOptions:函数之后那一堆堆臃肿的网络请求以及业务流程。
我们这里只考虑冷启动的优化，因为冷启动包括了热启动，冷启动需要做额外的初始化工作，所以相较而言更慢，导致需要更长的启动等待时间。
所以我们先来看看-applicationDidFinishLaunching:withOptions:函数之后，我们的APP都做了哪些事情。
首先会初始化window，加载tabbar，加载首页controller以及数据，可能我们还有一个loading广告页，还有各种各样的业务需求，网络请求。所以这些都是需要去排查的地方，可以尝试通过添加打印时间戳的方式，来测量每个阶段的耗时情况。我们根据排查结果来明确造成启动缓慢的原因。
我们再简单看看main()函数调用之前都发生了什么。
动态链接器 dyld 开始将程序依赖的动态链接库递归加载进内存（有缓存机制，第二次启动时会快一些），交由ImageLoader读取所有的类、方法等各种符号，加载完毕后dyld通知runtime调用map_images，遍历所有Class，按继承层次依次调用Class的+load方法和其Category的+load方法。待所有初始化工作结束后，dyld调用main()函数。
我们可以通过在 Xcode 中 Edit scheme -> Run -> Auguments 将环境变量 DYLD_PRINT_STATISTICS 设为 1，在控制台看到main()函数之前的启动时间。
分解优化目标 分步达到优化目的
如果有很多业务模块在启动时，都在异步的抢占主线程渲染UI，这就会发生阻塞的现象，如果手机性能较好则看不出差异，如果手机性能较差，会卡的想骂人。
如果启动流程依赖网络请求回来才能继续，那么需要考虑网络极差情况下的启动速度。
如果APP有loading广告页并且对分辨率的要求较高，请尝试做缓存吧。
请尽量精简启动流程的各个阶段和逻辑。
对于tabBarController以及主页面Controller中的viewDidLoad和viewWillAppear方法中尽量少做事情。
如果项目历史悠久，请尽快排查清理项目中未使用到的类库以及Framework。
如果时间允许，请删减合并一些OC类，删减没有用到或者可以不用的静态变量、方法等。
尽量轻量化+load方法中的内容，可延迟到+initialize中。
Reference
https://developer.apple.com/videos/play/wwdc2016/406/
https://mp.weixin.qq.com/s?__biz=MzA3ODg4MDk0Ng==
http://blog.sunnyxx.com/2014/08/30/objc-pre-main/
原文链接：https://ekko.bitcron.com/post/apps/appqi-dong-su-du-you-hua
