- インメモリーキャッシング
- ファイルシステムキャッシング(電話メモリまたはSDカード)
public abstract class Cache<K, V> { protected final Map<K, Reference<V>> softMap = new HashMap<K, Reference<V>>(); public V get(K key) { if (softMap.containsKey(key)) { Reference<V> reference = softMap.get(key); return reference.get(); } else { return null; } } public void put(K key, V value) { softMap.put(key, createReference(value)); } public void clear() { softMap.clear(); } protected abstract Reference<V> createReference(V value); }
現在のバージョンでは、サイズを制御するビットマップキャッシュを使用しています。 これは、 ソフトマップからビットマップへの「強力な」リンクが保存された追加の「ハード」リストを導入することで実装されました。 キャッシュサイズが許容限度を超えると、「最も古い」オブジェクトが「ハードリスト」から削除されるため、強力なリンクが失われます。 弱いリンクはまだsoftMapに格納されていますが、ビットマップは既に完全にガベージコレクターの手に委ねられていますファイルシステムにキャッシュする場合 、ファイルはimageUrl.hashCode()と呼ばれ、同じ原理でキャッシュが検索されます。 ImageLoaderのメソッドは次のとおりです。 void displayImage(String imageUrl, ImageView imageView, DisplayImageOptions options, ImageLoadingListener listener)
パラメータimageUrlとimageViewは 、私が思うに、 問題を引き起こすことはないと思いますDisplayImageOptionsクラスは、画像の読み込み、キャッシュ、表示のプロセスを設定するように設計されています。 これを使用して、以下を指定できます。 - 実際の画像の読み込み中にImageViewでスタブ画像を表示する必要があるかどうか、およびどのスタブを表示するか。
- ダウンロードした画像をメモリにキャッシュするかどうか。
- ダウンロードしたイメージをファイルシステムにキャッシュする必要がありますか。
public interface ImageLoadingListener { void onLoadingStarted(); void onLoadingComplete(); }
ただし、現在の画像がメモリ内のキャッシュにある場合、 リスナーはイベントをスローしません。 UIストリームでイベントがスローされるため、 リスナーで静かな魂を使ってUIに触れることができるので、 ImageLoaderの使用例 : ImageLoader imageLoader = ImageLoader.getInstance(context); DisplayImageOptions options = new DisplayImageOptions.Builder() .showStubImage(R.drawable.stub_image) .cacheInMemory() .cacheOnDisc() .build(); imageLoader.displayImage(imageUrl, imageView, options, new ImageLoadingListener() { @Override public void onLoadingStarted() { spinner.show(); } @Override public void onLoadingComplete() { spinner.hide(); } });
ImageLoaderの動作のメカニズムについてはあまり説明しません。 私はいくつかのことだけを言います: - 画像を表示するタスクはキューに配置されます。画像が既にファイルシステムのキャッシュにある場合、タスクはキューの先頭に移動し、そうでない場合は最後に移動します。 タスクはキューの先頭から実行されるため、主にキャッシュされた画像が表示されます。 ( UPD :マルチスレッドイメージ表示メカニズムの導入後、このロジックは廃止されました。現在、キャッシュイメージと非キャッシュイメージのロードに2つの異なるスレッドプールが関与しています。キャッシュイメージ、シングルスレッド、その他、マルチスレッド)
- フルサイズのビットマップはメモリ内のキャッシュに保存されませんが、ImageViewでの表示に必要なサイズ以上ではありません。 このサイズは、属性maxWidthおよびmaxHeight 、 layout_width 、およびlayout_height 、デバイスの画面サイズに基づいて計算されます(元の画像のサイズは、画像のデコードに関する推奨事項に従って2のべき乗で縮小されます)。
- なぜなら まず、ImageLoaderはリストに画像を表示することを目的としていますが、原則として、Viewを再利用することをお勧めします。ImageLoaderは、独自のキーを使用して、タグImageViewに画像のロードされたURLを保存することにより、このような状況も監視します
UPD(2011年12月19日):ツールにいくつかの重要な変更が加えられました。それらの詳細とプロジェクト全体については、 こちらをご覧ください 。
UPD(2012年2月23日):多くの変更と改善が行われました(マルチスレッド、外部構成を含む)。 ただし、メインAPIは基本的に同じです。 これで、ツールがjarとして使用可能になりました。 バージョン管理が導入されました。
UPD(2012年3月11日):ライブラリの使用に関する詳細なガイドを書きました。