iOS 应用崩溃、卡顿、内存泄漏与性能问题的调试与…

在调试 iOS 应用时，用 LLDB、Memory Graph Debugger 和 Instruments 定位崩溃、循环引用、卡顿、构建失败及 CPU/内存/能耗/网络性能问题。

适用场景

解决思路

1. LLDB 调试流程：在 Debug 构建中复现问题，停在最窄的有用断点；用 `v` 检查局部变量而不执行代码，然后捕获当前堆栈；切换到相关帧或线程验证失败状态；仅在错误状态转换仍不清晰时添加条件断点或观察点。
2. 常用 LLDB 命令：`br set -f ViewModel.swift -l 42` 按文件行号下断点；`v myLocal` 不执行代码查看局部变量；`po myObject` 在需要时使用 debugDescription；`bt all` 捕获所有线程回溯；`frame select 3` 查看相关帧；`br modify 1 -c "count > 10"` 收窄嘈杂断点；`w set v self.score` 在意外写入时停止。
3. 优先使用 `v` 而非 `po` 查看局部变量值，因为它不执行代码、不会触发副作用；表达式求值可能执行或修改程序状态，硬件观察点资源稀缺，两者都要谨慎使用。
4. Memory Graph Debugger 工作流：在 Debug 配置下运行应用；复现疑似泄漏（进入某屏幕再返回）；点击 Xcode 调试栏的 Memory Graph 按钮；查找紫色警告图标（表示泄漏对象）；选中泄漏对象查看其引用图和回溯。
5. 在运行前启用 Malloc Stack Logging（Scheme > Diagnostics），以便 Memory Graph 显示分配回溯。
6. 修复闭包强引用 self 导致的循环引用：将 `onUpdate = { self.refresh() }` 改为 `onUpdate = { [weak self] in self?.refresh() }`。
7. 修复强引用 delegate 导致的循环引用：将 `var delegate: DataDelegate?` 改为 `weak var delegate: DataDelegate?`，并让协议继承 `AnyObject`。
8. 修复 Timer 保留 target 导致的循环引用：将 `Timer.scheduledTimer(timeInterval:target:selector:...)` 改为闭包式 API `Timer.scheduledTimer(withTimeInterval:repeats:) { [weak self] _ in self?.tick() }`。
9. 使用 Allocations 模板跟踪内存随时间增长，用 Mark Generation 隔离用户操作之间创建的分配（如打开/关闭屏幕）。
10. 使用 Leaks 模板检测泄漏分配，包括进程无法再访问的孤立循环引用；与 Allocations 一起运行以获得完整视图。
11. 按应用模块名过滤以排除系统分配。
12. 泄漏或内存增长排查时组合使用工具：在复现步骤前后用 Allocations 的 Mark Generation 证明保留增长，再用 Memory Graph Debugger 检查对象所有权，用 Malloc Stack Logging 恢复分配调用栈。
13. 在 Scheme > Run > Diagnostics > Malloc Stack Logging 中启用，记录分配回溯，使 Memory Graph Debugger、Allocations 工具和导出的 `.memgraph` 文件能显示对象创建位置。
14. 用 `leaks MyApp.memgraph` 检查从 Xcode 或 Instruments 导出的内存图。
15. 卡顿检测工具：Thread Checker（Xcode Diagnostics）警告非主线程 UI 调用；Thread Performance Checker 报告优先级反转；On-device Hang Detection 在开发者设置中报告设备使用中的卡顿；Time Profiler / CPU Profiler / Hitches 分析可复现卡顿；os_signpost 和 `OSSignposter` 标记 Instruments 区间；MetricKit 挂起诊断用于生产环境检测。
16. 用 OSSignposter 标记自定义性能区间：创建 `OSSignposter(subsystem:category:)`，用 `beginInterval` 和 `endInterval` 包裹耗时操作。
17. 使用 Time Profiler：Product > Profile（Cmd+I）启动 Instruments；选择 Time Profiler 模板；复现慢交互时录制；聚焦主线程，按 Weight 排序找热点路径；勾选 Hide System Libraries 只看自己的代码；双击重帧跳转到源码。
18. 常见卡顿原因与修复：主线程同步 I/O 阻塞 UI → 移到 `Task { }` 或后台 actor；锁竞争 → 使用 actor 或缩小锁范围；布局抖动 → 批量布局变更、避免强制布局；大 JSON 解析 → 后台线程解析；同步图片解码 → 使用 AsyncImage 或主线程外解码。
19. 构建失败排查：从第一个错误开始看，后续错误常是级联的；在构建日志中搜索错误码（如 `error: cannot convert`）；用 Report Navigator（Cmd+9）查看带时间戳的完整构建日志。
20. SPM 依赖解析冲突：检查 Package.resolved 并更新版本范围；必要时重置缓存：`rm -rf ~/Library/Caches/org.swift.swiftpm`、`rm -rf .build`、`swift package resolve`。
21. 模块未找到/链接错误排查：`No such module 'Foo'` 检查 target membership、import 路径、framework search paths；`Undefined symbol` 检查链接阶段缺少 framework、架构错误；`duplicate symbol` 检查两个 target 定义同一符号、ObjC 命名冲突。
22. 优先检查的构建设置：`FRAMEWORK_SEARCH_PATHS`、`OTHER_LDFLAGS`、`SWIFT_INCLUDE_PATHS`、`BUILD_LIBRARY_FOR_DISTRIBUTION`（用于 XCFrameworks）。
23. Instruments 模板选择：Time Profiler 用于 CPU 高、UI 慢、找热点代码；Allocations 用于内存随时间增长、跟踪对象生命周期；Leaks 用于怀疑循环引用或废弃对象；Network 用于检查 HTTP 请求/响应时序和负载；SwiftUI 用于分析视图 body 求值和更新频率；Animation Hitches / Core Animation 用于掉帧、卡顿、混合和提交/渲染工作；Power Profiler 用于电池消耗、热压力和后台能耗；File Activity 用于过多磁盘 I/O 和慢文件操作；System Trace 用于线程调度、系统调用和虚拟内存缺页。
24. 用 xctrace CLI 在 CI 中分析：`xcrun xctrace record --device "My iPhone" --template "Time Profiler" --instrument "Allocations" --output profile.trace --launch -- /path/to/MyApp.app`；`xcrun xctrace export --input profile.trace --xpath '/trace-toc/run/data/table'` 导出 XML 供自动分析；`xcrun xctrace list templates` 列出模板；`xcrun xctrace list devices` 列出设备。
25. 每次录制只用一个 `--template`，用 `--instrument` 添加额外工具；在 CI 流水线中用 xctrace 自动捕获性能回归，比较不同构建之间导出的指标。
26. 不要用 print() 调试，改用 os.Logger：`let logger = Logger(subsystem: "com.example.app", category: "UI")`，用 `logger.debug(...)` 和 `logger.info(...)` 获得级别、隐私元数据和子系统/分类过滤；`.debug` 保留在内存中且不会持久化到 release 构建。
27. 内存调试前务必启用 Malloc Stack Logging：在 Scheme > Run > Diagnostics 勾选 "Malloc Stack Logging: All Allocations"，然后运行、复现泄漏、打开 Memory Graph，否则只能看到泄漏对象而看不到分配回溯。
28. 不要用优化后的代码调试并期望完整变量可见性：调试用 Debug 配置（完整符号、无优化），性能分析用 Release 配置（真实性能）；Debug 构建的额外运行时检查会扭曲性能测量，Release 构建中变量会显示为 `<optimized out>`。
29. 不要在循环每次迭代都停下：用条件断点，如 `br set -f MyFile.swift -l 42 -c "item.id == targetID"`，或在 Xcode 中右键断点 > Edit > 添加 Condition。
30. 不要忽略 Thread Sanitizer（TSan）警告：TSan 警告表示数据竞争，可能只在间歇性崩溃时出现，应视为真实 bug；用 actor 保护共享可变状态，如 `actor CacheActor { var cache: [String: Data] = [:] ... }`。
31. 启用 TSan：Scheme > Run > Diagnostics > Thread Sanitizer；对于 iOS、iPadOS、tvOS、visionOS 和 watchOS 应用，在模拟器中运行 TSan；Apple 仅记录 64 位 macOS 应用的设备支持。
32. 审查清单：使用 os.Logger 而非 print()；内存调试前启用 Malloc Stack Logging；在 dismiss/dealloc 流程后检查 Memory Graph Debugger；delegate 声明为 `weak var`；存储为属性的闭包使用 `[weak self]`；Timer 使用闭包式 API 加 `[weak self]`；在模拟器测试 scheme 中启用 Thread Sanitizer 排查竞争；主线程无同步 I/O 或重计算；在 Release 构建上运行 Time Profiler 建立性能基线；从构建日志第一个错误开始排查构建失败；用 OSSignposter 标记自定义性能区间；循环/集合调试使用条件断点。

适用边界 · 注意事项

• 详细的 `.memgraph` 命令行所有权/增长分析和 ETTrace 工作应路由到专门的技能（ios-memgraph-analysis、ios-ettrace-performance），而非本技能。
• MetricKit 挂起诊断（HangDiagnostic 和 iOS 26 兼容性）应参考 metrickit 技能。
• Thread Sanitizer 的设备支持仅限 64 位 macOS 应用；iOS、iPadOS、tvOS、visionOS 和 watchOS 应用需在模拟器中运行 TSan。