前言
最近在做少量App品质提升，启动时间优化是其中很重要的一项，本文围绕启动时间做一个深入理解。
正文
什么是启动时间？
启动时间可以了解为从客户点击App的Icon到客户看到App真正画面并且可以进行交互的时间。这段时间还可以为两部分：iOS系统启动App的时间 和 App初始化应用内部逻辑和界面的时间。
一、App产生
在探索iOS系统如何解决App启动之前，我们需要先理解下一个App是如何产生的：
1、编译：我们打开一个xcode工程，会看到若干个.h/.m组成；当我们进行编译时，编译器会分别对每个.m文件进行编译，得到对应的.o文件；
2、链接：将编译产生的多个.o文件结合静态库、动态库进行链接，得到一个可执行文件，也叫Mach-O文件；
Mach-O里的部分信息会被行裁剪(strip)，比方说调试符号、行号等信息；为了方便调试，会把这些信息放到一个dsym文件；
3、签名&打包&上传：将裁剪后的Mach-O与资源文件（storyboard、asset）等一起打包成.app文件，再进行签名，最后上传到AppStore后端；
二、iOS如何启动App
WWDC视频中对启动过程做了少量详情，先看iOS 13以前用dyld2是如何启动App：
1、解析Mach-O文件的头部，找到LC_LOAD_DYLINKER，定位到dyld的路径，将dyld加载到内存中；
2、解析动态库的依赖，比方说我们工程中这部分依赖；
3、分别将动态库mmap到内存中，一个App运行过程中会依赖很多动态库；
4、符号查找定位，下图是我们工程依赖的GLKit.framework，但是点开framework的所在文件夹，会发现只有头文件和一个tbd文件；tbd是text-based stub library的简称，为xcode链接过程提供符号；App真正运行的时候，还需要加载动态库，进行真正的链接；（动态链接的理解可以看前文)
5、符号绑定和重定向，动态链接与静态链接一样，符号最终都需要转换为运行时的内存地址；动态库的符号需要运行时，才能确定所有符号的具体位置；还有另外一个影响的因素是iOS的ASLR(进程地址空间布局随机化)也需要在运行时加上偏移；
6、静态初始化，包括我们常用+load方法，以及其余静态初始化的方法；
dyld3如何进行优化？
iOS 13之后，系统提供的dyld3将启动过程的解析Mach-O文件的头部、解析动态库的依赖、符号查找定位的结果做了一个缓存，写到是disk中。在启动时候，就直接读取缓存并校验能否有效，再进行后续的动态库加载、符号绑定和重定向以及静态初始化。
这个缓存存储在沙盒的tmp/com.apple.dyld目录（tmp目录不能再整个清理），缓存会在手机系统更新或者者升级App时重新创立。
三、开发时如何对这些时间进行分析
开发阶段，可以在环境变量中设置DYLD_PRINT_STATISTICS值为1；
启动的时候，即可以看到控制台打出了具体的时间。
Total pre-main time: 622.64 milliseconds (100.0%) dylib loading time: 33.89 milliseconds (5.4%) rebase/binding time: 279.52 milliseconds (44.8%) ObjC setup time: 270.59 milliseconds (43.4%) initializer time: 38.63 milliseconds (6.2%) slowest intializers : libSystem.B.dylib : 7.08 milliseconds (1.1%) libMainThreadChecker.dylib : 19.92 milliseconds (3.2%)同样，还可以设置DYLD_PRINT_LIBRARIES值为1，就会打印出来装载了哪些动态库。
dyld: loaded: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMobileGestaltExtensions.dylibdyld: loaded: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libobjc-trampolines.dylibdyld: loaded: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/FontServices.framework/libTrueTypeScaler.dylibdyld: loaded: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/Accelerate.framework/Frameworks/vImage.framework/Libraries/libCGInterfaces.dylib...Instrucment也有工具进行这些时间的分析，比方说大家最常用的Time Profiler，以及更复杂的System Trace。
Time Profiler基于采样的方式进行运行时间统计，大概每毫秒会采样一次，可以通过勾选Recording Options的High Frequency来提高采样频率；Time Profiler的使用比较简单，能直接反馈出来瓶颈的问题。
System Trace可以更细致的分析锁、线程状态、内存变化、系统调用等，比方说下图的Zero Fill、File Backed Page In、Page Cache Hit、Copy On Write的分布。
File Backed Page In 就是PageFault，内存缺页中断，访问一个虚拟内存地址而内存中还不存在时触发，操作系统会分配物理内存并拷贝内容到对应物理内存；
Page Cache Hit 假如操作系统的PageCache里有对应缓存，则会触发一个Page Cache Hit；（参考资料）
Copy On Write 操作系统中的内存页存在共享的情况，假如某些页是只读，则一直是可以共享的；但是假如对一个可写的共享内存页进行写操作时，需要先复制一份再尝试写入，这个过程就是Copy On Write；
Zero Fill 部分内存页的值都是0，在读入后需要出发一次填充0的操作，这个过程就是Zero Fill；
四、如何对线上客户进行启动时间统计
最实用的方式就是打点统计：
+load方法开始打点：+load方法的调用顺序是按照链接顺序执行，假如使用CocoaPod来管理集成库，可以新建一个A开头的Pod库（CocoaPod是按照字母升序），让该Pod库的+load方法第一个被执行；
main函数开始打点：attribute可以设置函数、变量和类型属性，可以设置一个constructor属性，让函数在main()函数执行之前被自动的执行。
static void __attribute__((constructor)) _mainConstructor() { NSLog(@"main constructor");}didFinishLaunchingWithOptions开始打点：直接在APPDelegate的didFinishLaunchingWithOptions方法开始时打点；
didFinishLaunchingWithOptions结束打点：直接在APPDelegate的didFinishLaunchingWithOptions方法结束时打点；
RootViewControllerDidAppear打点：在viewDidAppear:方法开始时打点；
总结
理解更多关于启动相关的知识，才能更好去分析问题，设计良好的处理方案。
最后详情了两个工具：MachOView 和 Hopper Disassembler。 前者开源免费（直接搜索下载），后者收费软件（也可以30分钟试用）。
附录
dyld开源代码
iOS的文件内存映射——mmap
WWDC2017-App Startup Time: Past, Present, and Future
