0

私はその瞬間にロジックの助けを求めています（コードではありません）。アプリの目的は、レベル番号に応じて 2/3/4 の異なる画像を表示することです。すべて同じビュー内に表示されます (したがって、画像が消え、新しい画像が画面に配置されます)。これらすべての画像をローカルに置くと、メモリに非常に悪影響を及ぼします。私が疑問に思っているのは、メモリを抑えるための最良の方法です。「Property Lists」と「Archiving」に関する Apple のドキュメントを読んでいますが、読んだ内容の 6 分の 1 しか理解できませんでした。私は GCD、キュー、およびスレッドを認識していますが、それらを実装する方法や、それらが最善の方法であるかどうかもわかりません。文字通り、それらを知っているだけです。

すべての画像を保存し、必要な画像をレベル番号変数に応じて画面にロードし、レベル番号変数が 1 増加したときに画面からアンロードしたいと考えています。次のレベルの画像をプリロードし、次のレベルの画像が画面上にロードされたら、画面上の現在の画像をメモリからアンロードする方が速い場合があります。

それが少しでも理にかなっているのなら、それが意味をなすことを本当に願っています。

お時間とご協力いただきありがとうございます:)。

4

1 に答える 1

2

いくつかの考え：

  1. 「メモリを抑える」ための最良の方法はUIImage、すぐに必要とされないオブジェクトへの強い参照を保持しないようにすることです。これは、遅延読み込みと呼ばれることもあります（UIImage「ジャストインタイム」でオブジェクトを作成するだけです）。そのため、アプリが最終的に使用する可能性のある画像が多数ある場合でも、現在のユーザーインターフェイスにすぐに必要な画像のUIImageViewオブジェクト（および関連するプロパティ）のみを入力します。imageまた、同様に、不要になった画像への強い参照を解放するようにしてください。

  2. 画像メモリ管理とプロパティリストおよびアーカイブの間の接続は薄いです。画像をどのように保存するかを尋ねる場合は、画像がアプリのバンドルの一部としてアプリとともに配信されるか、ネットワークから画像を取得します。後者の場合、ダウンロードした画像をアプリのローカルファイルシステムDocuments（またはLibraryフォルダー）、およびアプリのモデルでそれらを追跡する場合があります。これは、プロパティリスト（plists）またはCore Data（または他の形式の永続ストレージ）を使用して永続ストレージに保存します。通常、キャッシュされた画像自体をこれらのタイプの永続ストレージに保存することはお勧めしません。パフォーマンス上の理由から、画像が小さい場合を除いて、ファイルをローカルファイルシステムに保存し、それらのファイル名への参照を永続ストレージに保持することをお勧めします。

  3. イメージメモリ管理とGCD/キュー/スレッド間の接続も薄いです。はい。ユーザーインターフェイスに悪影響を与えないようにバックグラウンドで画像をダウンロードする場合など、非同期のバックグラウンド操作には、またはGrandCentralDispatchのディスパッチキューなどの同時実行テクノロジを使用します。NSOperationQueueこれは、メモリ管理の問題というよりもUXの問題です。余談ですが、優れた汎用AFNetworkingや画像中心のSDWebImageなど、確立されたサードパーティのフレームワークを使用してこのプロセスを簡素化することも検討してください。これらは、画像の非同期検索を行うプロセスを簡素化します。

于 2013-03-14T16:18:47.440 に答える