私はiPhoneアプリケーションを構築しています。データベースには5000レコードがあります。その中で私はアプリに50個しか表示していません。しかし、50行のデータを表示しているのに、最初にiPhoneビューで5000個の空のセルを作成した場合、メモリの問題はありますか?
3 に答える
iPhoneのメモリ容量には限りがあるため、そのビューに必要なデータのみを表示するように常に注意する必要があります。無限スクロールを実装できます。スクロールによって画面の下部に到達すると、イベントがトリガーされ、次の25〜50レコードが読み込まれます。
http://nsscreencast.com/episodes/8-automatic-uitableview-paging
テーブルを処理する標準的な方法ですぐにわかることの1つは、モデルのサイズ(つまり、作成する行の数)に関係なく、実際に作成される行はほんの一握りであるため、メモリフットプリントは残ります。低い。
本質的に、UITableViewは最初に画面一杯の行を作成してレンダリングします(さらに、適切な測定のためにさらにいくつかの行を作成します)。下にスクロールし始めると、コントローラーは新しい行を描画する必要があることを認識します。ただし、テーブルの上からの行が表示されなくなったこともわかります。したがって、まったく新しいセルを作成するのではなく、表示されなくなったセルの1つを取得して、新しい情報で再構成するだけです。テーブルにいくつの行があっても、それらの少数のセルだけがメモリに存在します。
したがって、あなたの場合、メモリのボトルネックは、セル構成を供給しているモデルである可能性があります。5000行すべてを一度にメモリにロードした場合、処理が遅くなり、メモリを消費する可能性があります。しかし、手元に助けがあります。テーブルコントローラから、基本的に* n*番目の行を設定することを通知するヒントを取得します。したがって、モデルは事実上、よりターゲットを絞って、必要なデータのみをロードできます。たとえば、15行目がレンダリングされていることがわかっているので、モデル全体を事前にロードするのではなく、データベースから15行目を取得します。
これは、ページングを必要とせずに5000行を超えるアプリを作成するために使用したアプローチです。もちろん、ユーザーがどのようにナビゲートできるかはデータセットによって異なります。
テーブルを適切に作成すれば、画面に表示されるものとして常に再利用される実際の UITableViewCell オブジェクトは、ほんの一握りから十数個しか使用できません。
50でも安心です。
メモリ内に 5000 個のデータ オブジェクトと 50 個の UITableViewCells を持つことは、かなり許容できるはずです。
特に、これらのデータ オブジェクトが小さい場合、または CoreData にデータ セットの管理に関する何らかの作業を許可している場合。
重要なことは、5000 のテーブル セル ビューを作成しないことです。それは非常に悪い習慣です。