各セルにかなり大きな画像を読み込むuitableviewがあり、セルの高さは画像のサイズによって異なります。スクロールのパフォーマンスはまともですが、ぎくしゃくすることもあります。
私はFieryRobotブログでこれらのヒントを見つけました。
よりグラスっぽいスクロール-with-uitableview
uitableviewのスクロールパフォーマンスを向上させるためのヒントはありますか?
各セルにかなり大きな画像を読み込むuitableviewがあり、セルの高さは画像のサイズによって異なります。スクロールのパフォーマンスはまともですが、ぎくしゃくすることもあります。
私はFieryRobotブログでこれらのヒントを見つけました。
よりグラスっぽいスクロール-with-uitableview
uitableviewのスクロールパフォーマンスを向上させるためのヒントはありますか?
回答:
UITableViewCell
のすべてを描画します。drawRect:
drawRect:
UITableViewCell
の層の不透明(お持ちの場合は、同じコンテンツビューのために行きます)UITableView
例/ドキュメントで推奨されているreusableCellIdentifier機能を使用するUIImage
のUITableViewCell
化する場合は、Nibを使用せず、代わりにコードで記述してください。Nibファイルをロードするよりもはるかに高速です。トゥイーティーの背後にいる開発者は、これについて広範囲に記述しており、そのアプリでそれがどのように行われたかを示すコードをいくつか持っています。基本的に、彼/彼女はテーブルセルごとに1つのカスタムビューを推奨し、手動で描画します(他のオプションの中で、Interface Builderでサブビューするのではなく)。
また、AppleはTableViewSuiteチュートリアルでTableViewの独自のサンプルコードを更新しました(おそらくこれに対応していますか?)
UITableViewスクロールの#1パフォーマンスキラーは、任意のセルビューレイヤーにシャドウを描画するため、スクロールパフォーマンスが重要な場合は、基本的にメインスレッドの速度が低下しない限り、シャドウを実行しないでください。
受け入れられた答えのどれも影と層について言及しなかったので、これは言われる必要があると思いました。:+)
UITableView
スクロールのパフォーマンスに関する問題は、すでに他の回答で説明されている手法を使用して解決できます。ただし、パフォーマンスの低下は、本質的に誤りのある、または反復的なものによって引き起こされることがよくあります。
UITableView
セルを再利用するという事実と、各セルが独自のイメージを必要とする可能性があるという事実により、ソリューションは少し複雑になります。一般的な方法でそれがどのように解決されているかから、ここで注意すべき点を要約します:
[tableView reloaddata]
cellForRowAtIndexPath
に、配列の正しいデータモデルオブジェクトからデータ(テキスト)を設定するコードを含めます。問題を回避するには、テーブルビュー内の画像の遅延読み込みに関するこのチュートリアルを参照してください。