Android用のローカル画像キャッシュソリューション：Square Picasso、Universal Image Loader、Glide、Fresco？
Androidで非同期画像の読み込みおよびキャッシュライブラリを探しています。 Picassoを使用するつもりでしたが、GitHubではUniversal Image Loaderの方が人気があることがわかりました。誰もがこれらの2つのライブラリについて知っていますか？長所と短所の概要は素晴らしいでしょう。
（私の画像はすべてローカルにディスク上にあるので、ネットワークは必要ありません。したがって、Volleyは適切ではないと思います）
2018年9月更新：数年後、ローカルイメージキャッシュソリューションにもほぼ同じものが必要になりました。今回は、UILが積極的に開発されていません。人気のあるライブラリを比較しましたが、結論は非常に簡単です。Glideを使用するだけです。はるかに強力で設定可能です。何年も前、私はUILを分岐して変更しなければなりませんでした。 Glideは、キャッシング戦略とカスタムキーを使用した複数レベルの解像度キャッシングに関して、すべてのユースケースをサポートしています。 Glideを使用してください！
Koushik Duttaの比較は、主に速度ベンチマークのためのものです。彼の投稿はごく基本的なものにしか触れておらず、ローカル画像に特化したものではありません。質問をした後、ピカソとUILで経験を共有したいと思います。 PicassoとUILの両方がローカル画像をロードできます。私は最初にピカソを試しましたが、満足していましたが、後でカスタマイズオプションを増やすためにUILに切り替えることにしました。
ピカソ：
ピカソの流interfaceなインターフェースは素晴らしい。しかし、「with」、「into」、「load」を使用してジャンプすると、実際に背後にあるものがわかりません。返されるものを混乱させます。
Picassoでは、正確なターゲットサイズを指定できます。メモリの負荷やパフォーマンスの問題がある場合に役立ちます。画質と速度のトレードオフが可能です。
画像はキーのサイズでキャッシュされます。異なるサイズの画像を表示する場合に便利です。
メモリキャッシュサイズをカスタマイズできます。ただし、そのディスクキャッシュはhttpリクエスト専用です。ローカル画像の場合、読み込み速度が気になる場合は、サムネイルディスクキャッシュを用意しておくとよいです。そのため、毎回画像の数MBを読み込む必要がありません。 Picassoには、サムネイルをディスク上でサイズ変更および保存するこのメカニズムはありません。
Picassoは、キャッシュインスタンスへのアクセスを公開しません。 （最初にPicassoを構成し、それを保持するときに、それを手に入れることができます...）。
リスナーから返されたビットマップに画像を非同期的に読み込みたい場合があります。驚くべきことに、ピカソにはそれがありません。 「fetch（）」は何も返しません。 「get（）」は同期読み取り用で、「load（）」は非同期的にビューを描画するためのものです。
Picassoのホームページには、いくつかの簡単な例しかありません。高度な使用法については、順序付けられていないjavadocを読む必要があります。
UIL：
UILは、カスタマイズにビルダーを使用します。ほとんどすべてを構成できます。
UILでは、ビューにロードするサイズを指定できません。ビューのサイズに基づいていくつかのルールを使用します。ピカソほど柔軟ではありません。低解像度の画像を読み込んでメモリフットプリントを削減する方法はありません。 （編集：この動作は、ソースコードにImageSize引数を追加し、ビューサイズチェックをバイパスすることで簡単に変更できます）
UILはカスタマイズ可能なディスクキャッシュを提供します。これを使用して、指定されたサイズのサムネイルをキャッシュできます。しかし、それは完璧ではありません。 詳細 です。 （編集：速度を気にし、私の場合のように複数レベルのサムネイルキャッシュが必要な場合は、ソースコードを変更し、ディスクキャッシュで "memoryKey"を使用し、サイズも区別できるようにします）
UILは、デフォルトでメモリにさまざまなサイズの画像をキャッシュしますが、構成でオフにすることができます。
UILは、アクセス可能なバッキングメモリとディスクキャッシュを公開します。
UILは、ビットマップを取得したり、ビューにロードしたりできる柔軟な方法を提供します。
UILはドキュメントの方が優れています。 UILの詳細な使用方法はGithubページに記載されており、リンクされたチュートリアルがあります。
Picassoから始めることをお勧めします。さらに制御とカスタマイズが必要な場合は、UILに進んでください。
this KoushによるG +への投稿を読んだ場合、混乱に対する明確な解決策を得ることができます。Android-Universal-Image-Loaderが要件の勝者であるという点で、その概要を示しました。
Picassoは、ネットワークを使用している場合に最も優れた画像APIです！
rlImageViewHelper + AndroidAsyncが最も高速です。しかし、これらの他の2つの優れたライブラリを試してみると、画像APIの日付がかなり古いことが明らかになりました。
Volleyは滑らかです;プラグ可能なバックエンドトランスポートを本当に楽しんでいます。
そしてそこにAndroidAsyncをドロップする可能性があります。リクエストの優先度
そしてキャンセル管理は素晴らしい（ネットワークを使用している場合）Android-Universal-Image-Loaderは最も人気のあるものです
現在。高度にカスタマイズ可能。
このプロジェクトは、非同期の画像の読み込み、キャッシュ、表示のための再利用可能な機器を提供することを目指しています。もともとはFedor Vlasovのプロジェクトに基づいており、それ以来、大幅にリファクタリングおよび改善されています。
新しいUILバージョン（1.9.2）の今後の変更：
UIスレッドからImageLoaderを呼び出す可能性新しいディスクキャッシュAPI（より柔軟）。 Jake WhartonのDiskLruCacheに基づく新しいLruDiscCache。
このAndroid-Universal-Image-Loaderスイートすべてを要件と見なします（画像のロードはディスク上にローカルにあります）！
UIL、Picasso、Volleyの3つのライブラリーで経験を共有したいと思います。以前UILを使用していましたが、あまりお勧めできないという結論に至りました。非常に才能のあるチームが開発したVolleyまたはPicassoを代わりに使用することをお勧めします。 UILはまったく悪くありませんが、他の2つのライブラリの詳細に注意を払っていません。
UIのパフォーマンスについては、UILがあまり良くないことがわかりました。 VolleyやPicassoよりもUIスレッドをロックする傾向があります。これは、UILは画像応答のバッチ処理をサポートしていないが、ピカソとボレーはデフォルトでバッチ処理を実行しているためである可能性があります。
また、UILのディスクキャッシュシステムも好きではありませんでした。さまざまな実装から選択できますが、現時点では、合計サイズでUILディスクキャッシュbothを制限する方法はありません。エンティティの有効期限ごと。 VolleyとPicassoはそれを行い、UILはそれを無視しますが、デフォルトではサーバーから返された有効期限を使用します。
最後に、UILを使用すると、選択したディスクキャッシュとメモリキャッシュの実装と設定およびその他の詳細を含むグローバルイメージローダー構成を設定できますが、この構成はアプリのすべての場所に適用されます。したがって、2つの別個のディスクキャッシュのような柔軟性が必要な場合は、UILを使用する必要はありません。一方、Volleyでは、必要な数のイメージローダーを個別に構成できます。 Picassoはデフォルトでグローバルインスタンスを使用しますが、個別に構成可能なインスタンスを構築することもできます。
要約すると、Picassoには最高のAPIがありますが、すべてのHttpURLConnectionインスタンス間で共有されるグローバルHTTPディスクキャッシュを使用します。 Volleyは最高のパフォーマンスとモジュール性を備えていますが、ユーザーフレンドリーではないため、希望どおりに動作させるにはモジュールを1つまたは2つ記述する必要があります。全体的に、UILに対して両方をお勧めします。
編集（2014年12月18日）：この最初の答えを書いてから状況が変わり、改善する必要があると感じました：
Picasso 2.4は以前のリリースよりもさらに構成が容易であり、OkHttp（強く推奨）と併用すると、インスタンスごとに個別のディスクキャッシュを使用することもできるため、実際に何ができるかに制限はありません。さらに重要なことに、私はPicassoとOkHttpのパフォーマンスが大幅に改善されたことに気付きました。私のコードでは、.fit()または.centerCrop()または.centerInside()と組み合わせて常に使用し、メモリ使用量を減らし、UIスレッドのビットマップサイズ変更を回避していることに注意してください。 Picassoは積極的に開発およびサポートされており、それは確かに大きなプラスです。
ボレーはそれほど変わっていませんが、その間に2つの問題に気付きました。
- 時々、高負荷の下で、ディスクキャッシュの破損のために一部のイメージがロードされないことがあります。
- NetworkImageViewに表示されるサムネイル（スケールタイプがcenterCropに設定されている）は、他のライブラリで表示されるものと比べてかなりぼやけています。
これらの理由から、私はVolleyの使用をやめることにしました。
UILは依然として低速で（特にディスクキャッシュ）、APIは頻繁に変更される傾向があります。
Glide と呼ばれるこの新しいライブラリもテストしました。これは、Picassoに似たAPIを備えたPicassoよりも最適化されていると主張しています。私の個人的な経験によると、OkHttpと組み合わせて使用した場合でも、負荷の高いネットワーク要求では、実際にはピカソやボレーよりも遅くなります。さらに悪いことに、アクティビティを離れるときにLollipopの下で私のアプリでいくつかのクラッシュが発生しました。競合他社よりも2つの利点があります。
- アニメーションGIFデコードをサポートします
- 最終的にダウンスケールされたビットマップをディスクキャッシュに保存するため、ディスクキャッシュからの読み取りが非常に高速になります。
結論：最高の柔軟性、API、パフォーマンス、安定性を兼ね備えているため、Picasso + OkHttpを使用することをお勧めします。 GIFサポートが必要な場合は、Glideも検討できます。
インターネットから常に画像を取得して表示するアプリを実装しました。友達が私にユニバーサルイメージローダーを勧める前に、イメージキャッシュメカニズムをプログラムしようとしていました。
UILは非常に優れたカスタマイズが可能です。それは非常にカスタマイズ可能であるので、初心者は簡単に何か間違ったことをすることができます。しかし、私のアプリケーションではUILが遅く、少し遅くなりました。私の使用例は、画像を含むListViewでした。
昨日、UILの代替を探していましたが、ピカソを発見しました。 Picassoの統合と使用は簡単でした。Picasso.context(context).load(url).into(imageview)と画像をより速く、スムーズに統合できました。
私にとって、ピカソは間違いなく使用するAPIです。 UILでの私の経験は良くありませんでした。
ImageLoaderは、Picassoライブラリと比較して、よりカスタマイズ可能で柔軟だと思います。