苹果将启动时间分为两部分：pre-main 的时间和 main() 之后的时间（当然还有我们人为加上去的闪屏显示时间）。
pre-main时间：即调用 main() 函数之前的加载时间，在这段时间里系统会进行加载动态库、注册 Objc 类等系统操作。
main() 之后的时间：即从调用 main( ) 函数到看到第一个页面之间的时间（从 main 函数开始到第一个页面的 - viewDidAppear 被调用）。
优化方案
pre-main 阶段优化
以下为 iPhone 6s Plus 正常启动消耗的pre-main时间（苹果提供了内建的测量方法，在 Xcode 中 Edit scheme -> Run -> Auguments 将环境变量 DYLD_PRINT_STATISTICS 设为 1）：
Total pre-main time: 866.86 milliseconds (100.0%)
dylib loading time: 328.28 milliseconds (37.8%)
rebase/binding time: 49.19 milliseconds (5.6%)
ObjC setup time: 62.85 milliseconds (7.2%)
initializer time: 426.38 milliseconds (49.1%)
slowest intializers :
libSystem.B.dylib : 7.52 milliseconds (0.8%)
libMainThreadChecker.dylib : 37.19 milliseconds (4.2%)
libglInterpose.dylib : 61.17 milliseconds (7.0%)
libMTLInterpose.dylib : 22.23 milliseconds (2.5%)
MyMoney : 392.50 milliseconds (45.2%)
pre-main：
-
dylib loading：
这一阶段 dyld 会分析应用依赖的 dylib ，所以，依赖的 dylib 越少越好。在这一步，我们能做的优化就是检查是否存在不需要的 dylib ，移除不必要的 dylib 。
在项目优化实践中，我们移除了一个没有必要的动态库，并将几个动态库合成为一个动态库，减少动态库数量。
-
rebase/binding：
这一阶段系统主要注册 Objc 类。所以，指针数量越少越好。这一步能做的优化有：
清理项目中无用的类
删减没有被调用到或者已经废弃的方法
-
删减一些无用的静态变量
可通过 AppCode 等工具扫描项目中未使用的代码。
Objc srtup：
这一阶段没有什么特别能优化的地方，如果 rebase/binding 阶段优化的好这步耗时也会很少。-
initializer：
这一阶段，dyld 开始运行程序的初始化函数，调用每个 Objc 类和分类的 +load 方法，调用 C/C++ 中的构造器函数。initializer阶段执行完后，dyld 开始调用 main() 函数。在这一步，检查 +load 方法，尽量把事情推迟到 +initiailize 方法里执行。
在这里我们修改了部分原本代码中直接在 +load 函数初始化逻辑改为在 +initialize 中加载，也就是到使用时才加载。
main()之后
- didFinishLaunchingWithOptions 优化
思路：目前 App 的 didFinishLaunchingWithOptions 方法里执行了几十项业务，有一大部分业务并不是一定要在这里执行的，如支付配置、客服配置、分享配置等。整理该方法里的业务，能延迟加载的就往后推迟，防止其影响启动时间。
通过打点计时器统计各个业务的耗时时间（iPhone 6s Plus）：
各个业务耗时时间
整理 didFinishLaunchingWithOptions ，将业务分级，对于非必须的业务移到首页显示后加载。同时，为了防止以后新加的业务继续往 didFinishLaunchingWithOptions 里扔，可以新建一个类负责启动事件，新加的业务可以往这边添加。
首页渲染优化
- 减少启动期间创建的 UIViewController 数量
通过打符号断点-[UIViewController viewDidLoad]发现 App 启动过程中创建了 12 个 UIViewController（包括闪屏），即在启动过程中创建了 12 个视图控制器，导致首页渲染时间较长。
- 延迟首页耗时操作
App 首页有个侧滑页面及侧滑手势，并且该页面是用 xib 构建的，将该 ViewController 改为代码构建，同时延迟该页面的创建时机，等首页显示后再创建该页面及侧滑手势，这个改动节省了 300-400ms。
- 去除启动时没必要及不合理的操作
项目中使用了自定义的侧滑返回，在每次 push 的时候都会截图，启动的时候自定义导航栏会截取两张多余首页的图片，并且截图用的 API (renderInContext) 性能较差，耗时 800ms 左右，去掉启动截图的操作。
闪屏请求回调里写plist文件的操作放在主线程，导致启动时占用主线程，将文件读写移到子线程操作。
闪屏优化
闪屏在启动的时候也占据了很长的时间，合理的闪屏显示逻辑同样能大大的减少用户的等待时间。
闪屏显示通常都是有一个倒计时，倒计时结束后显示首页。通常倒计时都是使用 NSTimer ，且每秒倒计时结束都需要修改页面上的文字，这些操作必须在主线程做，并且 NSTimer 依赖于主线程的 runloop 状态，主线程阻塞会导致定时器不准。所以为了保证闪屏倒计时的正常显示，首页是在闪屏显示结束后才去创建的。
主线程工作状态如下：
这种情况下用户等待的时间是从“创建闪屏”到“创建、显示首页”结束的时间。
由于闪屏显示时间较长（通常都有几秒），用户在等待闪屏结束的这段时间如果用来创建首页内容肯定是够的，于是就考虑能不能先显示闪屏，在闪屏倒计时的同时去创建、显示首页。
在将首页创建、显示逻辑提前后发现并没有那么简单，就像前面提到的闪屏倒计时使用 NSTimer，NSTimer 又依赖于 runloop，且每秒倒计时结束都必须修改文字，这些操作必须依赖于主线程。只是把首页创建逻辑提前就导致闪屏倒计时不准确，主要表现在第一秒格外的长，因为闪屏显示后主线程就去做创建首页的工作（其实还包括之前被移到首页显示后才启动的服务，也会在这时候一起被主线程处理），必须等首页内容创建完成后 NSTimer 的倒计时才会触发，也必须等首页内容创建完成后才能修改文字。
这时候的主线程工作状态如下：
这时用户等待的时间并没有明显缩短，而且还出现了倒计时不准的 bug 。
出现上面这种情况主要是由两个原因导致的：
使用的定时器依赖于主线程。
修改文字操作依赖于主线程。
第一个问题比较容易解决，不使用 NSTimer，改用 GCD 定时器放在其他线程即可。可是第二个问题是更新 UI ，苹果爸爸明确表示更新 UI 必须放在主线程，一时好像就无解了，但是真的无解吗？
回过头再看一下需求，其实我们要做的就是每秒修改用户看到的文字，并且不依赖于主线程，不依赖于主线程第一时间就想到了动画，iOS 动画是在另一个进程（BackBoard 进程）实现的，主线程阻塞是不会影响 iOS 动画的，利用这一特性就能完美的解决这个问题。我们将要每秒要显示的文字提前生成图片，然后使用生成的图片数组做动画，这样在闪屏显示期间主线程就可以去做其他事情，保证闪屏显示时间的同时减少了用户的等待时间。