4

アプリでコア データを使用して、50,000 個以上のオブジェクトを持つエンティティを格納しています。これをテーブルビューで NSFetchedResultsController とペアにしました。セルの再利用により、テーブル ビューは正常に機能しますが、私の最大の問題は、実際のデータベースをキューしてデータセットを取得することです。

テーブルビューを最初にロードするとき、データベースからのすべての結果が必要です。単一のソート記述子でデフォルトのフェッチ要求を使用しており、batchSize を 1,000 に設定しています。iPad 2 では、このクエリが完了するまでに最大15 秒かかります。また、検索がキャンセルされた後にこのクエリを実行する必要があるため、全体的にアプリが使用できなくなります。私の推測では、CD はまだこれらすべての結果を解決するか、セクションなどをセットアップする必要があります。新しい行が常に追加されたり、並べ替え順序が変更されたりするという意味で、コンテンツは非常に動的でもあります。そのため、キャッシュの利点は限られています。

fetchRequest で fetchLimit を使用してから、いくつかの基本的なページングを実装するのが最善の選択肢であると考えています。テーブルビューが最後までスクロールすると、結果の次の「ページ」が取得されますか? このアプローチに関する私の唯一の問題は、sectionIndex を失い、それを回避する方法が考えられないことです。

誰かがアイデアを持っているか、すでにこの問題に対処していますか?

4

2 に答える 2

2

s.newave、

行の高さは可変ですか? その場合、テーブル ビューは各高さを計算するように要求し、それによりすべての行がフェッチされます。15 秒は、50,000 個のアイテムをフェッチするのに不当な時間ではありません。

より大きな問題は、デザインを変更したくないというあなたの声明です。率直に言って、50K アイテムのテーブルビューは役に立ちません。CD が遅いからではなく、そうではないので、設計を変更する必要があります。設計が実用的に使用できないためです。

アンドリュー

PS fetched results コントローラーは、主流のアプリケーション向けに設計されています。50K のテーブル ビューは主流のアプリではありません。どうしても 50K のテーブル ビューの設計を維持する場合は、独自のコントローラーを作成する必要があります。

于 2013-07-17T19:53:22.687 に答える