SwiftUI中@FetchRequests使用性能成本及CoreData实操问题咨询

问题1：多视图重复声明FetchRequest的性能问题 #

• 你提到的100条以内的数据量级，无论怎么写都不会产生可感知的性能问题，不需要做针对性的性能优化。
• 早年iOS 14及更早版本中@FetchRequest确实存在重复触发查询、列表滑动卡顿的缺陷，该问题在iOS 15之后的系统版本中已经得到了底层修复，当前@FetchRequest默认采用惰性加载机制，多视图重复声明也不会触发多次全量IO查询，底层会复用查询缓存。
• 通常来说，只有单表数据量超过1万条、且FetchRequest带有复杂计算逻辑的谓词或排序规则时，才可能出现UI卡顿的情况，普通工具类应用的常规数据量完全不需要担心这个问题。

问题2：CoreData对象转自定义结构的实践合理性 #

• 这是当前行业内的通用最佳实践之一，尤其适合中小规模的应用开发。
• CoreData的NSManagedObject是绑定ManagedContext的引用类型，跨视图、跨线程传递很容易出现上下文不一致、野指针崩溃、意外触发视图刷新等问题，转成值类型的自定义struct之后，完美适配SwiftUI的状态管理逻辑，传递、编辑、展示的成本都会低很多。
• 你提到的「展示编辑用自定义结构、仅增删改时同步回CoreData」的逻辑完全可行，也是大部分预算、记账类工具应用的常规实现方案，开发效率和稳定性都会比直接传递NSManagedObject高很多。

CoreData实操最佳实践 #

• 给Entity添加主键约束，避免重复数据插入，降低同步逻辑的复杂度
• 写入、批量查询等重操作放在私有上下文执行，不要占用主上下文资源阻塞UI
• @FetchRequest声明时尽量添加明确的谓词和排序规则，不要全量拉取冗余数据，养成良好的编码习惯
• 如果多视图需要共享同一份查询结果，可以将查询结果存储在全局注入的ObservableObject视图模型中，不需要每个视图重复声明FetchRequest，进一步减少重复代码
• 转自定义结构时按需转换属性即可，不需要递归转换所有关联关系，避免不必要的性能开销

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