APP的启动可以分为2种:
- 冷启动
（Cold Launch）：从零开始启动APP。 - 热启动
（Warm Launch）：APP已经在内存中，在后台存活着，再次点击图标启动APP。
通常所做的启动优化，都是针对冷启动做优化。
通过添加环境变量可以打印出APP的启动时间分析，点击Edit scheme -> Run -> Arguments，给Environment Variables添加一个DYLD_PRINT_STATISTICS，并且把Value设置为1，如下图：
Total pre-main time: 825.00 milliseconds (100.0%) //main函数调用之前总耗时
dylib loading time: 407.70 milliseconds (49.4%)//动态库加载耗时
rebase/binding time: 45.62 milliseconds (5.5%)
ObjC setup time: 100.80 milliseconds (12.2%)//OC结构体准备耗时
initializer time: 270.75 milliseconds (32.8%)//初始化耗时
slowest intializers ://比较慢的加载
libSystem.B.dylib : 7.66 milliseconds (0.9%)
libMainThreadChecker.dylib : 29.10 milliseconds (3.5%)
libglInterpose.dylib : 83.99 milliseconds (10.1%)
libMTLInterpose.dylib : 38.42 milliseconds (4.6%)
xxxxxx : 174.05 milliseconds (21.0%)
如果需要更详细的信息，那就将DYLD_PRINT_STATISTICS改为DYLD_PRINT_STATISTICS_DETAILS并且Value也是设置为1，打印如下：
total time: 1.9 seconds (100.0%)//总耗时
total images loaded: 459 (443 from dyld shared cache)//镜像加载耗时
total segments mapped: 49, into 5926 pages with 984 pages pre-fetched
total images loading time: 1.3 seconds (70.1%)
total load time in ObjC: 96.78 milliseconds (4.8%)//加载objc
total debugger pause time: 973.79 milliseconds (48.8%)
total dtrace DOF registration time: 0.12 milliseconds (0.0%)
total rebase fixups: 479,455
total rebase fixups time: 41.04 milliseconds (2.0%)
total binding fixups: 615,196
total binding fixups time: 192.49 milliseconds (9.6%)
total weak binding fixups time: 4.25 milliseconds (0.2%)
total redo shared cached bindings time: 194.69 milliseconds (9.7%)
total bindings lazily fixed up: 0 of 0
total time in initializers and ObjC +load: 259.27 milliseconds (13.0%)
libSystem.B.dylib : 8.80 milliseconds (0.4%)
libBacktraceRecording.dylib : 10.29 milliseconds (0.5%)
Foundation : 2.01 milliseconds (0.1%)
libMainThreadChecker.dylib : 28.12 milliseconds (1.4%)
libViewDebuggerSupport.dylib : 4.90 milliseconds (0.2%)
libglInterpose.dylib : 76.86 milliseconds (3.8%)
libMTLInterpose.dylib : 39.89 milliseconds (2.0%)
LookinServer : 2.89 milliseconds (0.1%)
xxxxxx : 160.63 milliseconds (8.0%)
total symbol trie searches: 1428216
total symbol table binary searches: 0
total images defining weak symbols: 45
total images using weak symbols: 113
一般总时间在800ms以内都是比较正常的，如果大于800ms就可以优化了。
冷启动的三大阶段
APP的冷启动可以概括为3大阶段：
-
dyld
-
runtime
-
main
-
dyld
dyld（dynamic link editor），它是Apple的动态链接器，可以用来装载Mach-O文件（可执行文件、动态库等）。
启动APP时，dyld动态链接器会装载APP的可执行文件，同时会递归加载所有依赖的动态库。
右键点击XX.app选择Show in Finder，找到XX.app，右键点击XX.app选择显示包内容，可以发现里面有个Unix可执行文件，平时我们写的所有代码都在这里面了，这就是一个Mach-O格式的可执行文件。
但是我们项目开发中也会依赖一些动态库，比如UIKit、Foundation，这些动态库都不是包含在可执行文件里面的，可执行文件里面只有一些依赖信息，比如这个项目依赖哪些动态库，一个动态库也可能依赖另一个动态库。
在dyld阶段，dyld动态链接器会装载可执行文件，以及检查可执行文件依赖哪些动态库，并加载那些动态库，一个动态库也可能依赖另一个动态库，dyld动态链接器就是这样一个一个检查，递归查找，直到装载完所有的动态库到内存中。
当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理。
- runtime
启动APP时，runtime所做的事情有：
1.调用map_images函数进行可执行文件内容的解析和处理
2.在load_images函数中调用call_load_methods，调用所有Class和Category的+load方法
3.进行各种objc结构的初始化（注册Objc类 、初始化类对象等等）
4.调用C++静态初始化器和__attribute__((constructor))修饰的函数
到此为止，可执行文件和动态库中所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被runtime 所管理。
- main
总结一下：
APP的启动由dyld主导，将可执行文件加载到内存，顺便加载所有依赖的动态库
并由runtime负责加载成objc定义的结构
所有初始化工作结束后，dyld就会调用main函数
接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法
冷启动优化
按照不同的阶段：
-
dyld：
减少动态库、合并一些动态库（定期清理不必要的动态库）
减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）
减少C++虚函数数量 (因为一旦有虚函数就要多维护一张虚表，有虚表的话冷启动的时候就要多耗费一点时间)
Swift尽量使用struct(因为加载类的时候也耗费时间) -
runtime：
用+initialize方法和dispatch_once取代所有的__attribute__((constructor))、C++静态构造器、ObjC的+load方法。 -
main：
在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在didFinishLaunchingWithOptions方法中，也就是按需加载。
贴一些启动优化的文档：
iOS开发高手课--App 启动速度怎么做优化与监控？
看到这篇启动优化，让你的App有顺滑无比的启动速度
iOS App冷启动治理：来自美团外卖的实践
我是如何让微博绿洲的启动速度提升30%的
网友评论