|
2
一个典型的局部，能看到主线程是 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 的机会
从中我们能看到几个结论： - 不指定 QoS 时，自行创建的 GCD queue 的 QoS 是 User-Initiated
- 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。 加入我们
字节跳动 APM 中台目前致力于提升整个集团内全系产品的性能和稳定性表现，技术栈覆盖 iOS/Android/Server/Web/Hybrid/PC/游戏/小程序等，工作内容包括但不限于性能稳定性监控，问题排查，深度优化，防劣化等。长期期望为业界输出更多更有建设性的问题发现和深度优化手段。欢迎对字节APM 团队职位感兴趣的同学投递简历到邮箱fengyadong@bytedance.com。 ,
免责声明：本文仅代表文章作者的个人观点，与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺，请读者仅作参考，并自行核实相关内容。文章投诉邮箱：anhduc.ph@yahoo.com
| 
