1

450.000 レコードのコアデータがあります。

uitableview で表示するには、NSFetchedResultsController を使用しています。動作しますが、大きな問題があります。

NSFetchedResultsController の開始が機能する前 に、 performFetchを呼び出す必要があります。 私の場合、この関数は約 2 ～ 3 分で機能します。その後、問題なく UITable にデータを表示できます。しかし、その2〜3分で私は死ぬ:(

それほど悪くはありませんが、このテーブルで検索する必要もあります。そのため、検索のために、述語を変更し、performFetch:を呼び出して、再び約 2 ～ 3 分待つ必要があります。

とにかくperformFetch:を高速化する方法はありますか? または、少なくとも誰かがperformFetch:を呼び出さずに検索を行う方法を教えてくれますか?

4

2 に答える 2

3

わずか 450.000 レコードを取得するには、2 ～ 3 分では明らかに長すぎます。述語で文字列を解析していますか? これらの最適化戦略を使用したことを確認してください。

  • 微調整してフェッチを最適化しますfetchBatchSize。(いくつかの設定を試して、データ型に最適なものを確認してください)。
  • セクション ヘッダーの複雑なクエリは避けてください。関係のいくつかの属性を使用してセクションの見出しを計算している場合は、アプローチを再検討してください。セクション情報を保持するエンティティを取得し、そこから各セクションの行を埋める方がよい場合があります。
  • 検索およびソートに使用するフィールドに索引を付けましたか?
  • 可能な限り、モデルで定義されたフェッチ リクエスト テンプレートを使用します。これにより、処理が大幅に高速化されます。

検索に関しては、これが私にとってうまくいった戦略です：

  • 数回のキーストローク (たとえば 2 回) の後にのみ検索に反応します。
  • 有効なキーストロークの後、たとえば 0.2 秒でタイマーを開始します。タイマーが起動する前に別のキーストロークがなかった場合にのみ、新しいフェッチを開始します。
  • バックグラウンドで取得します。フェッチが完了したら、メイン スレッドでテーブル ビューをリロードします。
  • スケジュールされた検索フェッチの配列を維持します。スケジュールされたフェッチが UI によってキャンセルされた場合 (別のキーストロークなど)、開始しないでください。
  • 大文字と小文字を区別せず、ダイアクリティカルを区別しない検索は非常にコストがかかるため、使用しないでください。可能であれば、単語/名前の先頭から検索してください。必要に応じて、Apple の WWDC12 ビデオで提案されているように、別のエンティティで検索する単語 (簡体字、小文字) だけでインデックスを作成します。
于 2013-03-29T13:42:09.160 に答える