所以我使用带有缓存的 NSFetchedResultsController 的 UICollectionView （依靠 Ash Furrow 的实现https://github.com/AshFurrow/UICollectionView-NSFetchedResultsController）。一切正常，但由于 uicollectionviewcontroller 代表的重复循环，我的反应迟缓。
这就是我正在做的事情：每隔几秒钟，我就会将一个新实体插入到 managedObjectContext 中。每个实体在获取时都会根据部分键属性的值进入自己的部分。每个实体都有 22 个不同的属性，最终在实体部分的 22 个新单元格（行）中呈现。
这就是正在发生的事情：我的 NSFetchedResultsController 委托似乎按预期工作（它们捕获单个部分条目）。当我最终运行批量更新时，它只为新实体调用 cellForItemAtIndexPath（如预期的那样）。但是（这是我的问题）UICollectionViewController 循环遍历每个现有部分的 numberOfItemsInSection 和 sizeForItemAtIndexPath （我为 22 个新单元格设置了不同大小的单元格）。这不是缓存吗？我们不是已经知道了吗？任何想法为什么会发生这种情况？我是菜鸟，所以我在这里误解了一些基本的东西吗？我是否从根本上错误地实现了 collectionView 的部分和行？
最终结果是，随着实体/部分数量的增加，额外的周期变得非常昂贵，并且 ui 很快变得过于缓慢而无法接受/可用。
想法？
更新：发现推理
所以我想我需要更深入地研究在我的委托中使用自定义单元格格式调用的含义。我真的不明白为什么这需要如此昂贵（在每一行都调用它，而不仅仅是视图中的那些），但它确实如此。
在性能问题之前，所有行都调用 heightForRowAtIndexPath 以及 UITableView 中有多少行？