启动优化
热启动与冷启动
当用户按下 home 键，iOS App 不会立刻被 kill，而是存活一段时间，这段时间里用户再打开 App，App 基本上不需要做什么，就能还原到退到后台前的状态。我们把 App 进程还在系统中，无需开启新进程的启动过程称为热启动。
而冷启动则是指 App 不在系统进程中，比如设备重启后，或是手动杀死 App 进程，又或是 App 长时间未打开过，用户再点击启动 App 的过程，这时需要创建一个新进程分配给 App。我们可以将冷启动看作一次完整的 App 启动过程，本文讨论的就是冷启动的优化。
冷启动概要
WWDC 2016 中首次出现了 App 启动优化的话题，其中提到：
• App 启动最佳速度是400ms以内，因为从点击 App 图标启动，然后 Launch Screen 出现再消失的时间就是400ms；
• App 启动最慢不得大于20s，否则进程会被系统杀死；（启动时间最好以 App 所支持的最低配置设备为准。）
冷启动的整个过程是指从用户唤起 App 开始到 AppDelegate 中的 didFinishLaunchingWithOptions 方法执行完毕为止，并以执行 main() 函数的时机为分界点，分为 pre-main 和 main() 两个阶段。
也有一种说法是将整个冷启动阶段以主 UI 框架的 viewDidAppear 函数执行完毕才算结束。这两种说法都可以，前者的界定范围是 App 启动和初始化完毕，后者的界定范围是用户视角的启动完毕，也就是首屏已经被加载出来。
Pre-main阶段优化方案：
• 尽量不使用内嵌 dylib；
• 合并已有内嵌 dylib；
• 检查 framework 的 optional 和 required 设置，如果 framework 在当前的 App 支持的 iOS 系统版本中都存在，就设为 required，因为设为 optional 会有额外的检查导致加载变慢；
• 使用静态库作为代替；（不过静态库会在编译期被打进可执行文件，造成可执行文件体积增大，两者各有利弊，开发者自行权衡。）
• 懒加载 dylib。（但使用 dlopen() 对性能会产生影响，因为 App 启动时是原本是单线程运行，系统会取消加锁，但 dlopen() 开启了多线程，系统不得不加锁，这样不仅会使性能降低，可能还会造成死锁及未知的后果，不是很推荐这种做法。）
Main阶段优化点
- 使用简单的广告页作为过渡，将首页的计算操作及网络请求放在广告页展示时异步进行。
- 涉及活动需变更页面展示时（例如双十一），提前下发数据缓存。
- 首页控制器用纯代码方式来构建，而不是 xib/Storyboard，避免布局转换耗时。
- 避免在主线程进行大量的计算，将与首屏无关的计算内容放在页面展示后进行，缩短 CPU 计算时间。
- 避免使用大图片，减少视图数量及层级，减轻 GPU 的负担。
- 做好网络请求接口优化（DNS 策略等），只请求与首屏相关数据。
- 本地缓存首屏数据，待渲染完成后再去请求新数据。
- 延迟暂时不需要的二方/三方库加载；
- 延迟执行部分业务逻辑和 UI 配置；
- 延迟加载/懒加载部分视图；
- 避免首屏加载时大量的本地/网络数据读取；
- 在 release 包中移除 NSLog 打印；
- 在视觉可接受的范围内，压缩页面中的图片大小；