iOS面试与核心基础之启动优化

App启动类型

1. APP的启动可以分为2种

• 冷启动（Cold Launch）：从零开始启动APP
  冷启动是指， App 点击启动前，它的进程不在系统里，需要系统新创建一个进程分配给它启动的情况。这是一次完整的启动过程。
• 热启动（Warm Launch）：APP已经在内存中，在后台存活着，再次点击图标启动APP
  App 在冷启动后用户将 App 退后台，在 App 的进程还在系统里的情况下，用户重新启动进入 App 的过程，这个过程做的事情非常少。

启动过程

第一种划分方式

启动过程可以分为三个阶段

• main() 函数执行前
• main() 函数执行后
• 首屏渲染完成后

main() 函数执行前，系统主要会做下面几件事情：

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

可以做的优化：

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

main() 函数执行后

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

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

• 首屏初始化所需配置文件的读写操作
• 首屏列表大数据的读取；
• 首屏渲染的大量计算等。

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

首屏渲染完成后

首屏渲染后的这个阶段，主要完成的是，非首屏其他业务服务模块的初始化、监听的注册、配置文件的读取等。从函数上来看，这个阶段指的就是截止到 didFinishLaunchingWithOptions 方法作用域内执行首屏渲染之后的所有方法执行完成。简单说的话，这个阶段就是从渲染完成时开始，到 didFinishLaunchingWithOptions 方法作用域结束时结束。这个阶段用户已经能够看到 App 的首页信息了，所以优化的优先级排在最后。但是，那些会卡住主线程的方法还是需要最优先处理的，不然还是会影响到用户后面的交互操作。

监控首屏渲染完成前的方法耗时的手段：

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

如何hook objc_msgSend?
Fishhook
fishhook 实现的大致思路是，通过重新绑定符号

如何打印买逆函数之前通过添加环境变量可以打印出APP的启动时间分析（Edit scheme -> Run -> Arguments）
DYLD_PRINT_STATISTICS设置为1
如果需要更详细的信息，那就将DYLD_PRINT_STATISTICS_DETAILS设置为1

第二种划分方式

• dyld
• runtime
• main()

dyld

dyld（dynamic link editor），Apple的动态链接器，可以用来装载Mach-O文件（可执行文件、动态库等）

启动APP时，dyld所做的事情有

• 装载APP的可执行文件，同时会递归加载所有依赖的动态库
• 当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理

runtime

启动APP时，runtime所做的事情有

• 调用map_images进行可执行文件内容的解析和处理
• 在load_images中调用call_load_methods，调用所有Class和Category的+load方法
• 进行各种objc结构的初始化（注册Objc类 、初始化类对象等等）
• 调用C++静态初始化器和__attribute__((constructor))修饰的函数

到此为止，可执行文件和动态库中所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被runtime 所管理

优化方向

按照不同的阶段

dyld

• 减少动态库、合并一些动态库（定期清理不必要的动态库）
• 减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）
• 减少C++虚函数数量
• Swift尽量使用struct

runtime

• 用+initialize方法和dispatch_once取代所有的__attribute__((constructor))、C++静态构造器、ObjC的+load

main

• 在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在finishLaunching方法中
• 按需加载