1

ですから、私は以前にこの質問を聞いたことがあり、実際には昨夜質問しましたが、この問題について他のユニークな見解を得ることができるかどうかを確認するためにもう一度試してみようと思いました。

問題—スクロールビューに多数のuiimageview(画像がディスクにダウンロードされている)を含むアプリがありますが、もちろん、メモリの使用とパフォーマンスという2つの大きな問題があります。私のアプリでは、イメージビューのデキューや再利用などの手法を採用しているため、メモリの使用はそれほど問題になりません。しかし、パフォーマンスはまったく別のものです。今のところ、メモリ節約の手順として、画像をメモリに保存するのはばかげているので、画像ファイルパスのみをメモリに保存します。ただし、これに伴う問題は、ディスクからの読み取りにメモリからの読み取りよりも時間がかかり、scrollviewのスクロールが非常に遅くなることです

では、このようなことに対して、どのようなテクニックを提案しますか?私はthree20を見たことがありますが、私の見解では高度なカスタマイズ性が必要であり、それではうまくいかないため、使用したくありません。画像ファイルは大きくはありませんが、サムネイルサイズだけなので、拡大縮小や余分なサイズはありません。これを処理する直感的な方法が必要です。組み込みの写真アプリは、メモリが少なく、滑らかでスムーズなスクロールパフォーマンスで、最大数千枚の写真を完全に処理します。

4

1 に答える 1

1

基本的に、問題は、UIスレッドで大量のディスクI / Oを実行している可能性があることです。これは、基本的にパフォーマンスの問題を引き起こすことが保証されています。

バックグラウンドスレッドに画像をロードし、画像がロードされたときにメインスレッドの画像ビューを更新することを検討する必要があります。ユースケースに応じて、事前にプリロードする距離などについて多かれ少なかれ賢くなり、画像を準備することができます。(このようなことを行う、使用可能なソースコードやAppleのサンプルコードさえあるかもしれませんが、頭の中でそれを知りません。)

一部のアプリケーション(写真アプリについては不明)には、すべての画像に対して非常に小さい親指サイズの画像をロードし、フルサイズバージョンまでプレースホルダーとして機能するレンダリングサイズにスケールアップする中間段階があることに気付くかもしれません。が読み込まれます-フルサイズが読み込まれる前にユーザーがその画像を超えてスクロールした場合、表示される効果は、画像がずっとそこにあった場合とほぼ同じです。

于 2010-08-22T17:53:13.160 に答える