SwiftUI 应用渲染慢/卡顿/CPU 高时…

当 SwiftUI 应用出现渲染慢、滚动卡顿、CPU/内存占用高、视图更新过多或布局抖动时，用代码优先审查加运行时剖析来诊断和修复。

适用场景

解决思路

1. 先对症状分类：渲染慢、滚动卡顿、CPU 高、内存增长、卡死或视图更新过多。
2. 若有代码，先用 references/code-smells.md 做代码优先审查。
3. 若无代码，向用户索取最小可用切片：目标视图、数据流、复现步骤和部署目标。
4. 若代码审查无法定论或需要运行时证据，用 references/profiling-intake.md 引导用户做 Instruments 剖析。
5. 用 references/report-template.md 汇总可能原因、证据、修复方案和验证步骤。
6. 信息收集阶段收集：目标视图或功能代码、症状与精确复现步骤、数据流（@State、@Binding、环境依赖、可观察模型）、问题出现在真机还是模拟器、以及是 Debug 还是 Release 下观察到的。
7. 让用户对问题分类：CPU 峰值或耗电、滚动卡顿或掉帧、内存高或图片压力、卡死或交互无响应、视图更新过多或范围过广。
8. 代码审查重点检查：宽泛观察或环境读取导致的失效风暴、列表和 ForEach 中不稳定的 identity、body 或视图构建器中的重计算、复杂层级/GeometryReader/preference 链导致的布局抖动、主线程上的大图解码或缩放、应用范围过广的动画或过渡。
9. 代码审查后给出：带代码引用的可能根因、建议的修复与重构、必要时提供最小复现或埋点建议。
10. 若代码审查无法解释问题，索取运行时证据：SwiftUI 时间线和 Time Profiler 调用树的 trace 导出或截图、设备/系统/构建配置、被剖析的确切交互、以及对比改动前后的指标。
11. 分析诊断时：把证据映射到最可能的类别（失效、identity 频繁变化、布局抖动、主线程工作、图片开销、动画开销），按影响而非解释难度排序问题，区分代码层面的怀疑与 trace 支撑的证据，并指出剖析仍不充分之处及还需哪些额外证据。
12. 修复时采取针对性措施：收窄状态作用域、减少宽泛观察的扇出；稳定 ForEach 和列表的 identity；把重活从 body 移到由输入更新的派生状态、模型层预计算、记忆化辅助函数或后台预处理，@State 只用于视图自有状态而非任意计算的临时缓存；仅当相等性比较比重算子树更便宜且输入真正是值语义时才用 equatable()；渲染前对图片降采样；降低布局复杂度或尽量使用固定尺寸。
13. 验证时让用户用同样的采集方式重跑并与基线指标对比，若提供数据则汇总差值（CPU、掉帧、内存峰值）。
14. 输出：简短指标表（有前后对比则附上）、按影响排序的 top 问题、带预估工作量的修复建议。
15. 参考资源：references/profiling-intake.md（剖析信息收集清单）、references/code-smells.md（代码坏味道与修复模式）、references/report-template.md（审计输出模板）、references/optimizing-swiftui-performance-instruments.md、references/understanding-improving-swiftui-performance.md、references/understanding-hangs-in-your-app.md、references/demystify-swiftui-performance-wwdc23.md。

适用边界 · 注意事项

• 非 SwiftUI 应用或非性能类问题（如功能 bug、UI 设计问题）不适用。
• 没有代码也没有运行时证据时，无法给出可靠诊断，需先补齐最小切片或剖析数据。
• 仅凭代码审查无法解释症状时，不应臆断根因，必须转向 Instruments 剖析获取证据。