原生 SwiftUI 性能优化要点

在一次大型聊天界面迁移到 SwiftUI 时，滚动卡顿的现象让开发团队几乎陷入僵局。细查后发现，根本原因并非网络延迟，而是视图层级与状态更新的细节处理不当。于是围绕原生渲染管线、状态管理以及布局计算三个维度展开了系统化的调优。

渲染管线的瓶颈

SwiftUI 的渲染过程会在每一次状态变更后重新走一遍 diff‑tree，然后将变更提交给 Core Animation。若在 body 中混入大量计算或创建临时视图层，diff 的代价会呈指数级增长。经验数据显示，单帧渲染时间超过 16 ms 时，即会出现明显的卡顿感。

对图层混合敏感的 UI（如半透明列表）可通过 .drawingGroup() 预合成，GPU 合并次数下降约 30%。
将耗时的字符串拼接或数值格式化搬到 ViewModel，保持 body 只做声明式布局。
使用 @StateObject 替代频繁创建的 @ObservedObject，可避免在同一视图层级上重复实例化。

数据流的调优

Combine 与 SwiftUI 的绑定本质上是一次事件桥接。如果发布者在主线程上进行重算，UI 更新会被阻塞。将后台计算封装为 Future 或 Task，并在完成后通过 DispatchQueue.main.async 触发状态变更，通常能将响应时间压缩到 40 ms 以下。

对列表数据使用 Identifiable 并确保 id 稳定，diff 过程只会比较标识而非整棵树。
在需要局部刷新时，局部视图采用 .equatable() 修饰，SwiftUI 会跳过相等的子树。

布局缓存的技巧

几何读取器（GeometryReader）若在每一次渲染中都重新计算坐标，会导致布局阶段的递归深度翻倍。把坐标信息写入 .preference 并在父视图中一次性消费，可实现“只读一次、缓存复用”。实测表明，复杂卡片页面的帧率从 45 fps 回升至 58 fps。

struct CardView: View {
    @State private var size: CGSize = .zero

    var body: some View {
        VStack {Text("标题")
                .font(.headline)
            // 其他子视图
        }
        .background(
            GeometryReader { geo in
                Color.clear
                    .preference(key: SizeKey.self, value: geo.size)
            }
        )
        .onPreferenceChange(SizeKey.self) { newSize in
            size = newSize   // 只在尺寸变更时更新一次
        }
    }
}

private struct SizeKey: PreferenceKey {
    static var defaultValue: CGSize = .zero
    static func reduce(value: inout CGSize, nextValue: () -> CGSize) {value = nextValue()
    }
}

把这些细节织进日常的 SwiftUI 开发流程，原本需要熬夜排查的性能坑，往往可以在几杯咖啡的时间里一键定位。只要记住：渲染要轻、状态要干、布局要记，代码自然会跑得更顺畅

渲染管线的瓶颈

数据流的调优

布局缓存的技巧

推荐话题