1

5 つのタブを持つタブ バー コントローラーがあります。各タブには、テーブル ビュー コントローラーがあります。そのうちの 2 つは NSFetchedResultsControllers です。

ユーザーがテーブル ビュー内の項目をタップすると、その項目は最初に履歴に保存され、次にセグエされて表示されます。これらの NSFetchedResultsControllers の 1 つは、表示された項目の履歴を日付順に表示します。

これらの NSFetchedResultsControllers のいずれも遅延インスタンス化されていない場合、パフォーマンスは良好です。

13:41:50.485 Saving to history…
13:41:50.487 CoreData: sql: BEGIN EXCLUSIVE
13:41:50.490 CoreData: sql: UPDATE ZSLBOOK SET ZDATEADDEDTOHISTORY = ?, Z_OPT = ?  WHERE Z_PK = ? AND Z_OPT = ?
13:41:50.495 CoreData: sql: COMMIT
13:41:50.511 Saved

しかし、履歴の表示を担当する NSFetchedResultsControllers がインスタンス化された後、速度が劇的に低下し、1 ～ 2 秒かかり (さらに次のビューをレンダリングする)、アプリがハングしたように見えます。

13:42:08.750 Saving to history…
13:42:08.752 Will change
13:42:08.753 Object changed
13:42:09.579 Did change
13:42:09.594 CoreData: sql: BEGIN EXCLUSIVE
13:42:09.596 CoreData: sql: UPDATE ZSLBOOK SET ZCOVERIMAGE = ?, ZDATEADDEDTOHISTORY = ?, Z_OPT = ?  WHERE Z_PK = ? AND Z_OPT = ?
13:42:09.619 CoreData: sql: COMMIT
13:42:09.637 Saved

何が起こっているのかを知るために、履歴を更新するためのコードを次に示します。

- (void)addToHistory
{
    NSLog(@"Saving to history…");
    self.book.dateAddedToHistory = [NSDate date];
    NSError *error;
    [self.managedObjectContext save:&error];
    NSLog(@"Saved");
}

ログ メッセージは、次のメソッドで呼び出されます。

controllerWillChangeContent ("Will change")
controller:didChangeObject ("Object changed")
controllerDidChangeContent ("Did change")

NSFetchedResultsController は標準で実装されています。少数の行 (5 ～ 10 行) しかない場合でも、パフォーマンスが低下します。コア データは問題ありません (ログからわかるように非常に高速です)。バッチ サイズを 20 に設定し、インデックスなどを設定しました。したがって、問題は NSFetchedResultsController のどこかにあります。

可能性の 1 つは、TVC のフェッチ結果コントローラー デリゲートを nil に設定することです。ただし、更新を管理し、行を選択して最後の位置までスクロールするのは非常に困難です (データをリロードする必要があるため)。

問題の原因となっている可能性のあるアイデアはありますか? 膨大な数の行を持つテーブルが一瞬で読み込まれて表示されるため、このパフォーマンスが規則的であるとは思えません。

4

1 に答える 1

0

無料の Sensible TableView フレームワークを使用すると、NSFetchedResultsController の使用を完全に回避できます。フレームワークは自動的にデータをフェッチし、すべての詳細ビュー UI と関係ビューの生成を含め、テーブル ビューに表示します。私の経験では、これは過去に NSFetchedResultsController を使用するよりもはるかに効率的でした。

于 2013-03-27T22:56:11.073 に答える