SwiftUI 系列 13｜性能优化：哪些写法会让页面变卡？

SwiftUI 一谈性能，最常出现两种极端判断：

• “SwiftUI 天生就慢”
• “SwiftUI 完全没问题，是你不会写”

这两种说法都太粗。

真实项目里，很多 SwiftUI 性能问题确实不是框架单点缺陷，而是这些东西一起失控：

• 状态更新粒度过大
• 视图层级过深
• 计算放在了频繁刷新路径上
• 列表与图片链路成本过高

所以真正该问的不是“SwiftUI 行不行”，而是：

你的页面是不是让一次小变化，引发了远大于必要范围的重算和重绘。

一、SwiftUI 性能问题最常见的根源，是更新范围太大

很多页面卡，不是因为某个组件重，而是因为：

• 一处局部状态变化
• 却让一大片界面重新参与计算

这在声明式 UI 里尤其重要。
因为你写的不是“改一个控件”，而是“状态变化后重算当前描述”。

如果状态边界和组件边界没立住，小变化就会放大成大范围更新。

二、把高成本计算放在频繁刷新路径上，是最常见的坏味道之一

例如：

• 在 body 里做复杂格式化
• 在视图构建过程中做重数据转换
• 每次刷新都重新拼复杂展示模型

这些事情在数据量小的时候看不出来，一旦页面刷新频繁，代价会被迅速放大。

三、列表和图片几乎总会放大 SwiftUI 的性能问题

因为这两个场景都会让：

• 刷新频率更高
• 视图数量更多
• 主线程压力更大

如果状态粒度又不够细，页面很容易掉帧。

四、结论：SwiftUI 页面变卡，通常不是一个 API 的锅，而是更新粒度、计算时机和视图边界一起失控

如果只用一句话总结，我会说：

SwiftUI 性能问题最常见的根源，不是框架本身“慢”，而是你让状态变化影响范围过大、让高成本计算出现在高频刷新路径上，并且没有把页面边界收住。

所以真正有效的优化方向，通常是缩小影响范围，而不是一上来就怀疑整个框架。