SwiftUI下EnvironmentObject数组更新是否需手动做无变更写入校验

不管是Swift 标准库还是SwiftUI的内置优化机制，都不会自动识别“赋值内容没有实际变化”的操作、自动跳过无效写入来减少UI更新——你要实现的无变更写入过滤逻辑，必须手动实现。 #

具体的机制边界 #

1. Swift 标准库没有内置的值校验逻辑 #

Swift 数组作为值类型，核心性能优化是写时复制（Copy-on-Write, COW），但这套机制的设计逻辑里完全不存在“比对新赋值和原有值是否相等”的环节：

• 只要对数组执行array[i] = newValue的下标赋值操作，不管写入的newValue和原有array[i]的内容是不是完全一致，都会触发COW检查：如果当前数组的底层存储存在跨对象共享，系统会直接拷贝整个底层缓冲区再完成赋值，全程没有值比对的步骤。
• 当数组规模到100万元素级别时，一次无意义的全量数组拷贝的开销，远高于逐元素做值对比的成本。

2. SwiftUI 的通知机制没有内置的内容 diff #

你通过EnvironmentObject注入的数据源，本质是遵循ObservableObject协议的类对象，如果数组属性是被@Published修饰的：

• 只要@Published修饰的数组属性感知到底层存储实例发生了变更（也就是COW机制生成了新的数组存储），会立刻通过objectWillChange向外派发变更通知，全程不会对比新旧数组的内容是否完全一致。
• SwiftUI确实会在收到通知后、执行实际渲染时，对视图的渲染参数做diff来跳过最终的像素绘制，但通知派发、触发所有依赖这个环境对象的视图重新计算body的前置开销已经产生了——尤其是绑定这个数据源的视图数量较多时，这类无意义的重绘计算会带来非常明显的性能损耗。

两种实现方案的实际开销对比 #

• 无校验直接写入的方案：循环遍历100万元素时，哪怕99%以上的元素赋值和原值完全一致，也会持续触发COW检查、生成新的数组存储实例，最终触发@Published的变更通知，引导所有依赖视图进入重绘流程，完全达不到“减少无效UI更新”的优化目标。
• 带手动值校验的方案：逐元素对比新旧值，仅当确实存在值变化时才执行数组写入。整个流程的额外成本仅为100万元素的逐值比对，远低于无差别写入带来的全量数组拷贝、冗余视图重绘开销，完全匹配你的优化目标。

实操提示：你可以在循环里加一个标记位，只要全程没有发现需要更新的元素值，循环结束后直接跳过所有后续的通知逻辑，连第一次COW触发的开销都能省掉。

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