私が今アプリ内でやろうとしているのは、コンテキストをリークすることなくImageViewsの画像を非同期的にダウンロードしてキャッシュするチュートリアルの1つでGoogleが昨年公開したImageDownloaderクラスを変更することです。
つまり、ビットマップハッシュマップへの参照を提供するグローバルキャッシュシングルトンオブジェクトを使用しているので、知っておく必要があります。アプリの特定の側面（クライアント要件）に応じて画像を個別にキャッシュする必要があるため、これらのタイプのビットマップごとにハードハッシュマップとソフトハッシュマップのペアを使用しますか、それとも、他のハードキャッシュがスペースを要求されたときにファイルを移動するソフトハッシュマップを1つだけ持つ方が効率的ですか？
次のようなものを使用することを検討してください。
ConcurrentHashMap<String, SoftReference<Bitmap>> image_cache =
newConcurrentHashMap<String, SoftReference<Bitmap>>( 1 );
キャッシュのメモリ部分用。デバイスがメモリを必要とするため、SoftReference はガベージ コレクションされます。これにより、アプリケーションは、メモリの問題を引き起こすことなく、できるだけ多くの画像をメモリに保持できます。
次を使用して、ルート パスを持つ SD カード上のファイル キャッシュでこのキャッシュをバックアップすることを選択できます。
Environment.getExternalStorageDirectory();
または、次のパスを使用して Android によって提供されるキャッシュ スペースを使用します。
context.getCacheDir();
キャッシュ スペースはプライベートであるため、SD カードのイメージはユーザーが取得したり、サード パーティのプログラムによって変更したりできます。キャッシュ スペースはデバイスの内部ストレージにあり、アプリケーション マネージャーの統計に表示されます。ユーザーは、設定 -> アプリケーション マネージャー画面から簡単にこのキャッシュをクリアすることもできます。
最初にメモリ キャッシュをチェックし、見つかった場合はソフト参照をチェックし、見つからない場合はファイル システムをチェックし、最後にネットワークからフェッチしてファイルに保存し、メモリ キャッシュに入れるアルゴリズムを入力する必要があります。 . 次に、クライアントの要件に基づいて、この構造の上にキャッシュの要件を追加できます。
私たちが取り組んでいるアプリで同様の問題が発生しました。SQLite blob にプルした画像をハード キャッシュします。ラッパーはキャッシュの存在をチェックするか、ネットワークを介してプルするため、誰かがアプリのデータを消去しても機能します (画像が再度キャッシュされるまで少し遅くなります)。SQLite にあるため、ファイル パスが変更されることを心配することなく、アプリ データを SD カードに簡単に移動したり戻したりできます。