私は最近、UITableViewController
CoreDataを介して最大8000行を管理していたものを持っていました。データはNSFetchedResultsController
;で管理されていました。NSFetchedResultsController
で使用しているかどうかはわかりませんがNSFetchRequest
、Core Dataを介して入力されたテーブルを表示している場合は、それを強くお勧めします。
とは言うものの、フェッチとレンダリングのパフォーマンスを向上させるために作成するときにできる調整はたくさんあります。NSFetchRequest
これがパフォーマンスのボトルネックだと思います。テーブルの初期レンダリングが高速になり、ユーザーがテーブルをスクロールするときに追加のフェッチが実行されるように、行のバッチをフェッチできます。
[fetchRequest setFetchBatchSize:25];
パフォーマンスチューニングとコアデータに関するAppleのガイドを読むことをお勧めします。
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdPerformance.html
Instrumentsを使用しているので、(上記のリンクに従って)Core Dataキャッシュのミス、フェッチ、および保存も確認してください。それはあなたに時間が費やされている場所の指標を与えるかもしれません。
cellForRowAtIndexPath:
ビューがロードされたときとユーザーがテーブルビューをスクロールしたときの行数を確認するなど、ブレークポイントテーブルメソッドを設定してみることもできます。
また、次のように設定しました。これにより、私の状況でパフォーマンスが向上したようです。
[fetchRequest setShouldRefreshRefetchedObjects:YES];
[fetchRequest setReturnsObjectsAsFaults:NO];
Re:欠点、これがAppleのNSFetchedRequest
ドキュメントに書かれていることです:
デフォルト値はYESです。結果タイプ(resultTypeを参照)がNSManagedObjectIDResultTypeの場合、オブジェクトIDにはプロパティ値がないため、この設定は使用されません。返されたオブジェクトからプロパティ値にアクセスする必要があることがわかっている場合は、returnsObjectsAsFaultsをNOに設定して、パフォーマンスを向上させることができます。
コアデータは非常に複雑になる可能性があります。1つだけ使用する場合は、NSManagedObjectContext
Erica'Sadunの優れたiPhoneDeveloper'sCookbookからの「コアデータヘルパー」を確認してください。Core Dataで多くのことを行う場合は、MagicalRecord
ネストされたマージNSManagedObjectContexts
、複数のスレッドの処理など、多くの面倒な作業を処理できるものを強くお勧めします:https ://github.com/magicalpanda/MagicalRecord
お役に立てれば!