我是Fresco项目的工程师之一。显然我是有偏见的。

但你不必相信我的话。我们已经发布了一个示例应用程序，允许您并排比较五个库的性能——Fresco, Picasso, UIL, Glide和Volley Image Loader。你可以在我们的GitHub回购。

我还应该指出，在Maven Central上可以买到Fresco，网址是com.facebook.fresco: Fresco。

Fresco提供了毕加索、UIL和Glide还没有的功能:

Images aren't stored in the Java heap, but in the ashmem heap. Intermediate byte buffers are also stored in the native heap. This leaves a lot more memory available for applications to use. It reduces the risk of OutOfMemoryErrors. It also reduces the amount of garbage collection apps have to do, leading to better performance. Progressive JPEG images can be streamed, just like in a web browser. Images can be cropped around any point, not just the center. JPEG images can be resized natively. This avoids the problem of OOMing while trying to downsize an image.

还有许多其他的(请参阅我们的文档)，但这些是最重要的。

这些答案完全是我个人的观点

答案

Picasso is an easy to use image loader, same goes for Imageloader. Fresco uses a different approach to image loading, i haven't used it yet but it looks too me more like a solution for getting image from network and caching them then showing the images. then the other way around like Picasso/Imageloader/Glide which to me are more Showing image on screen that also does getting images from network and caching them. Glide tries to be somewhat interchangeable with Picasso.I think when they were created Picasso's mind set was follow HTTP spec's and let the server decide the caching policies and cache full sized and resize on demand. Glide is the same with following the HTTP spec but tries to have a smaller memory footprint by making some different assumptions like cache the resized images instead of the fullsized images, and show images with RGB_565 instead of RGB_8888. Both libraries offer full customization of the default settings. As to which library is the best to use is really hard to say. Picasso, Glide and Imageloader are well respected and well tested libraries which all are easy to use with the default settings. Both Picasso and Glide require only 1 line of code to load an image and have a placeholder and error image. Customizing the behaviour also doesn't require that much work. Same goes for Imageloader which is also an older library then Picasso and Glide, however I haven't used it so can't say much about performance/memory usage/customizations but looking at the readme on github gives me the impression that it is also relatively easy to use and setup. So in choosing any of these 3 libraries you can't make the wrong decision, its more a matter of personal taste. For fresco my opinion is that its another facebook library so we have to see how that is going to work out for them, so far there track record isn't that good. Like the facebook SDK is still isn't officially released on mavenCentral I have not used to facebook sdk since sept 2014 and it seems they have put the first version online on mavenCentral in oct 2014. So it will take some time before we can get any good opinion about it. between the 3 big name libraries I think there are no significant differences. The only one that stand out is fresco but that is because it has a different approach and is new and not battle tested.

我是Fresco项目的工程师之一。显然我是有偏见的。

但你不必相信我的话。我们已经发布了一个示例应用程序，允许您并排比较五个库的性能——Fresco, Picasso, UIL, Glide和Volley Image Loader。你可以在我们的GitHub回购。

我还应该指出，在Maven Central上可以买到Fresco，网址是com.facebook.fresco: Fresco。

Fresco提供了毕加索、UIL和Glide还没有的功能:

Images aren't stored in the Java heap, but in the ashmem heap. Intermediate byte buffers are also stored in the native heap. This leaves a lot more memory available for applications to use. It reduces the risk of OutOfMemoryErrors. It also reduces the amount of garbage collection apps have to do, leading to better performance. Progressive JPEG images can be streamed, just like in a web browser. Images can be cropped around any point, not just the center. JPEG images can be resized natively. This avoids the problem of OOMing while trying to downsize an image.

还有许多其他的(请参阅我们的文档)，但这些是最重要的。

请注意，这是一个高度基于观点的问题，所以我不再制作峡湾，而是快速制作了一张表格

库比较很困难，因为在很多参数上，所有四个都做同样的事情，可能除了Fresco因为它有一大堆新的内存级别优化。所以，如果你想根据我的经验来比较某些参数，请告诉我。

由于使用Fresco最少，所以随着我继续在当前的漏洞中使用和理解它，答案可能会发生变化。使用者个人在一个完整的应用程序中至少使用过一次库。

*注-壁画现在支持GIF以及WebP动画

壁画来源|场外

(-)

图书馆规模庞大 没有回调视图，位图参数 SimpleDraweeView不支持wrap_content 巨大的缓存容量

(+)

非常快的图像加载器(适用于小型和中型图像) 大量的功能(流，绘图工具，内存管理等) 可以直接在xml中设置(例如圆角) GIF格式支持 WebP和动画WebP支持

毕加索来源|场外

(-)

缓慢加载大图像从互联网到ListView

(+)

图书馆太小了 缓存容量小 使用简单 UI不会冻结 WebP支持

滑翔来源

(-)

图书馆规模大

(+)

缓存的大小很小 使用简单 GIF格式支持 WebP支持 快速加载大图像从互联网到ListView UI不会冻结 BitmapPool重用内存，从而减少GC事件

通用图像加载器源

(-)

功能有限(图像处理有限) 项目自2015年11月27日起停止支持

(+)

图书馆太小了 使用简单

我在SGS2 (Android 4.1)上测试(WiFi 8.43 Mbps) Java的官方版本，不是Xamarin的! 10月19日 我更喜欢用Glide。 点击这里阅读更多。 如何写缓存到外部存储(SD卡)与Glide。

格莱德和毕加索都不是完美的。Glide加载图像到内存并进行缓存的方式比Picasso更好，Picasso让图像加载得更快。此外，它还有助于防止应用程序流行的OutOfMemoryError。GIF动画加载是Glide提供的一个致命功能。总之，毕加索解码的图像质量比格莱德更好。

我更喜欢哪一个?虽然我用毕加索画了这么长时间，但我必须承认我现在更喜欢格莱德。但我建议你将位图格式更改为ARGB_8888，让Glide先缓存全尺寸图像和调整大小的图像。剩下的会很好地完成你的工作!

毕加索和格莱德的方法数分别为840种和2678种。 毕加索(v2.5.1)的大小约为118KB，而Glide (v3.5.2)的大小约为430KB。 Glide按大小创建缓存图像，而Picasso保存完整图像并进行处理，因此在加载时，Glide显示更快，但占用更多内存。 Glide默认使用RGB_565较少的内存。

+1毕加索调色板助手。

有一个帖子谈论了很多关于毕加索和格莱德的帖子