Analyze hangs with Instruments
Developer Tools 进阶 20m

用 Instruments 分析应用卡顿

Analyze hangs with Instruments

2023年6月5日

在 Apple 官方观看视频

一句话判断

这场 Session 是 Instruments 卡顿分析的实战教学——从人类感知阈值出发，用灯泡实验解释为什么 100ms 是”即时感”的生死线，然后用三种典型的卡顿模式演示如何在 Instruments 中定位和修复问题。

这场 Session 讲了什么

Instruments 团队的 Joachim Kurz 系统性地讲解了如何使用 Instruments 分析应用卡顿（Hangs）。Session 从人类感知的基本原理开始，逐步深入到事件处理和渲染循环的技术细节，最后用三个真实案例演示了完整的分析流程。

人类感知阈值是理解卡顿的出发点。Session 用一个灯泡实验做了精彩的演示：100ms 的延迟几乎感觉不到，250ms 开始明显不自然，500ms 则完全破坏了”即时感”。Apple 的工具以 250ms 为起点报告”微卡顿”，500ms 以上才算正式的卡顿。

事件处理与渲染循环解释了卡顿的物理根源。用户输入经过硬件、操作系统、应用主线程、渲染服务器、显示驱动这一串管线。其中主线程是唯一的瓶颈——如果主线程被非 UI 工作阻塞，整个管线就停滞了。目标是主线程上的任何工作都不超过 100ms。

三种卡顿模式是 Session 的核心内容：忙碌主线程卡顿（主线程在执行耗时计算）、异步卡顿（等待异步操作完成）、阻塞主线程卡顿（主线程被锁或同步等待阻塞）。

值得深挖的点

“即时感”的双重标准：UI 元素的响应需要在 100ms 内完成，因为用户把它当作”真实物体”来交互。但请求-响应式的交互（如发送邮件）可以有 500ms 的延迟——前提是 UI 已经给了即时反馈（按钮高亮、动画过渡）。这个洞察对交互设计有直接指导意义。

三种卡顿模式的诊断策略：忙碌主线程卡顿在 Time Profiler 中表现为大量 CPU 时间集中在主线程上；异步卡顿表现为主线程空闲但 UI 不更新；阻塞主线程卡顿在 Time Profiler 中看不到明显 CPU 活动，需要配合 System Trace 来发现锁等待。每种模式的工具选择策略不同。

主线程的 100ms 黄金法则：不管什么操作，主线程上的任何工作都不应该超过 100ms。这包括事件处理、布局计算、视图更新等所有 UI 相关工作。超出这个阈值的操作应该移到后台线程。

卡顿与掉帧（Hitch）的关系：长时间的主线程工作不仅导致卡顿，也会导致动画掉帧。掉帧的阈值更低（每帧需要在 16.67ms 内完成），所以解决卡顿问题通常也能改善掉帧。

代码片段

// 典型的忙碌主线程卡顿 - 不要这样做
func loadUserData() {
    let data = processHeavyData() // 主线程上的耗时计算，导致卡顿
    updateUI(with: data)
}

// 正确做法：将耗时操作移到后台
func loadUserData() {
    Task.detached {
        // 耗时计算在后台线程执行
        let data = await processHeavyData()
        // UI 更新自动回到主线程
        self.updateUI(with: data)
    }
}
// 典型的异步卡顿 - 等待网络请求但不给反馈
func didTapRefresh() {
    // 用户点击后没有任何视觉反馈
    apiService.fetchData { result in
        self.updateUI(with: result) // 等待 2 秒后才更新
    }
}

// 正确做法：立即给反馈
func didTapRefresh() {
    showLoadingIndicator() // 立即响应
    apiService.fetchData { result in
        self.hideLoadingIndicator()
        self.updateUI(with: result)
    }
}
// 典型的阻塞主线程卡顿 - 主线程等待锁
let lock = NSLock()
func didTapButton() {
    lock.lock() // 主线程阻塞等待锁释放
    updateSharedState()
    lock.unlock()
    updateUI()
}

// 正确做法：使用 Actor 或异步锁机制
actor StateManager {
    private var state: AppState

    func update() -> AppState {
        // Actor 保证线程安全，不会阻塞调用方
        state.refresh()
        return state
    }
}

最佳实践

  • 主线程只做 UI 工作：这是解决卡顿问题的根本原则。数据处理、文件 I/O、网络请求、复杂计算全部移到后台线程。
  • 给异步操作加即时反馈：如果操作不可避免需要等待（如网络请求），至少在用户触发时立即给出视觉反馈——按钮状态变化、加载指示器、过渡动画。
  • 用 Instruments 的 Hangs 模板分析：Time Profiler 能发现忙碌主线程卡顿，但对阻塞型卡顿需要加 System Trace 或 os_signpost 来获得更多上下文。
  • 卡顿修复后验证：修复后重新用 Instruments 跑一遍，确认延迟降到 100ms 以下。同时检查 Xcode Organizer 中的卡顿统计数据是否改善。
  • 关注 250ms 微卡顿：虽然 500ms 以上的卡顿更紧急，但 250ms 的微卡顿积累起来会严重影响应用的”流畅感”。

还有什么值得关注

  • Session 提到了 Xcode Organizer 和设备端卡顿检测（iOS Developer 设置中可开启）作为发现卡顿的补充工具，不一定要每次都连 Instruments。
  • 灯泡实验的演示方式很值得学习——用物理世界的类比来解释抽象的性能阈值，比直接甩数字更有说服力。
  • “真实物体即时响应”这个设计哲学解释了为什么 Apple 平台对主线程性能如此执着，也解释了为什么 SwiftUI 的声明式 UI 和异步 API 设计是方向性的趋势。
  • 推荐结合 WWDC22 的 “Track down hangs with Xcode and on-device detection” 和 “Explore UI animation hitches and the render loop” 一起看，形成完整的性能优化知识链。
WWDC 2023