Run, Break, Inspect: Explore effective debugging in LLDB
Developer Tools 进阶 20m

运行、断点、检查：LLDB 高效调试指南

Run, Break, Inspect: Explore effective debugging in LLDB

2024年6月10日

在 Apple 官方观看视频

一句话判断

还在用 print 调试？这场 Session 会让你重新认识 LLDB——从 crashlog 分析到断点高级用法，再到 Swift 6 新增的自定义类型展示，调试效率可以上一个台阶。

这场 Session 讲了什么

这场 Session 系统介绍了 LLDB 的核心调试能力，并提出了一套调试方法论：Run -> Break -> Inspect 的循环。核心观点是，高效的调试不是靠运气，而是靠有目的地缩小问题范围。

内容分为五个部分。首先建立了调试模型：程序在某个时间点出现了错误行为，你的目标是找到引入 bug 的那段代码。然后介绍了 crashlog 的离线分析——不需要运行程序就能定位问题。接着深入讲解了断点的多种用法：行断点、条件断点、Symbolic 断点，以及 SwiftUI 等框架代码中的断点解析。之后介绍了 p 命令（expression evaluation）用于检查和修改变量状态。最后展示了 Swift 6 的新特性：自定义数据类型在调试器中的显示格式。

Session 以 Destination Video 这个多平台视频播放 App 作为示例项目，所有演示都围绕真实的调试场景展开。

值得深挖的点

断点解析（Breakpoint Resolution）的理解与利用

Session 展示了一个容易被忽视的现象：在 Xcode 中设置一个行断点后，LLDB 可能会将它解析为多个位置。比如在一个 Button 构造函数上设断点，LLDB 解析出了三个独立位置。这意味着同一个断点可能通过不同的代码路径触发。

理解断点解析对于 SwiftUI 开发尤其重要。SwiftUI 的视图构建是声明式的，一行代码可能在多个地方被执行。当你在 Button 的构造函数上设断点时，LLDB 找到的所有位置都是这个构造函数的调用点。如果你只关心某个特定场景，可以在 Xcode 的断点导航器中查看所有解析出的位置，单独禁用不关心的那些。

Crashlog 的事后调试价值

Crashlog 调试是一个被低估的能力。LLDB 可以直接消费 crashlog 文件，在 Xcode 中创建一个模拟的调试会话。你能看到崩溃时的完整调用栈、高亮的崩溃行号，甚至能查看崩溃前的日志输出。Session 中演示的案例里，崩溃点是一个 JSON 文件打开失败，而崩溃前的日志恰好记录了文件名——这直接指向了问题根源。

使用 crashlog 调试的前提是：项目 checkout 到创建 crashlog 的同一 commit，且对应的 dSYM 符号文件可用。对于内部分发的 App，确保 CI 流水线自动归档 dSYM 是关键基础设施。

代码片段

场景一：用 crashlog 在 Xcode 中进行离线调试

# 使用步骤：

# 1. 收到 crashlog 文件后，右键 -> 用 Xcode 打开
# 2. Xcode 会询问是否在项目上下文中打开，选择对应项目
# 3. Xcode 使用 LLDB 创建模拟调试会话
# 4. 崩溃行会被高亮显示
# 5. Debug Navigator 中查看完整调用栈

# 调用栈分析示例（Session 中的案例）：
# Frame 3: JSON 加载函数 <- 崩溃点：文件打开失败
# Frame 2: 视频元数据导入
# Frame 1: 程序初始化
# Frame 0: App 启动

# 关键前提条件：
# - 项目 checkout 到同一 commit
# - dSYM bundle 可用（检查 Build Settings -> Debug Information Format = DWARF with dSYM）
# 坑点：如果没有 dSYM，调用栈只会显示内存地址，没有符号信息
# 这对 App Store 分发的 App 特别重要——必须保存每次发布的 dSYM

场景二：断点的高级用法

// 场景：调试 SwiftUI Button 的点击行为
// 在 Button 构造函数上设断点后，LLDB 解析出多个位置

// 条件断点：只在特定条件下暂停
// 在 Xcode 断点导航器中右键断点 -> Edit Breakpoint
// Condition: id == "watchLaterButton"
// 这样只会在目标按钮创建时暂停

// Symbolic 断点：在特定函数调用时暂停
// Xcode -> Debug -> Breakpoints -> Create Symbolic Breakpoint
// Symbol: SwiftUI.Button.init
// 这在你没有源码但想追踪框架行为时非常有用

// 坑点：SwiftUI 视图 body 被频繁重新求值
// 如果在 body 中设断点，可能会被触发非常多次
// 建议加条件或者在更具体的方法上设断点

场景三：Swift 6 的自定义调试器展示格式

// Swift 6 新增：LLDB Type Summary Provider
// 允许你自定义类型在调试器变量视图中的显示方式

// 定义一个自定义显示格式的类型
struct WatchLaterList {
    private var items: [Video]

    var count: Int { items.count }
}

// 在 LLDB 中注册自定义显示
// (lldb) type summary add WatchLaterList --summary-string "${var.count} items"

// 或者用 Python 脚本实现更复杂的格式化
// 这对大型数据结构特别有用——调试时不需要展开所有字段
// 就能看到关键摘要信息

// 在项目中持久化配置：
// 在项目根目录创建 .lldbinit 文件
// 或者设置 Xcode 的 LLDB Init File 路径
// Settings -> Debugger -> LLDB -> LLDB Init File

// 坑点：自定义 type summary 只影响显示，不影响实际的变量值
// 调试结束后记得清理，避免 summary 脚本误导后续调试

最佳实践

  • 调试方法论：每次调试都应该遵循 Run -> Break -> Inspect 的循环。先运行到可疑位置，设断点暂停，检查状态，然后决定是继续执行还是重新运行。避免盲目地在代码中到处插 print——每次 print 都需要重新编译，而断点可以动态修改。
  • crashlog 基础设施：确保 CI 流水线为每次构建生成并归档 dSYM。App Store Connect 会自动处理上传的 dSYM，但对于内部测试分发的构建，需要自己管理。这是 crashlog 调试能正常工作的前提。
  • 断点管理：善用 Xcode 的断点导航器。LLDB 解析出的多个断点位置可以单独启用/禁用，条件断点可以大幅减少不必要的暂停次数。

还有什么值得关注

  • Session 提到 p 命令不仅能查看变量值，还能在调试时动态修改变量状态，对验证假设非常有帮助
  • Swift 6 的自定义 Type Summary 让大型集合类型在调试器中的可读性大幅提升
  • “Symbolication: beyond the basics” 这个相关 Session 对 dSYM 和符号化的机制有更深入的讲解
WWDC 2024