用途：端到端审查 SwiftUI 视图性能，从插桩与基线测量到根因分析和具体修复步骤。适用于诊断渲染缓慢、滚动卡顿、CPU/内存占用高等请求。
工作流程：若用户提供代码，先做“代码优先审查”；若只描述症状，先索取最小代码与上下文再做审查；若代码审查无法定论，则引导用户用 Instruments 采集数据。
代码优先审查关注：宽泛状态变更导致的视图失效风暴；列表标识不稳定（id 抖动、每次渲染生成 UUID()）；body 中的重活（格式化、排序、图片解码）；布局抖动（深层嵌套、GeometryReader、preference 链）；未降采样的大图；过度动画的层级。输出可能根因（附代码引用）、修复与重构建议，必要时给出最小复现或插桩建议。
引导采集：在 Instruments 中使用 SwiftUI 模板（Release 构建），复现具体交互（滚动、导航、动画），捕获 SwiftUI 时间线与 Time Profiler，导出或截图相关泳道与调用树，并索取设备/系统/构建配置。
分析与修复：优先排查上述常见元凶，用 trace/日志证据总结；修复手段包括收窄状态作用域（@State/@Observable 靠近叶子视图）、稳定 ForEach 与列表标识、把重活移出 body（预计算、缓存、@State）、对昂贵子树使用 equatable() 或值包装、渲染前降采样图片、降低布局复杂度或使用固定尺寸。
常见代码异味：body 中新建 NumberFormatter/MeasurementFormatter；每次 body 求值都执行过滤的计算属性；在 body 或 ForEach 中排序/过滤；用 id: .self 等不稳定标识；主线程解码图片；可观察模型依赖过宽导致更新扇出过大。
验证：让用户用相同方式重新采集并与基线对比，汇总 CPU、掉帧、内存峰值差异。输出包括指标对比表（如有前后数据）、按影响排序的主要问题、修复方案与预估工作量。参考资料由用户提供时放入 references/，包括 Instruments 优化、SwiftUI 性能理解与改进、应用卡顿理解、WWDC23 相关文档。限制：具体命令、平台与收费信息暂未提供。