注：【本文内容是阅读「戴铭」老师的iOS开发高手课内容后，自己的笔记总结】

1、APP启动分为两种启动：冷启动 + 热启动

冷启动：APP的icon从点击启动前，它的进程不在系统里，需要新创建一个进程分配给它的启动的情况。

热启动：APP在启动后用户将APP退到后台，在APP的进程还在系统里的情况下，用户重新启动进入APP的过程。（这个过程做的事情比较少）

2、APP启动慢，其实发生在主线程上。主线程慢的原因很多。（主线程上 执行大文件读写、大量数据处理计算等等），但是当这些任务全部去掉后，剩余的主线程耗时的任务还有哪些呢？下面我们一一来找出APP启动后，主线程都干了哪些事。

3、APP启动三个阶段

冷启动流程图

         1> main()函数执行前。

1. 加载可执行文件（APP的.o 文件的集合）

2. 加载动态链接库，进行rebase指针调整和bind符合绑定。

3. Objc 运行时的初始化处理，包括 Objc相关类的注册、category注册、selector唯一性检查等。

4. 初始化，包括了执行  +load()方法、attribute(constructor)修饰的函数的调用、创建 C++静态全局变量。

针对以上过程做优化：

2> 减少动态库加载。每个库本身都有依赖关系，苹果公司建议使用更少的动态库，并且建议在使用动态库的数量较多时，尽量将多个动态库进行合并。数量上，苹果公司建议最多使用6个非系统动态库。

3>减少加载启动后不会使用的类或者方法。（项目种不再使用的类、方法 及时清理掉！）

4>+load()方法里的内容可以放到首屏渲染完成后执行，或使用+initialize()方法替换掉。因为，在一个+load()方法里，进行运行时方法替换操作会带来4毫秒的消耗。因此积少成多，使用load()方法较多会对启动速度影响越来越大。   控制++全局变量的数量！

         2>mian()函数执行后。（该阶段：从main()函数执行开始，到appDelegate的 didFinishLaunchingWIthOptions 启动方法里首屏渲染相关方法执行完成。首页的业务代码都是要在这个阶段，也就是首屏渲染前执行的）

1. 首屏  "初始化" 所需配置文件的读写操作。

2. 首屏  "列表大数据" 的读取

3. 首屏渲染的大量计算等。

针对以上过程优化：

1> 从功能上梳理出哪些是   首屏渲染必要的初始化功能 、APP启动必要的初始化功能 、 只需要在对应功能开始使用时才需要初始化。

2> 将三个 初始化功能，分别放到合适的阶段进行初始化。

        3>首屏渲染完成后。（该阶段完成的是，非首屏其他业务服务模块的初始化、监听的注册、配置文件的读取等。这个阶段就是从 APP启动方法 内 首屏渲染完成时开始，到 didFinishLaunchingWIthOptions方法作用域结束时结束。）这个阶段用户已经看到APP首页了，但是这个阶段里 会卡主主线程的方法还是需要最优先处理的，不然会影响用户后续的操作。

1、非首屏其他业务服务模块的初始化、监听的注册、配置文件的读取等

优化：

1. 会阻碍 主线程的任务方法，进行优化处理。

4、功能级别的启动优化：从main()函数执行后到首屏渲染完成前只处理首屏相关的业务，其他非首屏业务的初始化、监听注册、配置文件读取等都放到 首屏渲染完成后去做。（非首屏业务所需的功能滞后处理。）

以上处理会大大缩短 APP启动的时间。 下面会针对 方法 进一步优化。

5、方法级别的启动优化：检查首屏渲染完成前 主线程上有哪些耗时方法，将没必要的耗时滞后或者异步执行。（通常耗时较长的方法主要发生在计算大量数据的情况下，具体的表现就是加载、编辑、存储图片和文件等资源。）

对方法耗时监控，APP启动速度监控办法。

1、定时抓取主线程上的方法调用堆栈，计算一段时间里各个方法的耗时。Xcode工具套件里自带的Time Profiler，采用的就是这种方式。（Xcode —> 右键 ——> Open Developer Tool ——> Instruments 工具里）

      定时抓取：定时间隔设置得长了，会漏掉一些方法，从而导致检查出来的耗时不精确；

                          而定时间隔设置得短了，抓取堆栈这个方法本身调用过多也会影响整体耗时，导致结果不准确。

                         这个定时间隔如果小于所有方法执行的时间（比如 0.002 秒），那么基本就能监控到所有方法。但这样做的话，整体的耗时时间就不够准确。一般将这个定时间隔设置为 0.01 秒。这样设置，对整体耗时的影响小，不过很多方法耗时就不精确了。但因为整体耗时的数据更加重要些，单个方法耗时精度不高也是可以接受的，所以这个设置也是没问题的。 总结来说，定时抓取主线程调用栈的方式虽然精准度不够高，但也是够用的。

2、对objc_msgSend方法进行hook来掌握所有方法的执行耗时：优点 非常精确，但缺点 只能针对 Objective-C的方法，当然 对于c方法 和block 可以使用 libffi 的 ffi_call 来 达成hook，但缺点就是编写维护相关工具门槛高。

objc_msgSend方法本身采用汇编语言写的，所以性能优化属于原子级优化，能够把优化做到极致。

objc_msgSend方法执行的逻辑：先获取对象的对应类的信息，再获取方法的缓存，根据方法的selector查找函数指针，经过异常错误处理后，最后跳到对应函数的实现。

6、objc_msgSend 方法hook工具：Facebook开源的库 fishhook.(可以在iOS运行的 Mach-O二进制文件中动态地重新绑定符号) GitHub地址：fishhook 代码

fishhook原理：fishhook 实现的大致思路是，通过重新绑定符号，可以实现对 c 方法的 hook。dyld 是通过更新 Mach-O 二进制的 __DATA segment 特定的部分中的指针来绑定 lazy 和 non-lazy 符号，通过确认传递给 rebind_symbol 里每个符号名称更新的位置，就可以找出对应替换来重新绑定这些符号。

使用Demo在戴铭老师的GitHub上地址：GCDFetchFeed