app启动速度通常关乎用户对app的总体评价，在这方面也有很多优秀关于优化方面的文章，不过这类文章更多地着墨于具体的优化方案，对原理的介绍往往并不详实，所以对于想了解个中原理进而深入学习系统机制的研发会有些美中不足的感觉。
本文根据wwdc 2012 iOS App Performance: Responsiveness，wwdc 2016 Optimizing App Startup Time及wwdc 2017 app start time:Past,Present and Future深入探讨启动原理与优化策略

应用启动概论

伴随app启动的过程会出现app应用界面放大出现的效果，iPhone及iPad上这个放大动画分别为400ms与500ms，如果动画结束时app已经启动完成，那么用户看起来就像app在点击了图标之后马上启动了一样，这样的启动速度自然是最佳的。

watchdog

watchdog机制会在app发生超时的场景下强行中止其运行，由下表可知它对启动场景的最大容忍时间为20s（xcode在debug期间会禁用watchdog）

启动时间的衡量

watchdog判定启动结束的时间点是第一个CATransaction的结束，这个点意味着UI在CPU中第一次布局和绘制的结束，其标志性的api调用为[UIApplication _reportAppLaunchFinished]（iOS6及之前版本，是此内部api调用为启动结束标志，但iOS8以后已经无法断点到这个api，现在做启动优化判定启动结束的一般的做法是rootViewController的viewDidAppear调用时间点）
而对于特定功能的app比如相机应用来说，用户所感知到的启动终结应当是快门达到可点按状态所需要的时间，也就是说如果在watchdog超时间内完成界面启动而功能却并未完成初始化，仍然算做启动未完成，只是已经没有在启动过程被系统强行终止的危险而已。

启动过程

链接与加载阶段优化策略

1.精简依赖的framework(每个OC库在加载阶段都会有些额外的工作要做，比如类的hash表需要在加载阶段将各类添加进去)
2.不要将require的framework标记为optional，因为optional需要更多的检查消耗
3.避免静态的初始化过程：
全局C++对象的创建:

    static std::map<int, int>  GlobalMap = {{1,2},{3,4}};

在main之前的load阶段执行的代码:

+ (void)load{  //do any stuff }
__attribute__((constructor)) void doInitializationStuff() {}

将尽可能多的工作放到运行期去做，比如+(void)initialize{}

UIKit 初始化优化策略

涉及的api

UIApplicationInitialize(iOS7以后应该已经没有了)
UIApplicationInstantiateSingleton
-[UIApplication _createStatusBarWithRequestedStyle: ...]
-[UIApplication _loadMainNibFileName:bundle:]

1 精简main nib的大小，更好的优化自然是用代码创建UI
2 不要在userdefault中存太多数据，因为userdefaults是作为property文件存储的，整个property list会一次性反序列化，所以不要存大块的数据，比如

NSUserDefaults *ud = [NSUserDefaults standardUserDefaults];
NSData* data = UIImagePNGRepresentation(image);
[ud setObject: data forKey: @"image"];

Application 回调 优化策略

此阶段过程如下：

 回调application: willFinishLaunchingWithOptions:
 恢复application 状态
 回调application: didFinishLaunchingWithOptions:

首次Core Animation Transaction

提交的重要阶段：

• 准备阶段：解码图片
• layout: 计算所有layer的大小(-layoutSubviews)
• 绘制: -drawRect:
  提交阶段的优化策略很明确，即尽可能精简root viewController首次出现时的view层次复杂度及图片素材的总量，同时不要做太复杂的drawRect操作

app启动原理及优化实践

这部分根据wwdc2016 session406, 主要内容为启动原理及优化实践

Mach-O 和虚存 掠影

Mach-O文件类型：

Executable - 应用主二进制文件
Dylib - 动态链接库（类似于其它平台的DSO和DLL）
Bundle - 无法链接的Dylib，只能通过dlopen(), 比如插件

Image - Executable, Dylib 或者 Bundle
Framework - 包含所属资源与头文件目录的Dylib
Mach-O文件又划分为段segment, 比如__TEXT, __DATA, __LINKEDIT, 每个段大小均为pagesize的整数倍，在arm64 pagesize为16KB，其它架构为4KB，段又划分为sections，section之间不重叠

Mach-O Universal Files
构建同时支持32位与64位架构时会将两个架构的Mach-O文件合并为UniversalFile

fat header

支持的架构会列举在fat header中，这个header也是一个page size

虚存
虚存是一种间接管理内存的方式，是为了方便多进程使用物理内存，常见特性比如：当访问的虚存对应的页不在内存中时发生的页错误引发加载，同一内存页映射到多进程中的内存共享模式，文件映射页mmap()与lazy reading特性（读到特定地址时才引发页错误引发加载），copy on write（COW,多进程共享数据页，直到对其进行修改时才引发内存将页复制到新内存页并将进程映射的页指向新内存页）
虚存的这些特性应用在__TEXT段极为合适，COW对于__DATA段是很好的优化，这也引出了另一个概念，即脏数据页和干净数据页：脏数据页是包含特定进程信息的页，而干净页是内核可以重新从disk中读取的数据页，所以脏数据页比干净数据页会带来更多消耗。
页权限属性：rwx(代码段设置为只读 r，数据段 rw)

加载dylib的时候，会将其文件映射到内存中，由于大部分全局变量都初始化为0，所以静态优化把它们都放在后面，以不占用空间，而且通过VM特性在首次读取时将其填充为0，dyld的第一件事情是读取Mach-O header，即第一页，会引发页错误进而进行页加载，它会发现此页进行了文件映射并加载文件首页到物理内存。然后dyld开始读mach header，接着Mach header说在__LINKEDIT段中有些信息需要读下，于是dyld开始读最下面那段，同样引发页错误及加载，然后LINKEDIT告诉dyld需要对DATA段做一些修正才能让dylib真正可运行。dyld于是开始入数据段写一些数据，这时候COW发生，数据页变脏。而如果此时另一个进程需要这个dylib，那么TEXT段和LINKEDIT段只需要复用已经在物理内存页中的这两个段即可，操作系统只需要将对应的内存页映射到新进程的虚存中即可。而数据段如果仍在内存中，也可以类似地映射，否则需要再次读取disk，这算是动态库加载的一项优化。而LINKEDIT段只有在dyld修正DATA段的时候才有用，此后其内存页即可回收做它用。

Dylib加载

有两件想提及的事情是安全是如何影响dyld的，而正是这两件事关安全的事情影响了dyld。
一个是ASLR(address space layout randomization)，用于随机化加载地址的常用技术。
另一个是code sign，构建时每页Mach-O文件都会生成各自的加密hash，均存储在LINKEDIT中，于是每页均可以验证其是否被更动过手脚。

EXEC

exec是一个系统调用，会使用指定的新程序替换当前进程，内核会将整个进程空间抹掉并将你指定的可执行文件映射进来，由于ASLR的存在，映射到的是一个随机的地址，并且从这个地址到0的整个区域都会标记为不可读不可写不可执行。在32位进程中，这个区域大小为4KB，在64位进程最少为4GB。它会用来捕获空指针引用及指针截断错误，因为块虚存未映射任何实际物理地址，所以访问会引发异常。
多年以前EXEC很轻松，因为只需要将程序映射到进程，再设置PC就可以开始执行了，但随着动态链接库的发明，出现了helper程序来帮忙加载动态链接库，apple平台上这个程序叫做dyld。内核在映射可执行文件到进程之后，会映射dyld到进程另一个随机地址，然后将PC设置进dyld中，并让其完成进程的启动。

查看image中需fix-up的指针信息的命令:

xcrun dyldinfo -rebase -bind -lazy_bind myapp.app/myapp

上述所有工作完成之后，dyld会调用可执行文件中的main()

提升启动速度实用策略

首先最好的启动时间是比启动动画更快，前述启动概论有提及，400ms最好
在scheme中添加环境变量 DYLD_PRINT_STATISTICS 1 后，在device log中会输出main之前所有执行过程的耗时统计

抖音代码段重排启动优化方案