App 启动速度怎么做优化与监控？

App的启动分类

一般情况下，App 的启动分为冷启动和热启动。

冷启动是指， App 点击启动前，它的进程不在系统里，需要系统新创建一个进程分配给它启动的情况。这是一次完整的启动过程。就是我们所说被”杀死“以后，从头开始启动的过程
热启动是指，App 在冷启动后用户将 App 退后台，在 App 的进程还在系统里的情况下，用户重新启动进入 App 的过程，这个过程做的事情非常少。即程序处于后台

由于热启动过程短，APP启动优化为App 冷启动的优化

用户能感知到的启动慢，其实都发生在主线程上。而主线程慢的原因有很多，比如在主线程上执行了大文件读写操作、在渲染周期中执行了大量计算等。

App的启动时间

一般而言，App 的启动时间，指的是从用户点击 App 开始，到用户看到第一个界面之间的时间。t(pre-main) +t( main )

总结来说，App 的启动主要包括三个阶段：
main() 函数执行前；
main() 函数执行后；
首屏渲染完成后； rootviewcontroller

main() 函数执行前

pre_main测量方法:
Xcode 中 Edit scheme -> Run -> Auguments 将环境变量 DYLD_PRINT_STATISTICS 设为 1

image.png

Total pre-main time: 1.0 seconds (100.0%)
         dylib loading time: 188.44 milliseconds (18.0%)
        rebase/binding time:  24.26 milliseconds (2.3%)
            ObjC setup time: 238.08 milliseconds (22.8%)
           initializer time: 591.25 milliseconds (56.7%)
           slowest intializers :
             libSystem.B.dylib :   8.26 milliseconds (0.7%)
    libMainThreadChecker.dylib : 200.57 milliseconds (19.2%)
                    PalmTutors : 642.09 milliseconds (61.6%)

dylib loading | 加载动态链接库。可以看到这个部分是耗时比较多的，相应的优化手段应该是尽量减少动态库的加载，或者尽量将多个动态库进行合并使用。
rebease/binding | 进行rebase指针调整和bind符号绑定。dylib加载完成之后，它们处于相互独立的状态，需要绑定起来。在dylib的加载过程中，系统为了安全考虑，引入了ASLR（Address Space Layout Randomization）技术和代码签名。由于ASLR的存在，镜像（Image，包括可执行文件、dylib和bundle）会在随机的地址上加载，和之前指针指向的地址（preferred_address）会有一个偏差（slide），dyld需要修正这个偏差，来指向正确的地址。Rebase在前，Bind在后，Rebase做的是将镜像读入内存，修正镜像内部的指针，性能消耗主要在IO。Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。
ObjC setup | 运行时初始处理，包括相关类的注册、category注册、selector唯一性检查等。OC的runtime需要维护一张类名与类的方法列表的全局表。这个部分的优化手段是定期清理项目中不再使用的类或者方法，因为在功能迭代时期可能会淘汰掉很多不再需要的功能，应该将这些文件及时清理。
initializer | 初始化，包括了执行+load()方法、创建静态全局变量等。在一个+load()方法里，进行运行时方法替换会带来4毫秒的消耗，这部分消耗积少成多，可以选择使用+initialize()方法替换，或者将这部分内容放到首屏渲染完成后执行，进行分流。还有由于这部分主要是系统级别的操作，所以我们能优化的范围很小，主要是要了解这个阶段系统的主要工作，尽量避免使用动态库，检查+load()方法等。

概括说：

在 main() 函数执行前，系统主要会做下面几件事情：
加载可执行文件（App 的.o 文件的集合）；
加载动态链接库，进行 rebase 指针调整和 bind 符号绑定；
Objc 运行时的初始处理，包括 Objc 相关类的注册、category 注册、selector 唯一性检查等；
初始化，包括了执行 +load() 方法、attribute((constructor)) 修饰的函数的调用、创建 C++ 静态全局变量。

main() 函数执行后

main() 函数执行后的阶段，指的是从 main() 函数执行开始，到 appDelegate 的 didFinishLaunchingWithOptions 方法里首屏渲染相关方法执行完成。

首页的业务代码都是要在这个阶段，也就是首屏渲染前执行的，主要包括了：
1.首屏初始化所需配置文件的读写操作；
2.首屏列表大数据的读取；
3.首屏渲染的大量计算等。

很多时候，开发者会把各种初始化工作都放到这个阶段执行，导致渲染完成滞后。更加优化的开发方式，应该是从功能上梳理出哪些是首屏渲染必要的初始化功能，哪些是 App 启动必要的初始化功能，而哪些是只需要在对应功能开始使用时才需要初始化的。梳理完之后，将这些初始化功能分别放到合适的阶段进行。

首屏渲染完成后

首屏渲染后的这个阶段，主要完成的是，
1.非首屏其他业务服务模块的初始化
2.监听的注册
3.配置文件的读取等。

从函数上来看，这个阶段指的就是截止到 didFinishLaunchingWithOptions 方法作用域内执行首屏渲染之后的所有方法执行完成。简单说的话，这个阶段就是从渲染完成时开始，到 didFinishLaunchingWithOptions 方法作用域结束时结束。

这个阶段用户已经能够看到 App 的首页信息了，所以优化的优先级排在最后。但是，那些会卡住主线程的方法还是需要最优先处理的，不然还是会影响到用户后面的交互操作。明白了 App 启动阶段需要完成的工作后，我们就可以有的放矢地进行启动速度的优化了。这些优化，包括了功能级别和方法级别的启动优化。

启动优化

功能级别的启动优化
功能级别的启动优化，就是要从 main() 函数执行后这个阶段下手。
优化的思路是：
main() 函数开始执行后到首屏渲染完成前只处理首屏相关的业务，其他非首屏业务的初始化、监听注册、配置文件读取等都放到首屏渲染完成后去做。
优化后，从用户点击 App 到看到首屏的时间将会有很大程度的缩短，也就达到了优化 App 启动速度的目的。
方法级别的启动优化
检查首屏渲染完成前主线程上有哪些耗时方法，将没必要的耗时方法滞后或者异步执行。通常情况下，耗时较长的方法主要发生在计算大量数据的情况下，具体的表现就是加载、编辑、存储图片和文件等资源。

监控耗时（待更新）

定时抓取主线程上的方法调用堆栈，计算一段时间里各个方法的耗时。eg:Xcode 工具套件里自带的 Time Profiler 。
对 objc_msgSend 方法进行 hook 来掌握所有方法的执行耗时。