NSFetchedResultsController和NSDiffableDataSourceSnapshot有什么区别？

我们通常在UIDiffableTableView场景下对比的两种更新方案分别是：UITableView原生手动行操作、DiffableDataSource快照更新，二者的核心差异和使用方式如下：

核心差异 #

• 定位逻辑不同
  手动更新完全基于IndexPath定位要操作的行，一旦操作前有其他增删操作导致IndexPath变化，很容易出现操作错行的问题，需要开发者自行维护IndexPath的正确性。
  快照更新基于数据item的Hashable唯一标识定位元素，完全不需要关心IndexPath的动态变化，只要目标item的唯一标识不变，就不会出现操作错行的问题。
• 数据同步逻辑不同

  手动更新是命令式更新逻辑，要求你必须先修改自己维护的数据源数组，再调用对应的行列更新方法，数据源变更的数量、顺序必须和UI操作严格一一对应，一旦不匹配会直接抛出崩溃。
  快照更新是声明式更新逻辑，你只需要构造出更新后完整的数据源快照，系统会自动计算新旧快照的差异，自动执行对应的增、删、改、移动操作，不需要手动维护数据源和UI操作的对应关系，几乎不会出现数据不一致导致的崩溃。

• 动画处理逻辑不同
  手动更新的动画需要自行控制参数，多步操作要实现连贯动画必须包裹在performBatchUpdates闭包中，处理复杂的多元素交叉变更时很容易出现动画错乱。
  快照更新默认自动计算所有差异的过渡动画，只要animatingDifferences参数传true就会自动播放流畅的连贯动画，不需要手动处理动画顺序。
• 行重载逻辑不同
  手动调用reloadRows(at:with:)会直接触发对应位置cell的重用刷新，本质是将对应cell当做全新元素重新配置，会触发完整的cell生命周期回调。
  快照更新默认只会比对数据模型的Hash和Equatable结果，如果模型的唯一标识和内容没有变化，哪怕你重新给快照赋值了相同的模型，Diffable也会判定该元素无变化，不会刷新对应cell；如果要主动刷新某行，需要调用快照的reloadItems(_:)方法标记目标元素。
• 使用成本不同
  手动更新无额外学习成本，适合更新逻辑单一的简单列表场景。
  快照更新要求数据模型必须实现Hashable协议，需要理解快照的构造逻辑，适合多数据源动态变化的复杂列表场景。

各自使用方式 #

手动行操作（不推荐在DiffableDataSource场景下使用） #

注意：如果已经接入UITableViewDiffableDataSource，绝对不要混用手动更新和快照更新，二者的数据源管理逻辑完全独立，混用必然会出现数据不一致崩溃。
使用步骤：

1. 先修改自行维护的数据源数组，以删除行为例：

dataArray.remove(at: indexPath.row)

2. 包裹在performBatchUpdates中执行对应的行操作：

tableView.performBatchUpdates {
    tableView.deleteRows(at: [indexPath], with: .automatic)
} completion: { _ in
    // 处理更新完成后的逻辑
}

适用场景：仅适合未使用DiffableDataSource、列表逻辑极简单、更新操作极少的场景。

快照更新（UIDiffableTableView推荐首选） #

新增行

// 读取当前最新的快照
var snapshot = dataSource.snapshot()
// 在指定位置插入新的item
snapshot.insertItems([newItem], afterItem: existingItem)
// 应用快照触发UI更新
dataSource.apply(snapshot, animatingDifferences: true)

删除行

var snapshot = dataSource.snapshot()
// 传入要删除的item即可，不需要关心对应的IndexPath
snapshot.deleteItems([itemToDelete])
dataSource.apply(snapshot, animatingDifferences: true)

重载行

var snapshot = dataSource.snapshot()
// 标记要重载的item，系统会自动刷新对应的cell
snapshot.reloadItems([itemToReload])
dataSource.apply(snapshot, animatingDifferences: true)

适用场景：所有使用UITableViewDiffableDataSource的场景，不管列表逻辑多复杂都优先选择该方案，崩溃率远低于手动更新。

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