适用于Android的本地图像缓存解决方案：Square Picasso，Universal Image Loader，Glide，Fresco？

Question

我正在寻找Android中的异步图像加载和缓存库。我打算使用Picasso，但我发现Universal Image Loader在GitHub上更受欢迎。有谁知道这两个图书馆？优点和缺点的摘要会很棒。

（我的所有图像都在本地磁盘上，因此我不需要联网，因此我认为Volley不合适）

Answer 1

更新于2018年9月：几年后，我需要与本地图像缓存解决方案几乎相同的东西。这一次，UIL尚未积极开发。我比较了流行的库，结论很简单：只需使用Glide。它功能强大且可配置。多年前我不得不分叉并对UIL进行更改。 Glide支持我的所有用例，包括缓存策略和使用自定义键的多级分辨率缓存。只需使用Glide！

Koushik Dutta的比较主要是速度基准。他的帖子只触及了非常基本的东西，并不是特定于本地图像。在我提出问题之后，我想与毕加索和UIL分享我的经历。 Picasso和UIL都可以加载本地图像。我第一次尝试Picasso并且很开心，但后来我决定切换到UIL以获得更多自定义选项。

毕加索：

• 毕加索的流畅界面很不错。但是，随着“with”，“into”，“load”的跳跃，你实际上并不知道幕后背后是什么。这让人感到困惑。
• 毕加索允许您指定确切的目标尺寸。当你遇到内存压力或性能问题时，它很有用，你可以牺牲一些图像质量来提高速度。
• 图像在其键中缓存大小，当您显示不同大小的图像时，它非常有用。
• 您可以自定义内存缓存大小。但它的光盘缓存仅适用于http请求。对于本地图像，如果您关心加载速度，最好有一个缩略图磁盘缓存，这样您就不必每次都为图像读取几个MB。 Picasso没有这种机制调整大小并在屏幕上保存缩略图。
• Picasso不公开对其缓存实例的访问。 （当你第一次配置Picasso并保持它时，你可以抓住它......）。
• 有时您希望将图像异步读取到侦听器返回的位图中。令人惊讶的毕加索没有那个。 “fetch（）”不会传回任何东西。 “get（）”用于同步读取，“load（）”用于异步绘制视图。
• Picasso在主页上只有一些简单的例子，你必须阅读无序的javadoc以获得高级用法。

UIL：

• UIL使用构建器进行自定义。几乎所有东西都可以配置。
• UIL不允许您指定要加载到视图中的大小。它使用一些基于视图大小的规则。它没有毕加索那么灵活。我无法加载较低分辨率的图像以减少内存占用。 （编辑：通过在源代码中添加ImageSize参数并绕过视图大小检查，可以轻松修改此行为）
• UIL提供可自定义的光盘缓存，您可以使用它来缓存指定大小的缩略图。但它并不完美。这是details。 （编辑：如果您关心速度并想要多级缩略图缓存，就像我的情况一样，您可以修改源代码，让磁盘缓存使用“memoryKey”，并使其大小敏感）
• UIL默认在内存中缓存不同大小的图像，并且可以在配置中关闭它。
• UIL公开您可以访问的后备内存和磁盘缓存。
• UIL提供了灵活的方法来获取位图或加载到视图。
• UIL在文档方面更好。 UIL在Github页面上给出了详细的用法，并且有一个链接的教程。

我建议从Picasso开始，如果你需要更多的控制和定制，请选择UIL。

Answer 2

如果您阅读Koush在G +上阅读this帖子，您将获得明确的解决方案，我已经总结了这一点，因为Android-Universal-Image-Loader是您的要求的赢家！

• 如果您使用网络，Picasso拥有最好的图像API！
• UrlImageViewHelper + AndroidAsync是最快的。然而，与其他两个伟大的库一起玩，确实突出了图像API已经过时了。
• Volley很光滑;我非常喜欢他们的可插拔后端传输， 并可能最终放弃AndroidAsync。请求优先级 和取消管理很棒（如果你使用网络）
• Android-Universal-Image-Loader是最受欢迎的 目前。高度可定制。

该项目旨在为异步图像加载，缓存和显示提供可重用的工具。它最初基于Fedor Vlasov的项目，并且从那时起经过了大量的重构和改进。

新UIL版本（1.9.2）即将发生的变化：

可以从UI threadNew Disk Cache API调用ImageLoader（更灵活）。基于Jake Wharton的DiskLruCache的新LruDiscCache。

考虑所有这些Android-Universal-Image-Loader套件您的要求（将图像加载到本地磁盘上）！

Answer 3

我想与这三个图书馆分享我的经验：UIL，Picasso和Volley。我之前使用的是UIL，但后来我得出结论我不能真正推荐它，我建议使用Volley或Picasso，这些都是由才华横溢的团队开发的。 UIL一点也不差，但它缺乏对其他两个库的细节的关注。

我发现UIL对UI性能的影响不大;它倾向于比Volley或Picasso更多地锁定UI线程。这可能部分是由于UIL不支持批量处理图像响应而Picasso和Volley默认情况下这样做。

另外，我不喜欢UIL的磁盘缓存系统。虽然您可以在各种实现之间进行选择，但我需要指出的是，目前无法通过总大小和实体到期时间来限制UIL磁盘缓存。 Volley和Picasso这样做，他们默认使用服务器返回的到期时间，而UIL忽略它。

最后，UIL允许您设置全局图像加载器配置，其中包括所选的磁盘缓存和内存缓存实现和设置以及其他详细信息，但此配置将应用于应用程序的任何位置。因此，如果你需要更多的灵活性，比如两个独立的磁盘缓存，那么对于UIL来说是不行的。另一方面，Volley允许您拥有任意数量的单独图像加载器，每个图像加载器都有自己的配置。 Picasso默认使用全局实例，但也允许您构建单独的可配置实例。

总结一下：Picasso拥有最好的API，但它使用所有HttpURLConnection实例之间共享的全局HTTP磁盘缓存，在某些情况下这可能过于严格。 Volley具有最佳性能和模块性，但用户友好性较低，需要您自己编写一个或两个模块才能使其按您的需要工作。总的来说，我会推荐他们两个对抗UIL。

编辑（2014年12月18日）：自从我写下这个初步答案后情况发生了变化，我认为有必要改进它：

Picasso 2.4比旧版本更具可配置性，当与OkHttp（强烈推荐）一起使用时，它也可以为每个实例使用单独的磁盘缓存，因此您可以做的事情没有任何限制。更重要的是，我注意到Picasso和OkHttp的性能已经有了很大的改进，在我看来，它现在是Android上最快的图像加载器解决方案。请注意，在我的代码中，我总是将.fit()与.centerCrop()或.centerInside()结合使用，以降低内存使用量并避免UI线程上的位图大小调整。毕加索积极开发和支持，这当然是一个很大的优势。

Volley的变化并没有那么多，但我同时注意到它有两个问题：

• 有时在负载较重的情况下，由于某些磁盘缓存损坏，某些映像不再被加载。
• NetworkImageView中显示的缩略图（缩放类型设置为centerCrop）与其他库相比非常模糊。

出于这些原因，我决定停止使用Volley。

UIL仍然很慢（尤其是磁盘缓存），其API经常会发生变化。

我还测试了这个名为Glide 3的新库，它声称比Picasso更加优化了Picasso-like API。根据我的个人经验，即使与OkHttp结合使用，在重载下的网络请求期间它实际上比Picasso和Volley慢。更糟糕的是，在离开活动时，它在Lollipop下的应用程序引起了一些崩溃。它仍然比竞争对手有两个优势：

• 它支持动画GIF解码
• 它将最终缩小的位图放在磁盘缓存中，这意味着从磁盘缓存中读回非常快。

结论：我现在建议使用Picasso + OkHttp，因为它提供了最佳的灵活性，API，性能和稳定性。如果您需要GIF支持，您也可以考虑Glide。

Answer 4

我已经实现了一个应该不断获取并显示来自互联网的图像的应用程序。我正准备编写一个图像缓存机制，之前朋友推荐我使用通用图像加载器。

UIL非常好定制。它是如此可定制，以至于新手很容易出错。但是，UIL在我的应用程序中很慢，而且变得有点慢。我的用例是带有图像的ListView。

昨天我一直在寻找UIL的替代品，我发现了毕加索。毕加索易于整合和使用：只需Picasso.context(context).load(url).into(imageview)，图像可以更快，更顺畅地集成。

对我来说，毕加索绝对是使用的API。我对UIL的经历并不好。

Answer 5

我认为与Picasso库相比，ImageLoader更具可定制性和灵活性。