实质上是 UICollectionView 与 NSFetchedResultsController 配合，在去年遇到这个问题时，当时进行了一番尝试无解，找到了俩年前 @ash furrow 的方案，但原来的方案中无法同时处理 section 和 cell 的变化，我针对这个缺陷做了改进，但复杂而且难以使用；后来 @SixtyFrames 修正了这个缺陷，并且优化了原方案的逻辑，几乎不需要改动就可使用。原方案的作者后来停止了维护该方案，并推荐了更优雅的解决方案：JSQDataSourcesKit，使用前提是 iOS 8和 Swift 2.0。
我上周 fork 了这个库，原本还打算给它贡献点这个话题方面的代码，结果发现它已经处理好了，而且代码封装得很好，我目前可写不出这种水平的代码。使用 Swift 有三个月左右了，越来越喜欢这个语言了，最近连 OC 都不会写了。刚开始总会接触到 protocol 的话题，但不是很理解，最近写了几个动画，对 protocol 有点感受了，不过这个库我目前看得有点吃力，不知道为何要那样封装，等三个月再看我的水平是否足够。现成的解决方案是有了，但思路还是值得记录的。
为 NSFetchedResultsController 对象提供 delegate 后，就能够跟踪数据的变化并更新视图了， delegate 对象需要实现下面的方法：
-controllerWillChangeContent:
-controller:didChangeSection:atIndex:forChangeType:
-controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:
-controllerDidChangeContent:
当 NSManagedObjectContext 中对象发生了变化后，上面四个方法除了中间的两个按照变化的情况来调用之外，基本上是按照顺序来调用的。
对于 UICollectionView，来看看解决思路，ash furrow 指出问题的关键在于：
The trick is to queue the updates made through the NSFetchedResultsControllerDelegate until the controller finishes its updates. UICollectionView doesn't have the same beginUpdates and endUpdates that UITableView has to let it work easily with NSFetchedResultsController, so you have to queue them or you get internal consistency runtime exceptions.
那么解决的方法就是在上面中间两个 didChangeXXX 方法中搜集变化的内容，然后在最后的 didChangeContent 里使用 UICollectionView 的 performBatchUpdates: 方法来集中更新 UI。
原方案没有考虑到一些情况而无法处理同时发生了 section 和 cell 变化的情况，比如我的需求是批量操作多个 section 内的 cell，例如，选中不同 section 内的 cell，这包括了某个 section 内的全部 cell 以及其他 section 中部分 cell，然后新建一个 section，如下图：
那么 delegate 将会接受到以下通知，log 里我打印出了动作类型以及位置变化，使用 S 代表了 cell 所在的 section，I 代表 row。
Insert Section at Index: 4
Delete Section at Index: 2
Move Cell from S1I8 -> S4I5
Move Cell from S2I1 -> S4I1
Move Cell from S2I0 -> S4I0
Move Cell from S4I1 -> S4I2
Move Cell from S2I2 -> S4I4
Move Cell from S3I1 -> S4I3
上面的这些变化需要我们在 controllerDidChangeContent: 里先对这些变化进行分类和过滤后再来更新 UI。你需要尝试一些操作来测试 UICollectionView 是怎么判定操作的类型的，依据这个才好对操作进行分类和过滤。
操作类型有这么四种：
NSFetchedResultsChangeInsert
NSFetchedResultsChangeDelete
NSFetchedResultsChangeMove
NSFetchedResultsChangeUpdate
NSFetchedResultsChangeMove 这种操作类型的通知里会包含目标的源位置 fromIndexPath 和新位置 toIndexPath，根据对这种操作类型的处理方式不同，有两种方法来处理和过滤这些变化：
1. @SixtyFrames 的方案：
过滤阶段：
首先对标记为 NSFetchedResultsChangeMove 的操作进行过滤：
- fromIndexPath 的 section 在被删除的 section 集合里并且 toIndexPath 的 section 不在新增的 section 集合里，则被视为 NSFetchedResultsChangeInsert，并将 toIndexPath 纳入该操作类型的集合里。翻译一下就是：从被删除的 section 移动到另外一个已知的 section 被判定为 insert。
上面例子中的没有符合这个条件的。
- fromIndexPath 的 section 不在被删除的 section 集合里并且 toIndexPath 的 section 在新增的 section 集合里，被视为 NSFetchedResultsChangeDelete，并将 fromIndexPath 纳入该操作类型的集合中。意思就是：整个 section 没有被删的而且移动到新 section 的被判定为 delete。
上面的例子中有三条符合： S1I8 -> S4I5, S3I1 -> S4I3, S4I1 -> S4I2。S1I8，S3I1，S4I1 这些 NSIndexPath 被标记为要被删除的目标。
- fromIndexPath 的 section 不在被删除的 section 集合里并且 toIndexPath 的 section 不在新增的 section 集合里，才被视为 NSFetchedResultsChangeMove。意思就是：从一个已知的 section 移动到另外一个已知的 section 才被判定为真正的 move。
上面的例子没有符合条件的。
其次，对标记为 NSFetchedResultsChangeDelete 的操作进行过滤，去除那些目标 section 在被删除的 section 集合里的 NSIndexPath。这么做的原因是，某个 section 要被删除的话，该 section 内的所有 cell 都会被移除，但不用分别删除 section 和删除 cell 这样的重复操作，因此必须把该 section 内的所有 NSIndexPath 过滤掉。
上面的例子中没有 NSIndexPath 被移除。
最后，对标记为 NSFetchedResultsChangeInsert 的操作进行过滤，去除那些目标 section 是新增 section 的 NSIndexPath。
上面的例子里没有属于 NSFetchedResultsChangeInsert 的 NSIndexPath，因此什么也不会移除。
接下来要对上面的过滤结果进行针对性的操作，更新 UI 要按照一定的顺序来，这点在 performBatchUpdates:completion: 的文档里有说明：delete 操作必须在 insert 之前，因为 insert 时的位置是相对于 delete 后再次计算的，这与我们之前看到的 log 恰好是反过来的。
另外，section 的变化会同时处理该 section 内所有 cell 的变化，所有只需要对 section 进行更新即可。
- 先处理 section 的变化：先删除被标记的 section（可能有多个），然后添加被标记的 section（一般情况下只有一个）。
上面的例子 Section 2 被整体删除，然后添加 Section 4。
- 然后处理不在 section 变化范围内的漏网之鱼，处理顺序是，先处理删除，然后是添加，移动和更新操作的顺序无所谓，因为这两个不影响整体的布局。
上面的例子里被判定为 delete 的三个目标将被删除。
至此结束。
2. JSQDataSourcesKit
JSQDataSourcesKit 的方式与上面截然不同，简直有种做奥赛题使用常规方法和特殊方法的区别：把 NSFetchedResultsChangeMove 拆分为先 Delete 再 Insert，这样一来所有的操作只剩下 Delete 和 Insert（Update 不影响大局），因此只需要对搜集的变化进行分类而不需要过滤，而且在处理上不需要依赖特定的顺序。在处理时，需要先处理 object 的变化，再处理 section 的变化。处理 object 的变化时，遇到 Move 操作时，先删除原来的目标，在添加新的目标；而处理 section 的变化时，不处理 Move 操作。
简洁有力！但老实说，除了拆分这个操作明白，后来对变化的处理不明白。
