iOS启动时间优化（一）
前言
过长的启动时间对于用户体验是非常的不好的，苹果建议的启动时间不要超过400ms，并且启动时间超过20s将被系统直接杀死。所以优化启动时间是极其必要的。
启动时间调试
App启动耗时主要分为main函数前与main函数之后的耗时，查看main函数前的耗时可以Edit->Run->Arguments->Environment Variables中添加参数DYLD_PRINT_STATISTICS参数，main函数之后可以直接打点查看时间。
添加DYLD_PRINT_STATISTICS参数后，App启动后，控制台会输出
Total pre-main time: 2.3 seconds (100.0%)
dylib loading time: 461.95 milliseconds (19.7%)
rebase/binding time: 216.22 milliseconds (9.2%)
ObjC setup time: 735.25 milliseconds (31.4%)
initializer time: 927.89 milliseconds (39.6%)
slowest intializers :
libSystem.B.dylib : 20.75 milliseconds (0.8%)
……
- dylib loading time 动态库载入耗时
可以删除不必要的动态库，动态库合并，或将动态库变成静态库 - rebase/binding time
rebase做偏移修正：ASLR随机分配的内存地址+文件偏移地址，用于找到外部方法（外部方法：可执行文件外的方法）。
binding：外部方法的绑定。 - ObjC setup time OC方法类注册 -- 耗时参考：每20000个类大概增加耗时800ms
删除僵尸类。 - initializer time 执行load方法耗时
减少load方法中的耗时操作 - slowest intializers 比较耗时的动态库
根据上面可对pre-main阶段进行优化，同时对比swift和OC，因为swift是静态语言，相对耗时会更少。
pre-main阶段优化是相对比较复杂的，主要优化还是在main()之后
可以使用打点计时器BLStopwatch打点调试，大概优化有这几方面
- 减少初始化阶段的流程：懒加载等
- 优化代码逻辑--大部分耗时可以通过该操作优化
- 启动阶段可以使用多线程
- 尽量少使用sb/xib
二进制重排
二进制重排可以优化大部分App的启动时间
虚拟内存与物理内存
了解二进制重排前，需要先了解虚拟内存与物理内存。
每一个应用在启动时，都会在虚拟内存中创建一个页表。在iPhone中，应用将以16K为一页，将数据分为n页插入到页表中，当执行一个应用时，cpu会先在虚拟内存中找到需要执行的方法所在的页，比如图中P1，然后在P1所指向物理内存中地址中找到真正的方法进行执行。
但是因为物理内存大小有限，虚拟内存中页对应的数据并不一定写入到了物理内存中，如P2，当读到对应页时，就会有缺页异常的错误，同时会将对应的数据写入到物理内存中，并覆盖掉不活跃的数据。而这种缺页异常越多，耗时就越大。
虚拟内存与物理内存
应用启动时所调用的类转化成二进制写入到虚拟内存中时，可能分布在很多不同的页中。而哪怕CPU只读取这个页中的一个方法，也需要把整页的数据先写入物理内存才能执行。如果启动时调用的方法分布的页越多，缺页异常出现的就越多，耗时就越长，特别是冷启动时（应用所有数据都没有写入物理内存中）。
二进制重排就是将二进制中的方法重新排序，尽可能将启动的方法放在相同页中，减少缺页异常出现的次数，从而减少启动耗时。
先介绍个简单的方法
通过拖动Build Phases中Compile Source中的文件顺序，将启动的方法所在的文件排在前面，可以使起所在页相对集中，减少耗时，不过这种方法只是使文件相对集中，而文件中也有很大启动时没用到的方法，二进制重排是直接将启动时调用的方法排在一起，优化效果更佳。
缺页异常时间查看
使用instruments中的system trace进行调试
应用启动后，点停止，可以获取到如下数据：
System Trace
其中count的缺页异常次数，Duration是总耗时
如果重复启动，缺页异常次数可能减少，因为部分数据已经写入了物理内存中。要想缺页异常次数尽可能的大，可以先尝试多打开一些其他App，再启动该App查看。
这篇文章先说到这里，二进制重排具体实现，将在启动优化（二）中详细写
文章在我的博客中地址：地址
