結果：
したがって、ライブラリはベンチマークに参加します。
UIL 、 ピカソ 、 グライド 、 クエリ 、 ボレー
ソースはここにあります。
この記事の最初の部分では、5つのライブラリーを使用して、使用済みメモリーの測定に関する実験を行います。
第2部では、カスタマイズオプションと視覚的特性によってライブラリを比較します。
使用メモリ
誰かが実験の詳細に慣れることに興味があるなら、それらは前の記事で見つけることができます。
簡単に言います：画像を読み込むためのライブラリを同じ条件下でテストし、それらが使用するメモリを測定します。 デバイス上のグラフは、 GraphViewライブラリを使用して描画されました。
240x240の小さな画像をダウンロード
この実験では、ライブラリの作成者によるハックのおかげで、 UILのメモリ消費量が減少していることがわかります 。
imageView.post(new Runnable() { @Override public void run() { imageLoader.displayImage(...); } });
フォーマット変換なしで大きな画像をダウンロードする
クエリライブラリは非常に興味深いものです。 ソースには入りませんでしたが、キャッシュはセットではなくリストに基づいていると仮定しています。 そうでなければ、逆グリッドスクロールでの画像の複製を説明する方法がわかりません。
また、不快にボレーを驚かせた。 多くの場合、ImageViewの画像は読み込まれません。 Debagは、リサイクルBitmapをインストールする試みが時々行われることを示しました。 おそらく、クリーニングするイメージの選択に何らかの問題があります。
RGB565形式に変換して大きな画像をダウンロードし、画像をImageViewサイズに合わせる
原則として、大きな画像では24ビット形式は必要ありません。ほとんどの場合、RGB565で十分です。
形式を変換する最も簡単な方法はUILです。 イメージの読み込みオプションで必要なBitmap.Configを指定するだけで十分です。 ライブラリの残りの部分については、変換を記述する必要がありました。
この実験ではGlideが際立っており、 Volley 、 Query、 Picassoを組み合わせたよりも多くのメモリを消費します。 すぐに明確にしたい：キャッシュのサイズを制限することは可能でしたが、実験では、基本構成でライブラリがメモリでどのように機能するかを確認したかったのです。 キャッシュ制限によるすべてのグローバルクリーニングは、UIストリームの作業における顕著なプラグインです。 したがって、そういうことがあれば、図書館から少しずつ掃除してほしい。
小さい画像（240x240）をダウンロードして、その後の丸め
残念ながら、そのような成功したボレーの結果は考慮に入れることができません、なぜなら帰りのパスで私は写真を見なかったからです。 変換中に元のrecycle（）を呼び出さなかったことを考慮しても、それらはすべてリサイクルされました。 良くない。
Glideは 、すべての画像をRGB565に変換するようです。これは、画像の背景が透明なものではなく黒い背景であることが判明したためです。 良くない。
変換を行う最も簡単な方法は、 UILとQueryを使用することです。 UILにはビルトインクラスRoundBitmapDisplayerがあり、ダウンロードオプションに接続できます。
クエリの場合 、オプションで画像の丸みの半径を指定するだけで十分です。
PicassoとGlideの場合 、ダウンロードに変換を含めることは、Builderの手順の1つのように見えます。
Glide.load(url).centerCrop().transform(roundTransformation).into(imageView); Picasso.with(context).load(url).transform(picassoRoundTransformation).noFade().into(imageView);
Volleyの場合、 ImageViewを再定義し、setImageBitmap（）メソッドでビットマップ変換を行う必要がありました。
誰かがより良い解決策を持っているなら、あなたのオプションを提供してください。
視覚特性。
Picassoは 、画像のダウンロード速度が他のライブラリより劣っています。 これを説明する方法はわかりませんが、事実です。ピカソの写真は少し遅れて表示されます。
前述のように、 Glideは画像をRGB565に変換するため、画像の変換時に問題が発生する可能性があります。
UILは視覚的に画像をより速く読み込みます。 ただし、1つの機能を検討する必要があります。FadeInBitmapDisplayerを使用して写真をスムーズに表示する場合は、高度なコンストラクターを使用することをお勧めします。
new FadeInBitmapDisplayer(duration, true, true, false)
この構成では、画像は初めて（アニメーションがキャッシュ内に存在する間）のみアニメーション化され、スクロールするとき、不要なアニメーションで目を痛めません。 これは私見です。
ピカソでは、「フェードイン」効果はこのモードでの定義により機能します。
一方、Volleyは、既にリサイクルされているため、変換された画像を表示しないことがよくあります（）。 このバグを修正する方法についてのコメントをお待ちしています。
クエリは視覚的に驚くことではありませんでした。 画像のダウンロードは断続的に見えます。 写真が要求された順序はほとんど尊重されません。
ブートローダーのセットアップ
UILは、ブートオプションを微調整する際の議論の余地のないリーダーです。 形成設定のビルダーパターンのおかげで、ライブラリの機能に簡単に慣れることができます。 原則として、マニュアルなしで行うことができます。 UILを使用すると、OnScollListenerに接続して、リストのスクロール中に要求を中断することもできます。
GlideとPicassoは、統合が最も簡単なライブラリです。 Picassoには、Mavenリポジトリがあるという利点があります。 最適な設定と経済的なメモリ消費を確保しながら、画像の読み込みをすばやく統合する必要がある場合は、 Picassoを選択してください。
PicassoとUILは、画像をどこにでもアップロードできるように実装することにより、インターフェースを提供します。
Volleyを使用するには、多くの準備が必要です。 キャッシュインスタンスとブートキューを自分で作成して構成する必要があります。 マークアップでは、NetworkImageViewウィジェットまたはその子孫を使用する必要があります。 私にとって、これは大きな不便です。 このライブラリを使用して画像をアップロードする唯一の許容される方法は、プロジェクトのネットワークがVolleyで構築されている場合です。
クエリは、原則として設定するのが難しくありません。 しかし、著者によって提案されたアダプターを使用するオプションは、私を少し混乱させます。 各画像を読み込むには、AQueryクラスのインスタンスを作成する必要がありますが、それ自体は非常に重いものです。 ガベージコレクションのCPU時間を節約する場合、これは最適なライブラリではありません。
クエリの例
AQuery aq = new AQuery(convertView); ImageOptions options = new ImageOptions(); options.ratio = 1; options.round = Integer.MAX_VALUE; aq.id(imageView).image(url, options);
多くの場合、独自のHTTPClientを使用して画像をアップロードする必要があります。 VolleyとUILは、接続をセットアップするためのツールを提供します。 インターネットでは、カスタムHttpClientのPicassoへの統合にも出会いました。 しかし、私が理解しているように、標準的な手段ではこれを行うことはできません。
結論
ライブラリが多いほど、結論を出すのが難しくなります。 各ライブラリを1つの文で特徴付けようとします。
Picasso-すぐに統合する必要があり、使用済みメモリを心配しない場合
UIL-プロジェクトでダウンロードの特定の構成が必要であるが、同時にこの構成を迅速かつ明確に実行できる場合
Glideは一種のピカソクローンです（逆の場合もあります）が、少し多くのメモリを消費します。
Volley-ネットワークがVolley上に構築されていて、接続にプロジェクト全体の特定のHttpClient構成が必要な場合、使用は正当化されます。
クエリは、理解するのが難しく、貧弱なドキュメントと統合するのが難しいライブラリですが、それでもデバイスメモリの節約に優れた結果を示しています。
あなたのコメントと役に立つヒントを待っています！