最近在学习戴铭老师的《iOS开发高手课》,方便后续开发，特此做笔记记录一下。
本节讲解的主要内容是：App 启动速度怎么做优化与监控？
启动速度的优化必然就是 App 开发过程中，不可或缺的一个环节，那些接下来要分析一下App 在启动时都做了哪些事儿.
一. App 启动时都干了哪些事？
一般情况下，App 的启动分为冷启动和热启动.
a.冷启动是指， App 点击启动前，它的进程不在系统里，需要系统新创建一个进程分配给它启动的情况。这是一次完整的启动过程。
b.热启动是指 ，App 在冷启动后用户将 App 退后台，在 App 的进程还在系统里的情况下，用户重新启动进入 App的过程，这个过程做的事情非常少。
今天学习的这篇文章戴铭老师只针对冷启动展开了讨论。
一般而言，App 的启动时间，指的是从用户点击 App 开始，到用户看到第一个界面之间的时间。总结来说，App 的启动主要包括三个阶段：
1.main() 函数执行前；
2.main() 函数执行后；
3.首屏渲染完成后。
👉 main() 函数执行前,系统主要会做以下几件事情：
a.加载可执行文件（App 的.o 文件的集合）；
b.加载动态链接库，运行rebase指针调整和bind符号绑定；
c.Objc 运行时的初始处理，包括 Objc 相关类的注册、category 注册、selector 唯一性检查等；
d.初始化，包括了执行 +load() 方法、attribute((constructor)) 修饰的函数的调用、创建 C++ 静态全局变量。
😊 在这个阶段对于启动速度优化来说，可以做的事情包括：
a.减少动态库加载。每个库本身都有依赖关系，苹果公司建议使用更少的动态库，并且建议在使用动态库的数量较多时，尽量将多个动态库进行合并。数量上，苹果公司最多可以支持 6 个非系统动态库合并为一个。
b.减少加载启动后不会去使用的类或者方法。
c.+load() 方法里的内容可以放到首屏渲染完成后再执行，或使用 +initialize() 方法替换掉。因为，在一个+load() 方法里，进行运行时方法替换操作会带来 4毫秒的消耗。不要小看这 4 毫秒，积少成多，执行 +load() 方法对启动速度的影响会越来越大。
d.控制 C++ 全局变量的数量。
👉 main() 函数执行后的阶段，指的是从 main() 函数执行开始，到 appDelegate 的 didFinishLaunchingWithOptions 方法里首屏渲染相关方法执行完成。
首页的业务代码都是要在这个阶段，也就是首屏渲染前执行的，主要包括了：
a.首屏初始化所需配置文件的读写操作；
b.首屏列表大数据的读取；
c.首屏渲染的大量计算等。
😊 在这个阶段对于启动速度优化来说，可以做的事情应该是从功能上梳理出哪些是首屏渲染必要的初始化功能，哪些是 App 启动必要的初始化功能，而哪些是只需要在对应功能开始使用时才需要初始化的。梳理完之后，将这些初始化功能分别放到合适的阶段进行。
👉 首屏渲染完成后这个阶段主要完成的是，非首屏其他业务服务模块的初始化、监听的注册、配置文件的读取等。从函数上来看，这个阶段指的就是截止到didFinishLaunchingWithOptions 方法作用域内执行首屏渲染之后的所有方法执行完成。简单说的话，这个阶段就是从渲染完成时开始，到 didFinishLaunchingWithOptions 方法作用域结束时结束。
这个阶段用户已经能够看到 App 的首页信息了，😊所以优化的优先级排在最后。但是，那些会卡住主线程的方法还是需要最优先处理的，不然还是会影响到用户后面的交互操作。
以上就是App启动阶段需要完成的工作，我们就可以有的放矢地进行启动速度的优化了。
这些优化，包括了功能级别和方法级别的启动优化。接下来，我们就从这两个角度展开看看。
👉 功能级别的启动优化，就是要从main() 函数执行后这个阶段下手。
😊 优化的思路是： main() 函数开始执行后到首屏渲染完成前只处理首屏相关的业务，其他非首屏业务的初始化、监听注册、配置文件读取等都放到首屏渲染完成后去做。
👉 方法级别的启动优化，检查首屏渲染完成前主线程上有哪些耗时方法，将没必要的耗时方法滞后或者异步执行。通常情况下，耗时较长的方法主要发生在计算大量数据的情况下，具体的表现就是就是加载、编辑、存储图片和文件等资源。
二.对App启动速度的监控，主要有两种手段。
👉 第一种方法是，定时抓取主线程上的方法调用堆栈，计算一段时间里各个方法的耗时。
Xcode 工具套件里自带的 Time Profiler ，采用的就是这种方式。
优点：开发类似工具成本不高，能够快速开发后集成到你的 App 中，以便在真实环境中进行检查。
缺点：定时间隔设置得长了，会漏掉一些方法，从而导致检查出来的耗时不精确；而定时间隔设置得短了，抓取堆栈这个方法本身调用过多也会影响整体耗时，导致结果不准确。
这个定时间隔如果小于所有方法执行的时间（比如 0.002 秒），那么基本就能监控到所有方法。但这样做的话，整体的耗时时间就不够准确。一般将这个定时间隔设置为 0.01 秒。这样设置，对整体耗时的影响小，不过很多方法耗时就不精确了。但因为整体耗时的数据更加重要些，单个方法耗时精度不高也是可以接受的，所以这个设置也是没问题的。
总结来说，定时抓取主线程调用栈的方式虽然精准度不够高，但也是够用的。
👉 第二种方法是，对objc_msgSend 方法进行 hook 来掌握所有方法的执行耗时。
hook 方法的意思是，在原方法开始执行时换成执行其他你指定的方法，或者在原有方法执行前后执行你指定的方法，来达到掌握和改变指定方法的目的。
hook objc_msgSend 这种方式的优点是非常精确，而缺点是只能针对 Objective-C 的方法。当然，对于 c 方法和 block 也不是没有办法，你可以使用 libffi 的 ffi_call 来达成 hook，但缺点就是编写维护相关工具门槛高。
综上，如果对于检查结果精准度要求高的话，我比较推荐你使用 hook objc_msgSend 方式来检查启动方法的执行耗时。
小结
启动速度优化和监控的重要性不言而喻，加快 App 的启动速度对用户的体验提升是最大的。
启动速度的优化也有粗有细：粗上来讲，这需要对启动阶段功能进行分类整理，合理地将和首屏无关的功能滞后，放到首屏渲染完成之后，保证大头儿没有问题；细的来讲，这就需要些匠人精神，使用合适的工具，针对每个方法进行逐个分析、优化，每个阶段都做到极致。