IOS开发优化APP启动时长，有的app启动会黑屏优化

App启动大致流程

对于一个可执行文件来说，它的加载过程分为两大部分：

1.pre-main 指的是操作系统开始执行一个可执行文件，并完成进程创建、执行文件加载、动态链接、环境配置

2.main 指的是从加载main函数入口以后，到app delegate完成加载回调的过程

操作系统加载App可执行文件

操作系统加载可执行文件，通过fork(创建一个进程)指令在新的空间内来执行可执行文件，加载依赖的可执行文件(mach-o)文件，定位其内部与外部指针引用，例如字符串与函数，执行声明为attribute((constructor))的C函数，加载扩展(Category)中的方法，C++静态对象加载，调用ObjC的+load函数

基本流程：

App 开始启动后，系统首先加载可执行文件(自身 App 的所有 .o 文件的集合)，然后加载动态链接器 dyld，dyld 是一个专门用来加载动态链接库的库。 执行从 dyld 开始，dyld 从可执行文件的依赖开始，递归加载所有的依赖动态链接库。

动态链接库包括：iOS 中用到的所有系统 framework，加载 OC runtime 方法的 libobjc，系统级别的 libSystem，例如 libdispatch(GCD) 和 libsystem_blocks (Block)。

　ObjC Runtime

dyld的加载过程会初始化Runtime系统，在此阶段，有相当多的优化工作可以做

这过程包括：

1.所有类型的定义和注册，Objective-C的类不是编译器决定的，是运行时动态载入到全局表中的

2.非脆弱的ivars变量抵消更新，修改实例变量的内存地址偏移问题

3.分类替换并添加到方法列表中，将分类中的方法加载到方法列表中

4.确认选择器全局唯一

Initializers 阶段

在Runtime系统加载以后，开始进行初始化

1.Objc的+load()函数

2.C++的构造函数属性函数 形如attribute((constructor)) void DoSomeInitializationWork()

3.非基本类型的C++静态全局变量的创建(通常是类或结构体)(non-trivial initializer) 比如一个全局静态结构体的构建，如果在构造函数中有繁重的工作，那么会拖慢启动速度

pre-main阶段分析

从上面可以得出以下几个结论，影响该阶段启动时间的因素如下：

1.Mach-O可执行文件的加载和内存重新分配规划，对于其segment和section进行虚拟内存的分页管理的调度

2.dyld动态链接内存中的公共镜像，在运行时进行检查共享数据和链接调用

3.Runtime的初始化，包括class注册、category加载、变量对齐等

4.C++静态对象和全局变量的加载

5.ObjeC所有load函数的调用加载

优化措施：

1.减少ObjC的类膨胀问题，清理没有使用的类，合并松散无用的类

2.减少静态变量的声明和初始化的分离，减少静态变量的使用

3.减少符号表的导出

通过设置-exported_symbols_list或-unex生成web appported_symbols_lis来限制符号表的导出，从而减少dyld的工作量

4.去除没有使用的动态库依赖，明确所依赖的frameworks是require还是optional，optional会动态进行额外检查

5.删除没有用的方法

6.减少+load函数的实现，并减少在其中操作的逻辑

7.对某些经常调用的代码进行二进制化，生成静态库，多使用静态库代替动态库，将多个静态库框架，集中制作成静态framework，从而能够减少dyld的链接工作

网址app生成软件main阶段

从上图可以得到，影响main阶段的启动时间因素是：

1.AppDelegate代理的加载生命周期回调

2.Application Window的布局、绘制和加载

3.RootViewController的加载

优化点：

1.压缩和减小启动图片

2.尽量不使用storyboard或者是nib来布局rootViewController

3.在didFinishLaunchingWithOptions阶段，尽可能减少阻塞代码的执行，可以利用多线程进行加载逻辑的处理，注意多线程对主线程同步阻塞可能造成的黑屏问题

4.将非同步需求的初始化逻辑进行异步加载