iOS App启动优化

启动的阶段

1. main() 函数执行前

执行的操作

• 加载可执行文件（App 的.o 文件的集合）

• 加载动态链接库，进行 rebase 指针调整和 bind 符号绑定

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

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

  注：attribute((constructor))

  constructor参数让系统执行main()函数之前调用函数(被__attribute__((constructor))修饰的函数).同理, destructor让系统在main()函数退出或者调用了exit()之后,调用我们的函数.带有这些修饰属性的函数,对于我们初始化一些在程序中使用的数据非常有用.

优化思路

• 减少动态库加载。每个库本身都有依赖关系，苹果公司建议使用更少的动态库，并且建议在使用动态库的数量较多时，尽量将多个动态库进行合并。数量上，苹果公司建议最多使用 6 个非系统动态库。
• 减少加载启动后不会去使用的类或者方法。
• +load() 方法里的内容可以放到首屏渲染完成后再执行，或使用 +initialize() 方法替换掉。因为，在一个 +load() 方法里，进行运行时方法替换操作会带来 4 毫秒的消耗。不要小看这 4 毫秒，积少成多，执行 +load() 方法对启动速度的影响会越来越大。
• 控制 C++ 全局变量的数量。

2. main() 函数执行后

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

首页的业务代码都是要在这个阶段，也就是首屏渲染前执行的，主要包括了：

• 首屏初始化所需配置文件的读写操作；

• 首屏列表大数据的读取；

• 首屏渲染的大量计算等。

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

3. 首屏渲染完成后

首屏渲染后的这个阶段，主要完成的是，非首屏其他业务服务模块的初始化、监听的注册、配置文件的读取等。从函数上来看，这个阶段指的就是截止到 didFinishLaunchingWithOptions 方法作用域内执行首屏渲染之后的所有方法执行完成。简单说的话，这个阶段就是从渲染完成时开始，到 didFinishLaunchingWithOptions 方法作用域结束时结束。

这个阶段用户已经能够看到 App 的首页信息了，所以优化的优先级排在最后。但是，那些会卡住主线程的方法还是需要最优先处理的，不然还是会影响到用户后面的交互操作。

明白了 App 启动阶段需要完成的工作后，我们就可以有的放矢地进行启动速度的优化了。这些优化，包括了功能级别和方法级别的启动优化。接下来，我们就从这两个角度展开看看。

如何监控方法耗时

• 定时抓取主线程上的方法调用堆栈，计算一段时间里各个方法的耗时

常用Xcode 工具套件里自带的 Time Profiler

• 对 objc_msgSend 方法进行 hook 来掌握所有方法的执行耗时

  hook objc_msgSend 这种方式的优点是非常精确，而缺点是只能针对 Objective-C 的方法。

如何hook objc_msgSend

可以使用fishhook 可以在Mach-O 二进制文件中动态地重新绑定符号

使用fishhook hook objc_msgSend方法，在objc_msgSend 前后新增 pushCallRecord和popCallRecord，用于记录方法开始和结束的时间，最后相减。