Android用のローカル画像キャッシュソリューション：Square Picasso、Universal Image Loader、Glide、Fresco？

Androidで非同期の画像読み込みとキャッシュライブラリを探しています。私はピカソを使用するつもりでしたが、GitHubではUniversal Image Loaderの方が人気があることがわかりました。これらの2つのライブラリについて誰か知っていますか？長所と短所の要約は素晴らしいでしょう。

（私の画像はすべてローカルにディスク上にあるので、ネットワークは必要ないので、Volleyは適していないと思います）

2018年9月更新：数年後、ローカルイメージキャッシングソリューションにもほぼ同じものが必要になりました。今回、UILは活発に開発されていません。私は人気のあるライブラリを比較しましたが、結論は非常に簡単です。Glideを使用するだけです。はるかに強力で構成可能です。数年前、私はフォークしてUILに変更を加えなければなりませんでした。Glideは、キャッシュ戦略とカスタムキーを使用した複数レベルの解像度のキャッシュに関して、すべてのユースケースをサポートしています。グライドを使用してください！

Koushik Duttaの比較は主に速度のベンチマークです。彼の投稿は非常に基本的なものに触れただけで、ローカルイメージに固有のものではありません。質問をした後、ピカソとUILでの経験を共有したいと思います。PicassoとUILはどちらもローカルイメージをロードできます。私は最初にピカソを試してみて満足していましたが、その後、より多くのカスタマイズオプションのためにUILに切り替えることにしました。

ピカソ：

• ピカソの流暢なインターフェイスは素晴らしいです。しかし、「with」、「into」、「load」でジャンプすると、実際には背後に何があるのか​​わかりません。何が返ってくるのかわかりません。

• ピカソでは、正確なターゲットサイズを指定できます。これは、メモリの負荷やパフォーマンスの問題がある場合に役立ちます。速度と画像品質のトレードオフが可能です。

• 画像はキーのサイズでキャッシュされます。異なるサイズの画像を表示する場合に便利です。

• メモリキャッシュサイズをカスタマイズできます。ただし、そのディスクキャッシュはhttpリクエスト専用です。ローカル画像の場合、読み込み速度を気にする場合は、サムネイルディスクキャッシュを用意しておくと、毎回画像の数MBを読み取る必要がなくなります。Picassoには、ディスク上でサムネイルのサイズ変更と保存を行うこのメカニズムはありません。

• ピカソはキャッシュインスタンスへのアクセスを公開しません。（最初にピカソを設定してそれを保持するときにそれを手に入れることができます...）。

• リスナーから返されたビットマップに画像を非同期で読みたい場合があります。驚いたことに、ピカソにはそれがありません。「fetch（）」は何も返しません。「get（）」は同期的に読み取るためのものであり、「load（）」は非同期的にビューを描画するためのものです。

• Picassoのホームページにはいくつかの簡単な例しかありません。高度な使用法については、順序付けされていないjavadocを読む必要があります。

UIL：

• UILは、カスタマイズにビルダーを使用します。ほとんどすべてを構成できます。

• UILでは、ビューにロードするサイズを指定することはできません。ビューのサイズに基づいていくつかのルールを使用します。ピカソほど柔軟ではありません。メモリフットプリントを減らすために低解像度の画像を読み込む方法はありません。（編集：この動作は、ソースコードにImageSize引数を追加し、ビューサイズチェックをバイパスすることで簡単に変更できます）

• UILはカスタマイズ可能なディスクキャッシュを提供します。これを使用して、指定されたサイズのサムネイルをキャッシュできます。しかし、それは完璧ではありません。ここにある詳細が。（編集：速度を重視し、私の場合のようにサムネイルキャッシュの複数のレベルが必要な場合は、ソースコードを変更して、ディスクキャッシュに "memoryKey"を使用させ、サイズを区別することもできます）

• UILはデフォルトで、さまざまなサイズの画像をメモリにキャッシュします。設定でオフにできます。

• UILは、アクセスできるバッキングメモリとディスクキャッシュを公開します。

• UILは、ビットマップを取得したりビューにロードしたりできる柔軟な方法を提供します。

• ドキュメントではUILの方が優れています。UILはGithubページで詳細な使用法を提供し、リンクされたチュートリアルがあります。

Picassoから始めることをお勧めします。より詳細な制御とカスタマイズが必要な場合は、UILを使用してください。

KoushによるG +に関するこの投稿を読むと、混乱の明確な解決策が得られます。その概要をまとめました。Android-Universal-Image-Loaderが要件の勝者です！

• ネットワークを使用している場合、ピカソは最も素晴らしい画像APIを持っています！

• UrlImageViewHelper + AndroidAsyncが最速です。しかし、これらの他の2つの優れたライブラリで遊んだことで、画像APIがかなり古くなっていることが強調されました。

• ボレーは滑らかです。私はプラグイン可能なバックエンドトランスポートを本当に楽しんで
  おり、AndroidAsyncをそこにドロップする可能性があります。リクエストの優先度
  とキャンセルの管理が優れている（ネットワークを使用している場合）

• Android-Universal-Image-Loaderは、
  現在最も人気のあるものです。高度にカスタマイズ可能。

このプロジェクトは、非同期の画像の読み込み、キャッシュ、表示のための再利用可能な計測器を提供することを目的としています。もともとはFedor Vlasovのプロジェクトに基づいており、それ以来大幅にリファクタリングされ、改善されてきました。

新しいUILバージョン（1.9.2）で予定されている変更：

UIスレッドからImageLoaderを呼び出す可能性新しいディスクキャッシュAPI（より柔軟）。Jake WhartonのDiskLruCacheに基づく新しいLruDiscCache。

このすべてのAndroid-Universal-Image-Loaderスイートを要件と考えると（画像をローカルにディスクにロードする）！

UIL、ピカソ、ボレーの3つのライブラリでの経験を共有したいと思います。以前はUILを使用していましたが、結局推奨できません。どちらも非常に才能のあるチームが開発したVolleyまたはPicassoを使用することをお勧めします。UILは悪くありませんが、他の2つのライブラリの詳細に注意を払っていません。

UILはUIパフォーマンスがあまり良くないことがわかりました。VolleyやPicassoよりもUIスレッドをロックする傾向があります。これは、ピカソとボレーがデフォルトで画像応答をバッチ処理している間、UILが画像応答のバッチ処理をサポートしていないためである可能性があります。

また、UILのディスクキャッシュシステムは好きではありませんでした。さまざまな実装から選択できますが、現時点では、合計サイズとエンティティの有効期限の両方で UILディスクキャッシュを制限する方法がないことを指摘する必要があります。VolleyとPicassoはそれを行い、UILが無視する間、デフォルトでサーバーから返される有効期限を使用します。

最後に、UILを使用すると、選択したディスクキャッシュとメモリキャッシュの実装と設定およびその他の詳細を含むグローバルイメージローダー構成を設定できますが、この構成はアプリのすべての場所に適用されます。したがって、2つの別個のディスクキャッシュなどの柔軟性が必要な場合は、UILを使用する必要はありません。一方、Volleyでは、独自の構成を持つイメージローダーを必要な数だけ使用できます。ピカソはデフォルトでグローバルインスタンスを使用しますが、個別に構成可能なインスタンスを構築することもできます。

まとめると、ピカソは最高のAPIを備えていますが、すべてのHttpURLConnectionインスタンス間で共有されるグローバルHTTPディスクキャッシュを使用するため、場合によっては制限が厳しすぎることがあります。Volleyは最高のパフォーマンスとモジュール性を備えていますが、ユーザーフレンドリーではなく、希望どおりに機能させるために独自のモジュールを1つまたは2つ作成する必要があります。全体的に、UILに対して両方を推奨します。

編集（2014年12月18日）：この最初の回答を書いてから状況が変わっており、改善する必要があると感じました。

Picasso 2.4は以前のリリースよりもさらに構成可能であり、OkHttpで使用する場合（強く推奨）、インスタンスごとに個別のディスクキャッシュを使用することもできるため、実際にできることには制限がありません。さらに重要なことに、PicassoとOkHttpのパフォーマンスが大幅に向上していることに気付きました。私の意見では、Android向けの最速の画像ローダーソリューションであると言えます。私のコードでは、メモリ使用量と.fit()組み合わせて、.centerCrop()または.centerInside()メモリ使用量を減らし、UIスレッドでのビットマップのサイズ変更を回避するために常に使用していることに注意してください。ピカソは積極的に開発およびサポートされており、それは確かに大きなプラスです。

ボレーはそれほど変わっていませんが、それまでの間、2つの問題に気づきました。

• 負荷が高い場合、ディスクキャッシュの破損が原因で一部のイメージが読み込まれなくなることがあります。
• NetworkImageView（縮尺タイプがcenterCropに設定されている）に表示されるサムネイルは、他のライブラリで得られるものに比べてかなりぼやけています。

これらの理由から、ボレーの使用をやめることにしました。

UILは依然として低速であり（特にディスクキャッシュ）、そのAPIは頻繁に変更される傾向があります。

私はまた、Glide 3と呼ばれるこの新しいライブラリをテストしました。これは、ピカソのようなAPIでピカソよりも最適化されていると主張しています。私の個人的な経験によれば、OkHttpと組み合わせて使用​​した場合でも、高負荷のネットワークリクエストでは、実際にはピカソやボレーよりも遅くなります。さらに悪いことに、アクティビティを終了するときに、Lollipopの下で私のアプリでいくつかのクラッシュが発生しました。それでも、競合他社に比べて2つの利点があります。

• アニメーションGIFデコードをサポート
• 最終的にダウンスケールされたビットマップをディスクキャッシュに入れます。つまり、ディスクキャッシュからの読み取りは非常に高速です。

結論：ピカソ+ OkHttpを使用することをお勧めします。これにより、最高の柔軟性、API、パフォーマンス、および安定性が組み合わされます。GIFサポートが必要な場合は、Glideを検討することもできます。

インターネットから常に画像を取得して表示するアプリを実装しました。私がイメージキャッシュメカニズムをプログラムしようとしていましたが、その前に友人からユニバーサルイメージローダーが勧められました。

UILは非常にカスタマイズ可能です。初心者でも簡単に問題が発生するほどカスタマイズ可能です。しかし、UILは私のアプリケーションでは遅く、少し遅くなりました。私の使用例は、画像付きのListViewでした。

昨日、UILに代わるものを探していたところ、ピカソを発見しました。Picassoは統合と使用が簡単でしPicasso.context(context).load(url).into(imageview)た。画像をより速くスムーズに統合することができました。

私にとって、ピカソは間違いなく使用するAPIです。UILの私の経験はよくありませんでした。

ImageLoaderは、Picassoライブラリと比較して、カスタマイズと柔軟性が高いと思います。