そのため、キャッシュ付きの NSFetchedResultsController で UICollectionView を使用しています (Ash Furrow の実装https://github.com/AshFurrow/UICollectionView-NSFetchedResultsControllerに依存しています)。すべてが機能していますが、uicollectionviewcontroller デリゲートの冗長な循環のように見えるため、応答が遅くなります。
これが私がやっていることです: 数秒ごとに、新しいエンティティを managedObjectContext に挿入しています。各エンティティは、フェッチされたときのセクション キー属性の値に基づいて、独自のセクションになります。各エンティティには 22 の異なる属性があり、最終的にエンティティ セクションの 22 の新しいセル (行) に表示されます。
これが起こっていることです: 私の NSFetchedResultsController デリゲートは、期待どおりに動作しているように見えます (単一のセクション エントリをキャプチャします)。バッチ更新を実行すると、新しいエンティティのみに対して cellForItemAtIndexPath が呼び出されます (予想どおり)。しかし（これは私の問題です）、UICollectionViewController は既存のセクションごとに numberOfItemsInSection と sizeForItemAtIndexPath を循環します（22 個の新しいセルに対して異なるサイズのセルがあります）。これはキャッシュされていませんか？私たちはすでにこれを知っていませんか？なぜこれが起こっているのですか？私は初心者なので、ここで何か基本的なことを誤解していますか? collectionView のセクションと行を根本的に正しく実装していませんか?
そして最終的な結果は、エンティティ/セクションの数が増加するにつれて余分なサイクルが非常に高価になり、UI がすぐに驚くほど遅くなりすぎて許容/使用できなくなることです。
アイデア？
更新: 理由が判明
したので、デリゲートでカスタムのセル書式設定呼び出しを使用することの意味をより深く掘り下げる必要があったと思います。なぜこれがそれほどコストがかかる必要があるのか よくわかりません（表示されている行だけでなく、すべての行で呼び出す必要があります）が、そうです。
heightForRowAtIndexPath がすべての行に対して呼び出され、パフォーマンスの問題が発生する前に UITableView に何行ありますか?