SwiftUI 代码跟踪诊断与优化

问题：SwiftUI 性能问题为什么难查

SwiftUI 的声明式渲染模型在带来简洁 API 的同时，也让性能问题变得难以定位。一次看似普通的视图更新可能在背后触发大量冗余计算；主线程上的某个同步阻塞会造成界面冻结，但堆栈里往往看不出直接原因。开发者通常只能靠经验猜测，或者反复对比代码 diff，却很难拿到客观的执行时间数据。Instruments 提供了 Time Profiler、Hangs、Hitches 等 lane，但手动打开 trace、逐个 lane 切换分析，既耗时又容易遗漏跨 lane 的关联线索。

技能如何工作

该技能围绕 Instruments trace 提供了一套从采集到解读的完整流程：

• 采集 trace：通过封装 xctrace 的 Python 工具链直接录制新的 .trace 文件，无需手动在 Instruments 界面操作。
• 多 lane 解析：scripts/instruments_parser/ 下按 lane 拆分为独立模块，分别处理 time_profiler、hangs、hitches、swiftui、causes 等通道的数据。
• 跨 lane 关联：将不同 lane 的命中结果进行交叉比对，定位导致卡顿或掉帧的真正根源，而非只看单个线程的耗时排名。
• Markdown 报告：解析结果会渲染为结构化的 Markdown 摘要，方便在代码审查或团队讨论中直接引用。

在代码实现阶段，技能会依据当前 Apple 推荐的模式给出实现或重构建议；在审查阶段，则结合 trace 数据判断是否存在过度更新或昂贵的视图刷新。

适用边界与注意点

• 仅适用于 iOS / Xcode 项目，依赖 xctrace 命令行工具，需在 macOS 环境下运行。
• 上游文档提到需要 Sosumi MCP 可用，实际使用时需确认环境已配置。
• 在新的 iOS 或 Xcode 版本发布后，建议先运行该技能刷新已弃用的 API 参考，避免按过期模式编写代码。