冷启动和热启动
1.冷启动：APP 的第一次打开，或者被kill掉之后重新打开的启动过程为冷启动。
2.热启动：就是按下home键的时候，app还存在一段时间，这时点击app马上就能恢复到原状态，这种启动我们称为热启动。
应用启动时间，直接影响用户对一款应用的判断和使用体验，冷启动的时间的是我们关注比较多的方向，也是需要注重优化的地方，解析会详细介绍app冷启动的过程和优化策略。
冷启动的耗时计算
t(App总启动时间) = t1(main()之前的加载时间) + t2(main()之后的加载时间)。
main()之前的加载过程
大致的过程如下：
- 加载dyld到App进程
- 加载动态库（包括所依赖的所有动态库）
- Rebase image
- Bind image
- Objc setup
- 初始化
加载动态库
App开始启动后，系统首先加载可执行文件（自身App的所有.o文件的集合），然后使用dyld加载动态链接库。dyld是一个专门用来加载动态链接库的库。
dyld的全称是dynamic loader，它的作用是加载一个进程所需要的image(可执行文件、动态链接库等)，dyld是开源的。
执行从dyld开始，dyld从可执行文件的依赖开始, 递归加载所有的依赖动态链接库。在每个动态库的加载过程中， dyld需要：
- 分析所依赖的动态库
- 找到动态库的mach-o文件
- 打开文件
- 验证文件
- 在系统核心注册文件签名
- 对动态库的每一个segment调用mmap()
动态链接库包括：iOS 中用到的所有系统 framework，加载
OC runtime方法的libobjc，系统级别的libSystem，例如libdispatch(GCD)和libsystem_blocks(Block)。动态链接库有以下好处：代码共用，很多程序都动态链接了这些 lib，但它们在内存和磁盘中只有一份； 易于维护，由于被依赖的 lib 是程序执行时才链接的，所以这些 lib 很容易做更新。
通常的，一个App需要加载100到400个dylibs， 但是其中的系统库被优化，可以很快的加载。 针对这一步骤的优化有：
- 减少非系统库的依赖
- 合并非系统库
- 使用静态资源，比如把代码加入主程序
Rebase && Bind
ASLR(Address space layout randomization)地址空间布局随机化，是一种针对缓冲区溢出的安全保护技术，通过对堆、栈、共享库映射等线性区布局的随机化，增加攻击者预测目的地址的难度，防止攻击者直接定位攻击代码位置，达到阻止溢出攻击的目的。大部分主流的操作系统已经实现了ASLR，Apple在iOS4.3开始导入了ASLR。
由于ASLR的存在，可执行文件和动态链接库在虚拟内存中的加载地址每次启动都不固定，所以需要这2步来修复镜像中的资源指针，来指向正确的地址。 Rebase修复的是指向当前镜像内部的资源指针； 而Bind指向的是镜像外部的资源指针。
- Rebase步骤先进行，需要把镜像读入内存，并以page为单位进行加密验证，保证不会被篡改，所以这一步的瓶颈在IO。
- Bind在其后进行，由于要查询符号表，来指向跨镜像的资源，加上在rebase阶段，镜像已被读入和加密验证，所以这一步的瓶颈在于CPU计算。
优化该阶段的关键在于减少__DATA segment中的指针数量。我们可以优化的点有：
- 减少Objc类数量， 减少selector数量
- 减少C++虚函数数量
- 转而使用swift struct（其实本质上就是为了减少符号的数量）
Objc setup
这一步主要工作是:
- 注册Objc类 (class registration)
- 把category的定义插入方法列表 (category registration)
- 保证每一个selector唯一 (selctor uniquing)
由于之前2步骤的优化，这一步实际上没有什么可做的。
Initializers
以上三步属于静态调整(fix-up)，都是在修改__DATA segment中的内容，而这里则开始动态调整，开始在堆和堆栈中写入内容。 在这里的工作有：
- Objc的+load()函数
- C++的构造函数属性函数 形如attribute((constructor)) void DoSomeInitializationWork()
- 非基本类型的C++静态全局变量的创建(通常是类或结构体)(non-trivial initializer) 比如一个全局静态结构体的构建，如果在构造函数中有繁重的工作，那么会拖慢启动速度。
至此，可执行文件中和动态库所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被 runtime 所管理，再这之后，runtime 的那些方法(动态添加 Class、swizzle 等等)才能生效。
main()之前的加载时间
在不越狱的情况下，以往很难精确的测量在main()函数之前的启动耗时，因而我们也往往容易忽略掉这部分数据。小型App确实不需要太过关注这部分。但如果是大型App（自定义的动态库超过50个、或编译结果二进制文件超过30MB），这部分耗时将会变得突出。所幸，苹果已经在Xcode中加入这部分的支持。
在Xcode的菜单中选择Project→Scheme→Edit Scheme，然后找到 Run → Environment Variables →+，添加name为DYLD_PRINT_STATISTICS，value为1的环境变量。
Total pre-main time: 43.00 milliseconds (100.0%)
dylib loading time: 19.01 milliseconds (44.2%)
rebase/binding time: 1.77 milliseconds (4.1%)
ObjC setup time: 3.98 milliseconds (9.2%)
initializer time: 18.17 milliseconds (42.2%)
slowest intializers :
libSystem.B.dylib : 2.56 milliseconds (5.9%)
libBacktraceRecording.dylib : 3.00 milliseconds (6.9%)
libMainThreadChecker.dylib : 8.26 milliseconds (19.2%)
ModelIO : 1.37 milliseconds (3.1%)
main()前的优化总结：
- 减少不必要的framework，因为动态链接比较耗时
- check framework应当设为optional和required，如果该framework在当前App支持的所有iOS系统版本都存在，那么就设为required，否则就设为optional，因为optional会有些额外的检查
- 合并或者删减一些OC类，关于清理项目中没用到的类，使用工具AppCode代码检查功能，查到当前项目中没有用到的类、方法、变量等：
1. 删减一些无用的静态变量
2. 删减没有被调用到或者已经废弃的方法，方法见：StackOverflow、Apple - 将不必须在+load方法中做的事情延迟到+initialize中
- 尽量不要用C++虚函数(创建虚函数表有开销)
main()调用之后优化
从main()函数开始至applicationWillFinishLaunching结束，我们统一称为main()函数之后的部分，在main()被调用之后，App的主要工作就是初始化必要的服务，显示首页内容等。而我们的优化也是围绕如何能够快速展现首页来开展。 main()函数之后耗时的影响因素：
- 执行main()函数的耗时
- 执行applicationWillFinishLaunching的耗时
- rootViewController及其childViewController的加载、view及其subviews的加载
这个过程的时间统计可以在起止位置埋点获取时间戳，开始位置时main()开始执行的位置，结束位置是applicationWillFinishLaunching开始执行的位置，将两个时间戳相减可以获取main()调用之后的耗时。对于main()函数调用之后我们可以优化的点有：
- 不使用xib，直接使用代码加载首页视图；
- NSUserDefaults实际上是在Library文件夹下会生产一个plist文件，如果文件太大的话一次能读取到内存中可能很耗时，这个影响需要评估，如果耗时很大的话需要拆分(需考虑老版本覆盖安装兼容问题)；
- 每次用NSLog方式打印会隐式的创建一个Calendar，因此需要删减启动时各业务方打的log，或者仅仅针对内测版输出log；
- 梳理应用启动时发送的所有网络请求，是否可以统一在异步线程请求；
以上就是iOS应用启动时间统计和优化方案总结
参考文献：
