main函数之前，通过在Xcode里增加环境变量DYLD_PRINT_STATISTICS，可以让dyld输出pre-main之前的耗时。
可分为
1、dylib loading：动态库的加载，动态库会有依赖关系，官方建议不要多余6个动态库，太多就建议进行合并，这个合并能够提升整个加载时间
2、 rebase/binding：偏移修正，符号绑定。在二进制文件里的函数、变量的地址，都是偏移后的地址(为什么会偏移？这要从物理内存到虚拟内存的发展说起)。app在运行的时候，会把地址加上ASLR(安全机制，分配的随机数值)，那么 偏移值+ASLR = rebase(运行时候的内存地址)。
在用到如系统类的动态库的时候，会创建一个符号，指向一个唯一的值(这个值在MachO的数据段里)，在app运行时，会将这个符号和真正的地址进行关联，这个过程就叫binding(绑定)。尽量少使用外部动态库，可以减少binding的时间。
3、ObjC setup：OC类注册的耗时，类越多越耗时。通过删减一些无用的OC类，减少C++的虚函数，能够降低这部分耗时。如果全用swift，效果会更明显。
4、initializier：执行load和构造函数的耗时。尽量不要重写load，可以减少这里的耗时。
①libSystem.B.dylib
②libMainThreadChecker.dylib
③libglInterpose.dylib
我们以微信启动为例
小结：对于不用的代码或者类，尽量删除，因为它们也会加入编译，启动的时候也会耗时。
PS：增加2w个类，会增加800ms启动时间(数据仅供参考)。
虚拟内存和物理内存
物理内存：内存条(硬件)上的地址就叫物理地址，以前的计算机都是通过CPU访问物理内存拿到数据的，这样存在安全问题(金手指?)，而且随着软件发展速度快于硬件速度，物理内存也越发不够......
虚拟内存：在app运行时，CPU首先会访问虚拟内存地址，MMU内存管理单元 配合操作系统 负责地址翻译(虚实地址互转)，这样CPU就能访问物理内存地址读取数据了。虚拟内存实际就是一张表，保存着和物理内存的映射表。
内存分页管理：数据会以页的方式来存储，方便管理(Linux和MacOS每页数据是4k，iOS是16k)，每个app会被分为若干页，运行的时候会一页一页按需加载。当数据需要被使用，而且没有被加载进页表(虚拟内存里)的时候，这个时候会触发“中断”(缺页异常PageFault)，系统会让将数据载入到物理内存，这个时候再去取。
我们对app的使用或者操作，实际是CPU在对虚拟内存上进行增删改查。
当物理内存不够用的时候，系统会覆盖掉不活跃的数据。
五大分区指的是在虚拟内存的分区，我们在LLDB里看到的内存也都是虚拟内存。
虚拟地址都是从0开始，黑客们可以通过偏移拿到其他地址的数据，ASLR技术就是为了解决虚拟地址固定不变导致安全问题而出现的。
在什么时机会出现大量的PageFault？app启动的时候。启动时候会加载很多页数据。这个时候会产生大量的PF，这里就有我们需要优化的空间。
前面提到iOS每页的数据量为16k，通常在实际app冷启动中每页数据可能只会用到很少的函数。
buildsettings里的linkmap，能够记录符号顺序，这是一个txt的文件，里面有函数和类的载入顺序，文件(类)的顺序是按照编译顺序(可以在build phases里compile sources进行修改)，类里的函数顺序是按照.m里的书写顺序进行排序的
二进制的排列顺序：首先会按照文件的编译顺序，然后再按照文件里代码的书写顺序进行排序。这种排序方式就会导致启动时刻的代码会分别分布在不同的文件里，在不同的页表里就会有启动相关的方法。
将启动时刻需要调用的方法尽量排列在一起，这样能减少启动时刻加载的页的数量，这就是二进制重排的的优化思路。
利用instrument的system trace可以查看应用启动时候的PageFault次数
file backed page in就是PF次数
order file可以让ld(链接器)按照我们给定的顺序去排列符号，可以在buildsettings下的linking Order File下设置order file路径。然后通过linkmap和MachOView查看文件顺序。order file需要定义好启动时刻的结束函数，那么在结束前调用了哪些函数？可以利用clang插桩(后续文章讲解)拿到app启动时候的函数调用，然后重新排列后录入order file中，完成二进制重排(查看linkmap效果)。
