iOS APP启动优化

App启动过程

iOS应用的启动可以分为pre-main阶段和main（）阶段，其中系统做的事情一次是：

无论对于系统的动弹链接还是对于APP本身的可执行文件而言，它们都算是image（镜像），而每个APP都是以image（镜像）为单位进行加载的

什么是image（镜像)

1. Executable:应用的主要二进制（比如.o文件）
2. Dylib:动态链接库（dynamic library，又称DSO或DLL）
3. Bundle：资源文件，不能被链接的dylib，只能在运行时使用dlopen()加载

pre-main阶段

1. 加载应用的可只能文件（自身APP所有的.o文件的集合）
2. 加载动态链接（dynamic loader，是一个专门用来加载动态链接库的库）
3. dyld递归加载应用所有依赖的动态链接库dylib

main()阶段

1. dyld调用main（）
2. 调用UIApplicationMain（）
3. 调用applicationWillFinishLaunching
4. 调用didFinishLaunchingWithOptions

pre-main阶段的过程和优化项

对于pre-main阶段的耗时优化，我们需要知道dyld加载的过程，苹果在2016年WWDC上介绍，dyld的加载过程主要分为4步：

1、 Load dylibs

分析应用依赖的dylib（xcode7以后.dylib已改为名.tbd），找到其mach-o文件，打开和读取这些文件并验证其有效性，接着会找到代码签名注册到内核，最后对dylib的每一segment调用mmap()
一般情况下，iOS应用会加载100-400个dylibs，其中大部分是系统库，这部分dylib的加载系统已经做了优化。
所以，依赖的dylib越少越好，我们可以做的优化有：

1. 尽量不要使用内嵌的dylib，加载内嵌dylib的性能开销比较大
2. 合并已有的dylib和使用静态库，减少dylib的使用个数
3. 依赖加载dylib，但是要注意dlopen()可能造成一些问题，且实际上依赖加载做的工作更多

Rebase/Bind

在dylib加载的过程中，系统为了安全考虑引用ASLR（address space layout randomization）技术和签名。由于ASLR 的存在，镜像会随机的地址上加载，和之前的指针指向的地址，prefered_address会有一个偏差，dyld需要修正这个偏差，来指向正确的地址。
Rebase在前，Bind在后，Rebase做的是将镜像读入内存，修正镜像内部的指针，性能消耗，主要实在IO，Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU
所以指针数量越少越好，

1. 减少objc类，方法selector、分类category的数量
2. 减少c++虚函数的数量
3. 使用swift struct（内部做了优化，符号数量更少）

objc setup

大部分objc初始化工作已经在rebase/bind 阶段左外，这一步dyld会注册所有生命过的objc，将分类插入到类方法列表中，再坚持每个selection的唯一性
这一步没什么可优化的，rebase/bind阶段优化好了，这一步耗时也会减少

Initializers

dyld开始运行程序的初始化函数，调用每个objc类和分类的+load方法，调用c/c++ 中的构造器，和创建非基本类型的c++静态全局变量。initializers阶段执行完后，dyld开始调用main函数
objc的load函数和C++的静态构造函数采用由低向上的方式执行，来保证每一个执行的方法，都可以找到所有的动态库

优化：

1. 少在类的+load方法中做事情，尽量把这些事情推迟到+initialize
2. 减少构造器个数，在构造函数中少做事情
3. 减少C++静态变量的个数

main（）阶段的优化项

这一阶段的优化主要是减少didFinishLaunchingWithOptions方法里的工作，在didFinishLaunchingWithOptions方法里，我们会创建应用的window，指定其rootViewController，调用window的makeKeyAndVisible方法让其可见。由于业务需要，我们会初始化各个二方/三方库，设置系统UI风格，检查是否需要显示引导页、是否需要登录、是否有新版本等，由于历史原因，这里的代码容易变得比较庞大，启动耗时难以控制。

所以，满足业务需要的前提下，didFinishLaunchingWithOptions在主线程里做的事情越少越好。在这一步，我们可以做的优化有：

1. 梳理各个二方/三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器的viewDidAppear方法里。

2. 梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、注册推送通知等逻辑。

3. 避免复杂/多余的计算。

4. 采用性能更好的API。

5. 避免在首页控制器的viewDidLoad和viewWillAppear做太多事情，这2个方法执行完，首页控制器才能显示，部分可以延迟创建的视图应做延迟创建/懒加载处理。

6. 首页控制器用纯代码方式来构建。

启动耗时的测量

pre-main阶段：

xcode9以后APP提供了一种测试方法，在Xcode中Edit scheme-> Run -> Auguments
设置环境变量：DYLD_PRINT_STATISTICS为1

main()阶段测量

对于main()阶段，主要是测量main()函数开始执行到didFinishLaunchingWithOptions执行结束的耗时，就需要自己插入代码到工程中了。先在main()函数里用变量StartTime记录当前时间

CFAbsoluteTime StartTime;
int main(int argc, char *argv[]){
	StartTime = CFAbsoluteTimeGetCurrent();
}
再在AppDelegate.m文件中用extern声明全局变量StartTime
extern CFAbsoluteTime Startime;
最后在didFinishLaunchingWithOptions里，再获取一下当前时间，与StartTime的差值即是main()阶段运行耗时。
double launchTime = (CFAbsoluteTimeGetCurrent() - StartTime)