iOS NSFetchedResultsController 插入节冗余循环问题答案

【问题标题】：iOS NSFetchedResultsController Insert Section Redundant Cycling IssueiOS NSFetchedResultsController 插入节冗余循环问题
【发布时间】：2013-05-03 09:47:33
【问题描述】：

所以我使用带有 NSFetchedResultsController 的 UICollectionView 和缓存（依靠 Ash Furrow 的实现 https://github.com/AshFurrow/UICollectionView-NSFetchedResultsController）。一切正常，但由于 uicollectionviewcontroller 代表的重复循环，我的响应速度很慢。

这就是我正在做的事情：每隔几秒钟，我就会在 managedObjectContext 中插入一个新实体。每个实体在获取时都会根据部分键属性的值进入自己的部分。每个实体都有 22 个不同的属性，最终在实体部分的 22 个新单元格（行）中呈现。

这是正在发生的事情：我的 NSFetchedResultsController 委托似乎按预期工作（它们捕获单个部分条目）。当我最终运行批量更新时，它只为新实体调用 cellForItemAtIndexPath（如预期的那样）。但是（这是我的问题）UICollectionViewController 循环遍历每个现有部分的 numberOfItemsInSection 和 sizeForItemAtIndexPath （我为 22 个新单元格设置了不同大小的单元格）。这不是缓存吗？我们不是已经知道了吗？任何想法为什么会发生这种情况？我是菜鸟，所以我在这里误解了一些基本的东西吗？我是否从根本上错误地实现了 collectionView 的部分和行？

最终结果是，随着实体/部分数量的增加，额外的周期变得非常昂贵，并且用户界面很快变得过于缓慢而无法接受/可用。

想法？

更新：找到原因 所以我想我需要更深入地研究在我的委托中使用自定义单元格格式调用的含义。我真的不明白为什么这需要如此昂贵（在每一行都调用它，而不仅仅是视图中的那些），但确实如此。
heightForRowAtIndexPath being called for all rows & how many rows in a UITableView before performance issues?

【问题讨论】：

stackoverflow.com/questions/5324205/…

标签： ios uicollectionview nsfetchedresultscontroller

【解决方案1】：

所以我想我需要更深入地研究在我的委托中使用自定义单元格格式调用的含义。我真的不明白为什么这需要如此昂贵（在每一行都调用它，而不仅仅是在视图中），但确实如此。

这个 SO 线程谈论它： heightForRowAtIndexPath being called for all rows & how many rows in a UITableView before performance issues?

【讨论】：

需要在每一行（甚至是tableview之外的行）上调用它的原因是它可以知道table view contentSize 应该有多大。如果它不知道表格视图的完整高度，它就无法知道在哪里显示滚动条。不过，从 iOS 7 开始，您可以近似高度以提高性能。