iOS NSFetchedResultsController插入部分冗餘循環問題

因此，我正在使用UICollectionView和NSFetchedResultsController緩存（靠Ash Furrow的實現https://github.com/AshFurrow/UICollectionView-NSFetchedResultsController）。一切都很實用，但由於看起來像uicollectionviewcontroller代表的冗餘循環，我得到的響應很慢。iOS NSFetchedResultsController插入部分冗餘循環問題

這就是我在做的：每隔幾秒鐘，我就在managedObjectContext中插入一個新的實體。每個實體在獲取時根據section key屬性的值結束於它自己的部分。每個實體有22個不同的屬性，最終以實體部分的22個新單元格（行）呈現。

這就是發生了什麼事情：我的NSFetchedResultsController委託似乎按預期工作（它們捕獲單個部分條目）。當我最終運行批量更新時，它僅爲新實體調用cellForItemAtIndexPath（如預期的那樣）。但（這是我的問題）UICollectionViewController循環遍歷numberOfItemsInSection和sizeForItemAtIndexPath（對於22個新單元格，我有不同大小的單元格）。這不是緩存嗎？我們不知道這個嗎？任何想法爲什麼發生這種情況？我是一個noob，所以我在這裏誤解了一些基本的東西？我是否從根本上錯誤地實現了collectionView的部分和行？

最終的結果是，隨着實體/部分數量的增加以及ui很快變得過於遲鈍以至於無法接受/可用，額外的週期變得非常昂貴。

想法？

更新：推測發現 所以我想我需要深入研究在我的委託中使用自定義單元格格式調用的影響。我不明白爲什麼這需要如此昂貴（不僅僅是在那些視線上的每一行上），而是它。
heightForRowAtIndexPath being called for all rows & how many rows in a UITableView before performance issues?

來源

2013-05-09 jaypee

http://stackoverflow.com/questions/5324205/heightforrowatindexpath-being-called-for-all-row-how-many-rows-in-a- uitablevie – jaypee 2013-05-09 20:56:17

所以我想我需要更深入地研究使用自定義單元格格式在我的委託調用的影響。我不明白爲什麼這需要如此昂貴（不僅僅是在那些視線上的每一行上），而是它。

這SO線程會談一下： heightForRowAtIndexPath being called for all rows & how many rows in a UITableView before performance issues?

來源

2013-05-09 20:59:31 jaypee

需要在每行（即使是tableview以外的那些行）上調用它的原因是它可以知道表視圖contentSize應該有多大。如果不知道表視圖的全部高度，它無法知道顯示滾動條的位置。儘管如此，您可以通過近似高度來提高性能。 – Accatyyc 2013-08-02 08:37:33

iOS NSFetchedResultsController插入部分冗餘循環問題

回答

相關問題