1. 启动流程

1.1 准备知识

Mach-O

Apple的操作系统的可执行文件格式几乎都是mach-o，mach-o可以大致的分为三部分：

绝大多数mach-o包括以下三个段（支持用户自定义Segment，但是很少使用）

dyld

dyld的全称是dynamic loader，它的作用是加载一个进程所需要的image，它是开源的。

• Virtual Memory

  虚拟内存是在物理内存上建立的一个逻辑地址空间，它向上（应用）提供了一个连续的逻辑地址空间，向下隐藏了物理内存的细节。
  虚拟内存使得逻辑地址可以没有实际的物理地址，也可以让多个逻辑地址对应到一个物理地址。

  虚拟内存被划分为一个个大小相同的Page（64位系统上是16KB），提高管理和读写的效率。 Page又分为只读和读写的Page。

  虚拟内存是建立在物理内存和进程之间的中间层。在iOS上，当内存不足的时候，会尝试释放那些只读的Page，因为只读的Page在下次被访问的时候，可以再从磁盘读取。如果没有可用内存，会通知在后台的App（也就是在这个时候收到了memory warning），如果在这之后仍然没有可用内存，则会杀死在后台的App。

• Page fault
  在应用执行的时候，它被分配的逻辑地址空间都是可以访问的，当应用访问一个逻辑Page，而在对应的物理内存中并不存在的时候，这时候就发生了一次Page fault。当Page fault发生的时候，会中断当前的程序，在物理内存中寻找一个可用的Page，然后从磁盘中读取数据到物理内存，接着继续执行当前程序。

• Dirty Page & Clean Page
  如果一个Page可以从磁盘上重新生成，那么这个Page称为Clean Page
  如果一个Page包含了进程相关信息，那么这个Page称为Dirty Page
  像代码段这种只读的Page就是Clean Page。而像数据段(_DATA)这种读写的Page，当写数据发生的时候，会触发COW(Copy on write)，也就是写时复制，Page会被标记成Dirty，同时会被复制。

1.2 dyld2启动流程

加载动态库

dyld会首先读取mach-o文件的Header和load commands。
接着就知道了这个可执行文件依赖的动态库。例如加载动态库A到内存，接着检查A所依赖的动态库，就这样的递归加载，直到所有的动态库加载完毕。通常一个App所依赖的动态库在100-400个左右，其中大多数都是系统的动态库，它们会被缓存到dyld shared cache，这样读取的效率会很高。

查看mach-o文件所依赖的动态库，可以通过MachOView的图形化界面(展开Load Command就能看到)，也可以通过命令行otool。

Rebase && Bind

有两种主要的技术来保证应用的安全：ASLR和Code Sign。

ASLR的全称是Address space layout randomization，翻译过来就是“地址空间布局随机化”。App被启动的时候，程序会被影射到逻辑的地址空间，这个逻辑的地址空间有一个起始地址，而ASLR技术使得这个起始地址是随机的。如果是固定的，那么黑客很容易就可以由起始地址+偏移量找到函数的地址。

Code Sign相信大多数开发者都知晓，这里要提一点的是，在进行Code sign的时候，加密哈希不是针对于整个文件，而是针对于每一个Page的。这就保证了在dyld进行加载的时候，可以对每一个page进行独立的验证。

mach-o中有很多符号，有指向当前mach-o的，也有指向其他dylib的，比如printf。那么，在运行时，代码如何准确的找到printf的地址呢？

mach-o中采用了PIC技术，全称是Position Independ code。当你的程序要调用printf的时候，会先在__DATA段中建立一个指针指向printf，在通过这个指针实现间接调用。dyld这时候需要做一些fix-up工作，即帮助应用程序找到这些符号的实际地址。主要包括两部分

Rebase 修正内部(指向当前mach-o文件)的指针指向
Bind 修正外部指针指向

之所以需要Rebase，是因为刚刚提到的ASLR使得地址随机化，导致起始地址不固定，另外由于Code Sign，导致不能直接修改Image。Rebase的时候只需要增加对应的偏移量即可。待Rebase的数据都存放在__LINKEDIT中。

Rebase解决了内部的符号引用问题，而外部的符号引用则是由Bind解决。在解决Bind的时候，是根据字符串匹配的方式查找符号表，所以这个过程相对于Rebase来说是略慢的。

Objective-C

Objective C是动态语言，所以在执行main函数之前，需要把类的信息注册到一个全局的Table中。同时，Objective C支持Category，在初始化的时候，也会把Category中的方法注册到对应的类中，同时会唯一Selector，这也是为什么当你的Cagegory实现了类中同名的方法后，类中的方法会被覆盖。

另外，由于iOS开发是基于Cocoa Touch的，所以绝大多数的类起始都是系统类，所以大多数的Runtime初始化起始在Rebase和Bind中已经完成。

Initializers

接下来就是必要的初始化部分了，主要包括几部分：

• load(Swift已弃用，只能使用initialize)
• C/C++静态初始化对象和标记为__attribute__(constructor)的方法

1.3 dyld3启动流程

上文的讲解是dyld2的加载方式。而最新的是dyld3加载方式略有不同：

out-of-process会做如下事情：

• 分析Mach-o Headers
• 分析依赖的动态库
• 查找需要Rebase & Bind之类的符号
• 把上述结果写入缓存

这样，在应用启动的时候，就可以直接从缓存中读取数据，加快加载速度。

1.4 main之后

相对于开发者来说，main才是程序入口。下面是加载流程：

• 1. main函数

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

UIApplicationMain函数有四个参数,最后一个参数是AppDelegate的类名，通常使用模板创建的AppDelegate是AppDelegate，如果我们想要改变它的名字，我们同样需要在这里传入对应的类名。

 UIApplicationMain(int argc, char *argv[], NSString *principalClassName, NSString *delegateClassName);

• 2. 程序完成加载
     我们一般会在这里进行一些初始化配置，例如创建window。

- [AppDelegate application:didFinishLaunchingWithOptions:]

• 3. 创建window窗口
     我们所有的画面最终都会显示在该窗口上，makeKeyAndVisible是window显示的关键。

_window = UIWindow.new;
_window.backgroundColor = [UIColor whiteColor];
[_window makeKeyAndVisible];

• 4. 程序被激活
     最后该方法会被调用，宣布程序处于激活状态。

- [AppDelegate applicationDidBecomeActive:]

2. AppDelegate

AppDelegate类有以下常用的函数，这里是我们与系统进行交互的场所，一般在这里创建视图以及监听部分设备状态。

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    NSLog(@"%s",__func__);
    return YES;
}

- (void)applicationWillResignActive:(UIApplication *)application {
     NSLog(@"%s",__func__);
}

- (void)applicationDidEnterBackground:(UIApplication *)application {
   NSLog(@"%s",__func__);
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
   NSLog(@"%s",__func__);
}

- (void)applicationDidBecomeActive:(UIApplication *)application {
  NSLog(@"%s",__func__);
}

- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application {
     NSLog(@"%s",__func__);
}

- (void)applicationWillTerminate:(UIApplication *)application {
    NSLog(@"%s",__func__);
}

APP状态更改后会收到一些通知。

// 启动APP会调用
-[AppDelegate application:didFinishLaunchingWithOptions:]
-[AppDelegate applicationDidBecomeActive:]

// 点击Home键会调用
-[AppDelegate applicationWillResignActive:]
-[AppDelegate applicationDidEnterBackground:]

// APP从后台返回前台
-[AppDelegate applicationWillEnterForeground:]
-[AppDelegate applicationDidBecomeActive:]

// 收到内存警告
-[AppDelegate applicationDidReceiveMemoryWarning:]

3. 启动优化

如果你刚刚启动过App，这时候App的启动所需要的数据仍然在缓存中，再次启动的时候称为热启动。如果设备刚刚重启，然后启动App，这时候称为冷启动。

启动时间在小于400ms是最佳的，因为从点击图标到显示Launch Screen，到Launch Screen消失这段时间是400ms。启动时间不可以大于20s，否则会被系统杀掉。

以main函数作为分水岭，启动时间其实包括了两部分：main函数之前和main函数到第一个界面的viewDidAppear:。不过一般情况下都是耗时都产生在自己的代码，优先考虑优化main之后的过程。

优化这些初始化的核心思想就是：能延迟初始化的尽量延迟初始化，不能延迟初始化的尽量放到后台初始化。