iOS 性能优化实战篇----app启动优化
简述：所谓app启动是指到我们打开app到我们看到app中的第一个页面的过程。整个过程可以分成两个部分完成：
（一）、pre-main 时间。(可通过系统内建的测量方法测试)
配置环境变量： Xcode 中 Product -> Edit scheme -> Run -> Auguments ->Environment Variables -> 添加DYLD_PRINT_STATISTICS 设为 1即可。
（二）、 main 函数到第一个界面渲染完成。
因为 APP 的入口在 main 函数 ，在 main 函数之后我们的代码才会执行。
详细过程如下：
一、第一阶段 pre-main加载过程
Total pre-main time: 890.12 milliseconds (100.0%)
dylib loading time: 377.85 milliseconds (42.4%)
rebase/binding time: 414.93 milliseconds (46.6%)
ObjC setup time: 70.57 milliseconds (7.9%)
initializer time: 26.55 milliseconds (2.9%)
slowest intializers :
libSystem.B.dylib : 2.95 milliseconds (0.3%)
具体如下：
- 加载dyld到App进程-> 找到dyld对应的Mach-O需要添加载动态库（包括所依赖的所有动态库）（dynamic loader）
- Rebase/Bind
- 初始化Objective C Runtime
- 其它的初始化代码
1、可执行文件(加载dylib)
(1).加载dylib
(2).分析每个dylib（大部分是iOS系统的），找到其Mach-O文件，
(3).打开并读取验证有效性，找到代码签名注册到内核，
(4).最后对dylib的每个segment调用mmap()。
2、动态库绑定rebase/bind
(1).dylib加载完成之后，它们处于相互独立的状态，需要绑定起来。
(2).在dylib的加载过程中，系统为了安全考虑，引入了ASLR（Address Space Layout Randomization）技术和代码签名。
(3).由于ASLR的存在，镜像（Image，包括可执行文件、dylib和bundle）会在随机的地址上加载，和之前指针指向的地址（preferred_address）会有一个偏差（slide），dyld需要修正这个偏差，来指向正确的地址。
(4.)Rebase在前，Bind在后，Rebase做的是将镜像读入内存，修正镜像内部的指针，性能消耗主要在IO。
(5.)Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。
3、添加运行时（OC setup）
(1).OC的runtime需要维护一张类名与类的方法列表的全局表。
dyld做了如下操作：
(2).对所有声明过的OC类，将其注册到这个全局表中（class registration）
(3).将category的方法插入到类的方法列表中（category registration）
(4).检查每个selector的唯一性（selector uniquing）
第一阶段优化方案有：
1. 移除不需要用到的动态库
2. 移除不需要用到的类
3. 合并功能类似的类和扩展
4. 尽量避免在+load方法里执行的操作，可以推迟到+initialize方法中。
二、程序启动第二阶段过程
程序启动的第二个阶段为：main 函数到第一个界面渲染完成。
main()阶段
2.1. dyld调用main()
2.2. 调用UIApplicationMain()
2.3. 调用applicationWillFinishLaunching
2.4. 调用didFinishLaunchingWithOptions(这阶段主要执行都是我们自己实现的代码，主要是一些配置、版本检查、推送等业务代码，耗时可以自己控制)。
相信小伙伴们对这一阶段加载过程都有一定了解，肯定有自己的优化方案。所以这里只是展示我个人对这阶段的优化建议。
优化方案：
1、梳理各个三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器的viewDidAppear方法里。
2、延迟执行部分业务功能。如检查新版本、注册推送通知、第三方注册、定位等
3、避免复杂/多余的计算。
4、避免在首页控制器的viewDidLoad和viewWillAppear做太多事情，这2个方法执行完，首页控制器才能显示，部分可以延迟创建的视图应做延迟创建/懒加载处理。
5、采用性能更好的API。
6、首页控制器用纯代码方式来构建。
