如何提升macOS平台上SwiftUI Picker的运行性能？

性能问题成因 #

• macOS端SwiftUI默认样式的Picker展开时会一次性初始化所有条目视图，同时执行全量的视图diff、tag哈希匹配计算，400+条目叠加后就会出现明显卡顿。而原生AppKit的NSPopUpButton是懒加载机制，仅渲染可视区域的条目，所以展开速度极快。
• 你当前使用UUID()作为数据模型的id，虽然保证了唯一性，但相比业务固定唯一字段（如alpha3B）会增加不必要的哈希计算开销，同时如果模型实例发生重建会触发不必要的视图重绘。
• 直接将整个结构体作为tag参数传入，相比用字符串类型的唯一编码作为tag，哈希匹配的计算成本更高。

优化方案 #

1. 优先更换Picker样式（成本最低，收益最高） #

macOS端SwiftUI提供的.menu样式的Picker底层直接桥接原生NSMenu实现，采用懒加载机制，不需要修改过多代码就能达到和原生NSPopUpButton几乎一致的性能：

struct ISO639Picker: View {
  @Binding var selection: ISO639LanguageCode
  var body: some View {
    Picker("", selection: $selection) {
      ForEach(codeSet.codes) { code in
        Text(code.alpha3B).tag(code)
      }
    }
    .pickerStyle(.menu) // 仅需添加这一行即可
  }
}

2. 优化数据模型的唯一标识 #

将模型的id替换为业务固定唯一的alpha3B字段，避免UUID带来的额外开销和不稳定问题：

public struct ISO639LanguageCode: Hashable,Identifiable {
  // 替换原有UUID id，用业务唯一编码作为id
  public var id: String { alpha3B }
  public var alpha3B: String
  public var alpha3T: String
  public var alpha2: String
  public var name: String
  public var family: String
}

3. 优化tag匹配效率 #

如果可以调整绑定类型，将selection改为绑定alpha3B字符串，tag也同步使用alpha3B，大幅降低哈希匹配的计算成本：

struct ISO639Picker: View {
  @Binding var selection: String // 绑定alpha3B字符串
  var body: some View {
    Picker("", selection: $selection) {
      ForEach(codeSet.codes) { code in
        Text(code.alpha3B).tag(code.alpha3B)
      }
    }
    .pickerStyle(.menu)
  }
}
// 外部需要获取完整结构体时，可通过alpha3B从codeSet中快速查找

4. 兜底方案：封装原生NSPopUpButton #

如果上述方案仍无法满足需求，可以直接用NSViewRepresentable封装原生NSPopUpButton，完全复用AppKit的实现，性能和迁移前完全一致。

内容的提问来源于stack exchange，提问作者altimes