UITableViewControllerが処理できるデータの量はどれくらいですか？

Question

私はUITableViewControllerが処理できるデータの大きさを知りました...私は、テーブルビューの各セルでデータを表現するために配列を使用することがほとんどです。

配列にかなりの量の文字列とある種の整数が含まれているとします（その行を選択すると、その行のIDとして渡されます）。配列の各要素は、文字列の場合は4バイト、整数の場合は4バイトです。私は単一のtableviewで持つことができる最大の要素を計算する方法はわかりません。

しかし、これは、iOSデバイスが非常に大きなデータ（たとえば2000-3000行）を処理できるとしても、そのような大量のデータをユーザーに提示するのは良い設計の決定でしょうか？ Appleの連絡先アプリでは、一度にたくさんの連絡先のデータを表示しながら、右側にA-Zのクイックジャンプを表示します。 Twitterアプリケーションでは、数百のツイートがユーザーに表示されます（ただし、1日以上経過していれば途中で途切れることがあります）。

このように大量のデータをユーザーに提示するには、どのような方法が最適ですか？

Answer 1

すべてのデータを同時にメモリに保存する必要はありません。確かに、配列はそれを行う最も簡単な方法ですが、多くの行（これはあなたがこの質問をしたためだと思います！）を使うつもりなら、最近使用された値をキャッシュする必要があります。

しかし、それだけではあなたが考慮する必要はありません。

テーブルが最初に表示されるときに、デリゲートにいくつのセクションがあるかを尋ねると、最初に表示されないセクションであってもセクションの数がセクションごとに尋ねられます。これは、あなたが持っているセクションが多いほど、テーブルの表示時間が長くなることを意味します。

私のアプリケーションのバージョン1.xと2.xの大きな変更の1つは、メイン画面に表示されるセクションの数を減らすことでした。私はまた、ビューが見えるようになるたびにそれらを計算する必要がないように、メタデータ（各セクションの行数など）も保存しました。これは、はるかに多くの行を処理することができ、ボリュームが増加してもはるかに速くなったことを意味しました。

Answer 2

私は大量のデータの場合、すべてのデータがRAMの配列ではなく、フラッシュドライブ（コアデータまたはsqlite）のベースにあると思います。
目に見える行のデータだけがメモリにあります。

Answer 3

UITableViewは表示されているデータのみを必要とするため、ただし、デバイスの制限は、すべてのデータをメモリに保存できない可能性があることを意味します。この場合、コアデータを使用してメモリに保存されているデータ量を最小限に抑えることができます。 NSFetchedResultsControllerはあなたの友人です。

UIに関する限り、テーブルの右側に表示されるインデックスバーは、大きなデータセットを可能にすると思います。ただし、3000アイテムの例を考えてみましょう。 25のインデックスポイント（例えばA、B、C、Dなど）がある場合、これはインデックスポイント間の120アイテムになります。この場合、厳密なアルファベット順のインデックスを使用することを控えておくことをお勧めします。なぜなら、その分布は非常に不均一であるからです。私はデータを解析し、各120番目のアイテムの最初の2〜3文字を持っています。これを念頭に置いて、私は3000がすばらしいUXではないと思います。