5

Apple は 1 週間前に、UITableView で画像を遅延読み込みするサンプル コードをいくつかリリースしました。私はそれをチェックアウトし、自分の UITableView (高速スクロール用の drawRect です) に実装して、既に行っていたこととの違いがあるかどうかを確認しました。

実装した後、何が最適かわかりません。新しいコードまたは私がすでに持っていたもの。私の 3GS では速度の向上はあまり見られません。

「サンドボックス」方式: 画像を遅延ロードし、サンドボックスのローカル tmp フォルダーに保存します。セルが表示されるたびに、そのファイル名の画像が既にサンドボックス フォルダーにあるかどうかが検索されます。そうである場合は、画像を取得して表示します。そうでない場合は、ダウンロードを続行し、ローカルに保存してから表示します。これの利点は、アプリを 2 回目に開いたときに画像が空白にならないことです。それらはすでにダウンロードされており、表示する準備ができています。

キャッシング方法: これも画像を遅延ロードしますが、テーブルビューに表示される配列内の各オブジェクトに UIImage を含めます。画像をローカルに保存する代わりに、画像をダウンロードしてオブジェクトの配列に配置します。ここで、毎回ファイル名をチェックする代わりに、UIImage != nil であるかどうかをチェックし、キャッシュされたイメージを使用します (または nil の場合はダウンロードします)。

小さな違いは、キャッシュ コードがセルに表示される正確なサイズに画像をキャッシュする前にサイズを変更することです。一方、サンドボックス コードの例で使用されている画像は、実際には表示に必要なサイズよりも少し大きいため、スクロールするときもその場でサイズを変更する必要があります。数か月前に、これを行うには少し費用がかかる可能性があることを読みました。また、サンドボックスに保存されたイメージの代わりにキャッシュされたイメージを使用するという点で大きな違いがあるかどうかもわかりません。上記のキャッシュコードでキャッシュから保存したものに）。

私の質問は、キャッシュコードを気にする必要があるかどうかだと思いますか? 繰り返しますが、新しいコードは新しい起動時に画像をすぐにロードしませんが、古いコードは既にサンドボックスにあるため、実際にロードします。私は画像を再利用していないので、（サンドボックスまたはキャッシュから）ロードする画像がたくさんあるので、速度に大きな違いはありません。実際、私の意見では、私の 3GS でそれを判断することはほとんど不可能です。スクロールは滑らかではありません。これは、再利用できない画像が大量にあるためだと思います (セルごとに異なる画像)。また、フォルダーに1000以上の画像があると、サンドボックスメソッドが遅くなるかどうかも疑問に思っています。たとえば、最終的には100個程度よりも多くの画像を調べます。

私が理にかなっていることを願っています。詳細についてはかなり徹底したかったので、必要に応じて詳細をお知らせします。

ありがとう！

4

3 に答える 3

1

すでに機能しているコードがあり、差し迫った問題がない場合は、変更しないでください。

スクロールが実際に遅すぎる場合は、さまざまなアイデアを組み合わせて UIImage を取得し、そこにない場合はサンドボックスから読み込み、ない場合はダウンロードすることができます。

于 2009-11-23T15:41:59.893 に答える
0

あなたが提示する両方のアプローチには賛否両論があります-私はあなたのアプリで両方の要素を使用することをお勧めします。

画像をメモリに保存し、後で（おそらくアプリが終了したときに）保存することをお勧めします。画像がたくさんある場合は、通常のファイルよりもCoreDataを使用して画像を保存する方が速い場合があります。

また、その場でサイズ変更を行わないようにすることをお勧めします。つまり、tableView：cellForRowAtIndexPath：またはtableView：willDisplayCell：forRowAtIndexPath：メソッド、またはセルのコンテンツビューの描画に関係するメソッドでサイズ変更を行うことは避けてください。可能であれば、画像プロバイダー（コンテンツ管理？）に、テーブルビューに表示されるサイズの画像を提供するよう依頼してください。

于 2009-11-26T09:06:10.220 に答える
0

パフォーマンスに識別可能な違いがあるかどうかを判断する唯一の良い方法は、Instruments (2 つの手法の表示フレームレートなどを測定するため) や Shark (コード内のホットスポットを特定するため) などのプロファイリング ツールを使用することです。正確な実装には小さな違いがある可能性があり、それにより、私たちが提供できる一般的な回答と、アプリケーションで見られる実際のパフォーマンスとの間に大きな違いが生じる可能性があります.

「サンドボックス」方式で主に懸念されるのは、パフォーマンスではなく、ディスク容量の使用です。特にすべての画像が一貫して使用されていない場合や、使用される画像のセットが頻繁に変更される場合は、iPhone や iPod Touch が不要なファイルでいっぱいになることをユーザーは歓迎しません。アプリケーションについて詳しく知らなければ、これらのキャッシュされた画像が読み込まれる頻度を推測することは不可能です。

自分のデバイスでローカルにテストしている場合は、Wifi ネットワークに接続している可能性があります。テストの一部で Wifi をオフにして、セルラー ネットワーク経由ですべての画像を取得する必要がある場合に 2 つのアプローチがどのように機能するかを確認することをお勧めします。また、古いデバイス (iPhone 3G またはそれ以下) を探してみることをお勧めします。3GS は実際には、古いデバイスのユーザーにとって煩わしい潜在的なパフォーマンスの問題を隠しているからです。

私は自分のアプリで LazyTableImages 手法を個人的に何度も使用してきました (ただし、WWDC09 と最近の「リリース」の間で大幅に変更されていない場合)。ただし、私の場合、ディスクに画像をキャッシュすることはできません。私の逸話をあまり強く考慮しないでください。独自のコードをプロファイリングし、表示される結果を使用してください。

編集：

明らかな答えは、メモリ内キャッシュへのアクセスはファイルシステムへのアクセスよりも高速になるということですが、もちろん、それに関する最終的な言葉はプロファイリングに委ねられています。画像が既にメモリ内にある場合は、フラッシュから読み取って UIImage で解析する必要はありません。ただし、ここで従来のトレードオフが発生します。インメモリ キャッシングとディスク スペースです。

画像をメモリ内に保存する方が高速かもしれませんが、アプリケーションでメモリ警告を正しく処理することを十分に確認する必要があります (とにかくそうする必要があります!)。そうしないと、長期間使用すると、メモリ内キャッシュに非常に多くの画像が作成され、メモリ警告がトリガーされます。アプリケーションがこれらを処理するように構築されていない場合、メモリ リソースの不足により、せいぜいアプリケーションが OS によって強制終了されます。

于 2009-11-23T15:22:45.253 に答える