所以我使用带有缓存的NSFetchedResultsController的UICollectionView（依赖于Ash Furrow的实现https://github.com/AshFurrow/UICollectionView-NSFetchedResultsController）。一切都很实用，但由于uicollectionviewcontroller代表的冗余循环，我的反应迟钝。
这就是我正在做的事情： 每隔几秒钟，我就会在managedObjectContext中插入一个新实体。每个实体在获取时基于section key属性的值结束于它自己的部分。每个实体具有22个不同的属性，最终在实体部分的22个新单元（行）中呈现。
这是发生的事情： 我的NSFetchedResultsController委托似乎按预期工作（它们捕获单个部分条目）。当我最终运行批量更新时，它仅为新实体调用cellForItemAtIndexPath（如预期的那样）。但是（这是我的问题）UICollectionViewController为每个现有部分循环通过numberOfItemsInSection和sizeForItemAtIndexPath（我有22个新单元格的不同大小的单元格）。这不是缓存的吗？我们不知道这个吗？任何想法为什么会这样？我是菜鸟，所以我误解了一些基本的东西吗？我是否从根本上不正确地实现了collectionView的部分和行？
最终结果是额外的周期变得非常昂贵，因为实体/部分的数量增加，并且ui很快变得过于笨拙而无法接受/可用。
想法？
更新：发现推理
所以我想我需要深入研究在我的委托中使用自定义单元格格式调用的含义。我真的不明白为什么这需要如此昂贵（在每一行上调用它而不仅仅是视图中的那些），但它确实如此。
heightForRowAtIndexPath being called for all rows & how many rows in a UITableView before performance issues?
答案 0 :(得分：0)
所以我想我需要深入研究在我的委托中使用自定义单元格格式调用的含义。我真的不明白为什么这需要如此昂贵（在每一行上调用它而不仅仅是视图中的那些），但它确实如此。