0

Core Dateに支えられ、UITableViewにデータを表示しているiPadアプリケーションがあります。また、カスタムセルを使用して、セルごとに複数のULabelを表示しています。

正常に動作しますが、tableViewに多くのアイテムが追加されると、動作が遅くなり、少し遅く感じます。現在、NSFetchedResultsControllerを使用していません。データに変更が加えられるたびに、ivar配列のデータは次のように更新されます。

items = [self.managedObjectContext executeFetchRequest:allItems error:&error];

Itemsは、tableViewがすべてのデータを取得し、すべてが更新および機能する配列です。しかし、それは超高速ではありません！私のアプローチに問題はありますか？NSFetchedResultsControllerが唯一の方法ですか？デリゲート/データソースメソッドで行われている処理はそれほど重くはありません。基本的に、配列から値を引き出し、UILabelsに設定します。

すべてが今必要な方法で機能します。応答性を高める必要があります。

ありがとう

4

2 に答える 2

3

楽器を使用します。いつも。永遠に。

ほとんどの場合、FRCが行うバッチ処理と前向きな考え方の一部を少なくとも模倣する必要があります。ただし、常にリレーションシップにアクセスしていることに気付く場合があり、それらをプリフェッチすると問題が解決する場合があります。

すべてがハードでコールドな数字のない純粋な憶測です...これはInstrumentsから簡単に入手できます。

編集

セルの描画は遅くなる可能性があります。ただし、これは、オブジェクトの数が少ない場合にも観察できます。通常、データが他のセルと大幅に異なる場合にのみ、描画によってパフォーマンスが低下します。

もちろん、これはセルの再利用を使用していることを前提としています。セルを再利用していない場合は、すべての賭けが無効になります。ただし、セルの再利用では、通常、オブジェクトの数に関連するパフォーマンスは表示されません。

繰り返しますが、機器を実行します。それはあなたの問題がどこにあるかを知る唯一の方法です。他のすべては時間の無駄です。

于 2012-08-25T19:47:11.817 に答える
1

NSFetchedResultsController間違いなく強くお勧めします。パフォーマンスの問題に対処できる可能性があるだけでなく、あらゆる種類の便利な機能（デリゲートプロトコルなど）や舞台裏の最適化にもつながります。

これらの最適化の中で最も重要なのは、おそらくメモリ管理でしょう。（配列内のすべてのアイテムを含む）ソリューションは、設計上の選択としては不適切であり、大量のレコード/行に拡張できないようです。

そうは言っても、セルを描画するときは通常の最適化戦略を使用してください。

  • ラベルやその他のサブビューの使用を最小限に抑えます。
  • 透明な背景を使用しないでください。
  • 1.0以外のアルファは使用しないでください。
  • セル内のサブビューが重ならないようにするなど。

drawRectそれでもパフォーマンスが問題になる場合は、UITableViewCellサブクラスのをオーバーライドして、自分でコンテンツを描画する必要があります。

于 2012-08-25T19:48:23.340 に答える