作者｜徐霜晴

引言

在启动优化时，我们常常通过增加并发的方式来减轻主线程的耗时。而在 iOS 中，GCD 是并发编程最常用的框架。增加并发是否是启动优化的良策？开发者适合选用哪个优先级的 GCD 队列？本文将结合飞书启动优化，给出选取 GCD 队列的最佳实践，也提供针对低端机的启动优化思路。

应用此思路，我们在未修改飞书业务逻辑的情况下，在飞书低端机上，取得了不错的用户体验收益：首屏展示时间优化 100ms，消息列表首刷时间优化 1500ms。

低端机的特性

通过 Instruments 的 App Launch 功能，我们能看到 App 启动时的线程状态、Time Profiler 等信息。其中，我们发现不同设备在启动时的表现有很大差异。​​

以 iPhone 7p（低端）和 iPhone 12（高端）举例，它们的设备参数分别为：

设备	CPU 参数	实际核数 ProcessInfo.processInfo.activeProcessorCount	跑满的 CPU 占比（Xcode 测试）
iPhone 7p	A10 芯片[1]，2 高性能 + 2 低功耗，但是只有 2 核能同时工作	2	200%
iPhone 12	A14 芯片[2]，2 高性能 + 4 低功耗	6	600%

启动飞书时，我们通过 Instruments 观察两个设备的线程状态，经过统计发现，iPhone 7p 上，主线程 Preempted 和 Runnable 状态的占比高达 21%。Instruments 的图中能看到主线程大片被抢占。

一个典型的局部，能看到主线程是 preempted 状态，CPU0 在执行其他进程，CPU1 在执行 GCD 线程。

而 iPhone 12，主线程 Preempted 和 Runnable 状态占比则只占 1%从这里我们能发现：对低端机来说，CPU 已经成为了启动的瓶颈，“增大并发”已不是一个万能的启动优化措施，而想办法减少其他线程对主线程的抢占，可能会是优化思路。

GCD queue 对主线程的抢占评测

为了评估“减少其他线程对主线程的抢占”是否是一个可行的优化思路，我们首先需要弄明白，主线程被抢占的程度会有多大？

我们可以使用 Demo 制造一些极端场景，了解极端场景下，主线程有多少比例会被其他线程抢占，因此有了如下 Demo 实验：

实验组1：

• 异步线程 QoS：DispatchQoS.userInteractive

代码：

for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue", qos: .userInteractive)
queue.async {
while true {
}
}
}
while true {
}

• qos_class_self 数值：33
• 主线程 Preempted + Runnable 占比：74%

实验组2：

异步线程 QoS：不指定 QoS 或 DispatchQoS.userInitiated

代码：

for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue")
queue.async {
while true {
}
}
}
while true {
}

• qos_class_self 数值：25
• 主线程 Preempted + Runnable 占比：73%

实验组3：

• 异步线程 QoS：DispatchQoS.utility​
• 代码：

for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue", qos: .utility)
queue.async {
while true {
}
}
}
while true {
}

• qos_class_self 数值：17
• 主线程 Preempted + Runnable 占比：1.3%

实验组4：

• 异步线程 QoS：DispatchQoS.background​
• 代码：

for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue", qos: .background)
queue.async {
while true {
}
}
}
while true {
}

• qos_class_self 数值：9
• 主线程 Preempted + Runnable 占比：1.3%​

不指定 QoS 下，一个极端 Demo，启动期间主线程长时间处于 preempted 状态，一直无法得到 running 的机会

从中我们能看到几个结论：

1. 不指定 QoS 时，自行创建的 GCD queue 的 QoS 是 User-Initiated
2. User-Initiated 及以上优先级，对主线程会有严重抢占现象；而 Utility 和 Background 则几乎不会抢占主线程。

另外，我们也做测试验证了，pthread_create 创建的线程，也有类似的抢占现象。

QoS 和 Priority

看到 iPhone 7p 上主线程被其他线程抢占，我们可能会有疑问：主线程不应该是优先级最高的么？怎么还会被其他线程抢占？

这里，我们需要理解一下 QoS 和线程 priority 两个概念。

QoS（quality of service）意指服务质量，它影响线程优先级（priority），也影响 I/O 吞吐、 CPU 吞吐等指标[3]。开发者可以用 qos_class_self() 接口获得当前线程 / 队列的 QoS。

苹果对于每个任务应该选用哪个 QoS，也有一些指导意见[4]：

QoS 和 priority 确实有对应关系，参考 xnu 源码和实验结果，对应关系为：​

QoS	Priority
User-Interactive	46，对于 UI 线程是 47
User-Initiated	37
Utility	20
Background	4

同时，线程的 priority 会随着执行动态调整。测试中我们会发现，主线程的 priority 在运行开始时是 QoS User-Interactive 对应的 47，但随着运行会出现下降的情况。

官方文档[5]中解释了线程 priority 变化的原因，priority 由 Mach scheduler 控制，为了防止计算密集的线程垄断资源，各个线程的 priority 会实时调整。

All of these mechanisms are operating continually in the Mach scheduler. This means that threads are frequently moving up or down in priority based upon their behavior and the behavior of other threads in the system.

进一步阅读 xnu 内核的源码[6]，我们发现，线程 priority 的变化，是由各个 Mach scheduler 实现的 compute_timeshare_priority 接口控制的。在 iOS 使用的 Mach scheduler 中，compute_timeshare_priority 为同一个实现 sched_compute_timeshare_priority。线程调度时的 priority，会在线程固有 priority 的基础上，结合当前线程的 CPU 占用情况和当前设备的整体负载进行调整。

在这个实现中，我们能看到 Mach scheduler 对 priority 的调整会有一个极限：对于原先 priority = 47 的线程来说，向下调整的极限是 47 - ((BASEPRI_FOREGROUND - BASEPRI_DEFAULT) + 2) = 29。这和我们用多个设备测试到的结果吻合：主线程执行时，priority 的最低值是 29，依然高于 Utility 对应的 priority 20。

这也解释了，为什么 Demo 中当异步线程的 QoS 是 Utility 时，就几乎无法对主线程造成抢占。

优化落地

通过 Demo 实验，一个启动优化思路产生了：在飞书中，大量异步队列的 QoS 是 User-Initiated，尽管这一 QoS 低于主线程的 User-Interactive，但依然可能对主线程造成抢占；那么，如果将异步队列的 QoS 调低到 Utility，是不是就可以优先保障主线程执行，让首屏更早展现出来？

经过一些粗暴的实验，我们证实了飞书在这个思路上存在优化空间。但另一个问题随之而来：如何兼顾首屏、消息列表首刷等多个指标？

考虑消息列表首刷的场景：获取到最新的消息，不仅仅需要主线程构建 UI，还需要依赖数据库读取、网络请求等异步操作。如果我们粗暴地将所有异步队列的 QoS 调低，首屏确实能更快展现，但消息列表的首刷则随着异步操作的变慢更劣化了。这对用户体验反而带来了负向影响。

梳理出哪些异步操作是首刷依赖的，确保这些队列的 QoS ，是优化中非常重要的一环。我们首先通过不断用 Instruments 测试、阅读代码梳理出了首版白名单队列，并在线下和线上验证了首屏、首刷等关键指标的优化收益。在后来的迭代中，我们又开发了线下工具，通过在线下 hook dispatch_async 等函数，记录下首刷等时机依赖的 GCD 队列，达成了白名单队列自动生成的能力。

效果分析

这一优化在线上产生了不错的体验优化效果：

启动首屏展现时间优化 100ms

通过调整异步线程的 QoS，启动期间主线程 CPU 抢占现象有明显降低。更多计算资源集中到主线程，使得首屏展示速度明显加快。

消息列表首刷时间优化 1500ms

通过对消息列表首刷依赖的任务的分析，我们调低了无关线程的 QoS，这也让首刷依赖的数据库读取、网络请求等任务得到了更多资源，加速了它们的执行。

总结

“增加并发”在一定范围内可以作为启动优化的方案，但在低端机上，CPU 已经成为瓶颈，并发时异步线程对主线程的抢占也需要引起重视。

GCD 提供了四种 QoS 给开发者使用，官方也为这四种 QoS 提供了最佳实践建议。

经过评测和源码推理，User-Interactive 和 User-Initiated 对主线程有明显抢占，Utility 和 Background 对主线程的抢占极少。开发者创建的 GCD 队列，默认的 QoS 实际为 User-Initiated。因此在启动期间（或者任何耗时敏感期间），与启动无直接关系的 queue，应该主动设置为 Utility 或 Background，减少对主线程的抢占。

通过飞书上落地优化，我们能得出结论：对线程或 GCD queue 调整 QoS，能在不改变启动业务逻辑的情况下取得显著收益。

当然，比事后优化更好的操作，是在编码时就充分了解不同 QoS 的行为特性，选用最适合的 QoS。​