Picasso v / s Imageloader v / s Fresco vs Glide [关闭]

本文翻译自：Picasso v/s Imageloader v/s Fresco vs Glide [closed]

Findings: 发现：

1. Difference between Picasso v/s ImageLoader here ... Picasso v / s ImageLoader的区别在这里......
2. Info about the library GLIDE here ... 关于图书馆GLIDE的信息在这里......
3. Now recently Facebook released new image library called Fresco 现在最近Facebook发布了名为Fresco的新图像库

---

Questions: 问题：

1. What is the difference between Picasso v/s Imageloader v/s Fresco Picasso v / s Imageloader v / s Fresco有什么区别
2. When can we use Glide 我们什么时候可以使用Glide
3. Which is the best library to use. 哪个是最好的库。
4. If each library has its own significance, what are they ? 如果每个图书馆都有自己的意义，那么它们是什么？

---

#1楼

参考：https://stackoom.com/question/1zCjx/Picasso-v-s-Imageloader-v-s-Fresco-vs-Glide-关闭

---

#2楼

These answers are totally my opinion 这些答案完全是我的意见

Answers 答案

1. Picasso is an easy to use image loader, same goes for Imageloader. Picasso是一个易于使用的图像加载器，同样适用于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. Fresco使用不同的图像加载方法，我还没有使用它，但它看起来更像是一个从网络获取图像并缓存然后显示图像的解决方案。 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. 然后反过来像Picasso / Imageloader / Glide对我来说更多是在屏幕上显示图像，也可以从网络获取图像并缓存它们。

2. 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尝试与Picasso有些互换。我认为当它们被创建时，Picasso的思维模式遵循HTTP规范，让服务器决定缓存策略并缓存完整大小并按需调整大小。 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. Glide与遵循HTTP规范相同，但通过做出一些不同的假设（例如缓存已调整大小的图像而不是全尺寸图像）来尝试拥有更小的内存占用，并使用RGB_565而不是RGB_8888显示图像。 Both libraries offer full customization of the default settings. 两个库都提供默认设置的完全自定义。

3. 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. Picasso，Glide和Imageloader是备受推崇的，经过良好测试的库，所有这些库都可以使用默认设置轻松使用。 Both Picasso and Glide require only 1 line of code to load an image and have a placeholder and error image. Picasso和Glide都只需要1行代码来加载图像并具有占位符和错误图像。 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. 同样适用于Imageloader，它也是一个较旧的库，然后是Picasso和Glide，但是我没有使用它所以不能说很多关于性能/内存使用/自定义，但是看看github上的自述文件给我的印象是它也是相对容易使用和设置。 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. 对于壁画我的意见是它的另一个facebook库，所以我们必须看看它将如何为他们解决，到目前为止，跟踪记录并不是那么好。 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. 就像facebook SDK还没有在mavenCentral上正式发布 我从2014年9月开始就没有用过facebook sdk了，似乎他们已经在2014年10月将第一个版本放到mavenCentral上了。所以我们需要一些时间才能获得任何很好的意见。

4. between the 3 big name libraries I think there are no significant differences. 我认为3个大牌库之间没有显着差异。 The only one that stand out is fresco but that is because it has a different approach and is new and not battle tested. 唯一脱颖而出的是壁画，但那是因为它采用了不同的方法而且是新的而不是经过战斗测试。

---

#3楼

I am one of the engineers on the Fresco project. 我是Fresco项目的工程师之一。 So obviously I'm biased. 显然我有偏见。

But you don't have to take my word for it. 但你不必接受我的话。 We've released a sample app that allows you to compare the performance of five libraries - Fresco, Picasso, UIL, Glide, and Volley Image Loader - side by side. 我们发布了一个示例应用程序，可以让您比较五个库的性能--Fresco，Picasso，UIL，Glide和Volley Image Loader - 并排。 You can get it at our GitHub repo . 你可以在我们的GitHub回购中获得它。

I should also point out that Fresco is available on Maven Central, as com.facebook.fresco:fresco . 我还应该指出，Fresco可以在Maven Central上获得，如com.facebook.fresco:fresco 。

Fresco offers features that Picasso, UIL, and Glide do not yet have: Fresco提供Picasso，UIL和Glide尚未提供的功能：

1. Images aren't stored in the Java heap, but in the ashmem heap. 图像不存储在Java堆中，而是存储在ashmem堆中。 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. 它降低了OutOfMemoryErrors的风险。 It also reduces the amount of garbage collection apps have to do, leading to better performance. 它还减少了应用程序必须执行的垃圾回收量，从而提高了性能。
2. Progressive JPEG images can be streamed, just like in a web browser. 渐进式JPEG图像可以流式传输，就像在Web浏览器中一样。
3. Images can be cropped around any point, not just the center. 图像可以在任何点周围裁剪，而不仅仅是中心。
4. JPEG images can be resized natively. JPEG图像可以原生调整大小。 This avoids the problem of OOMing while trying to downsize an image. 这样可以避免在尝试缩小图像尺寸时出现OOMing问题。

There are many others ( see our documentation ), but these are the most important. 还有很多其他的（ 参见我们的文档 ），但这些是最重要的。

---

#4楼

Mind you that this is a highly opinion based question, so I stopped making fjords and made a quick table 请注意，这是一个基于意见的问题，因此我不再制作峡湾并快速制作表格

Now library comparison is hard because on many parameters, all the four pretty much do the same thing, except possibly for Fresco because there is a whole bunch of new memory level optimizations in it.So let me know if certain parameters you'd like to see a comparison for based on my experience. 现在库比较很难，因为在许多参数上，所有这四个几乎都做同样的事情，除了Fresco，因为它有一大堆新的内存级别优化。所以让我知道你是否想要某些参数根据我的经验看一个比较。

Having used Fresco the least, the answer might evolve as I continue to use and understand it for current exploits. 最少使用Fresco后，答案可能会随着我继续使用并在当前漏洞利用中理解它而发展。 The used personally is having used the library atleast once in a completed app. used personally使用的是在已完成的应用程序中至少使用过一次库。

*Note - Fresco now supports GIF as well as WebP animations *注意 - Fresco现在支持GIF和WebP动画

---

#5楼

Neither Glide nor Picasso is perfect. 格莱德和毕加索都不是完美的。 The way Glide loads an image to memory and do the caching is better than Picasso which let an image loaded far faster. Glide将图像加载到内存并进行缓存的方式比Picasso更好，后者可以更快地加载图像。 In addition, it also helps preventing an app from popular OutOfMemoryError. 此外，它还有助于防止应用程序受欢迎的OutOfMemoryError。 GIF Animation loading is a killing feature provided by Glide. GIF动画加载是Glide提供的杀戮功能。 Anyway Picasso decodes an image with better quality than Glide. 无论如何，毕加索解码的图像质量比Glide更好。

Which one do I prefer? 我更喜欢哪一个？ Although I use Picasso for such a very long time, I must admit that I now prefer Glide. 虽然我使用毕加索这么长时间，但我必须承认我现在更喜欢格莱德。 But I would recommend you to change Bitmap Format to ARGB_8888 and let Glide cache both full-size image and resized one first. 但我建议你将位图格式更改为ARGB_8888，然后让Glide缓存全尺寸图像并先调整大小。 The rest would do your job great! 剩下的就是你的工作！

• Method count of Picasso and Glide are at 840 and 2678 respectively. Picasso和Glide的方法计数分别为840和2678。
• Picasso (v2.5.1)'s size is around 118KB while Glide (v3.5.2)'s is around 430KB. 毕加索（v2.5.1）的大小约为118KB，而Glide（v3.5.2）的大小约为430KB。
• Glide creates cached images per size while Picasso saves the full image and process it, so on load it shows faster with Glide but uses more memory. Glide为每个尺寸创建缓存图像，而Picasso保存完整图像并对其进行处理，因此在加载时，它会更快地显示Glide但使用更多内存。
• Glide use less memory by default with RGB_565 . 使用RGB_565 Glide默认使用更少的内存。

+1 For Picasso Palette Helper . +1为毕加索调色板助手 。

There is a post that talk a lot about Picasso vs Glide post 有一篇文章谈论毕加索与格莱德的帖子

---

#6楼

Fresco sources | Fresco 来源 | off site 场外
(-) （ - ）
- Huge size of library - 图书馆规模庞大
- No Callback with View, Bitmap parameters - 没有使用View，Bitmap参数的回调
- SimpleDraweeView doesn't support wrap_content - SimpleDraweeView不支持wrap_content
- Huge size of cache - 巨大的缓存大小
(+) （+）
- Pretty fast image loader (for small && medium images) - 非常快的图像加载器（适用于小型和中型图像）
- A lot of functionality(streaming, drawing tools, memory management, etc) - 许多功能（流媒体，绘图工具，内存管理等）
- Possibility to setup directly in xml (for example round corners) - 可以直接在xml中设置（例如圆角）
- GIF support - GIF支持
- WebP and Animated Webp support - WebP和Animated Webp支持

Picasso sources | 毕加索 来源 | off site 场外
(-) （ - ）
- Slow loading big images from internet into ListView - 慢速将大图像从互联网加载到ListView中
(+) （+）
- Tinny size of library - 图书馆的大小
- Small size of cache - 小尺寸的缓存
- Simple in use - 使用简单
- UI is not freeze - UI不冻结
- WebP support - WebP支持

Glide sources 滑翔 源

(-) （ - ）
- Big size of library - 大型图书馆
(+) （+）
- Tinny size of cache - Tinny大小的缓存
- Simple in use - 使用简单
- GIF support - GIF支持
- WebP support - WebP支持
- Fast loading big images from internet into ListView - 快速将大图像从互联网加载到ListView
- UI is not freeze - UI不冻结
- BitmapPool to re-use memory and thus lesser GC events - BitmapPool重用内存，从而减少GC事件

Universal Image Loader sources 通用图像加载器 源

(-) （ - ）
- Limited functionality (limited image processing) - 功能有限（图像处理有限）
- Project support has stopped since 27.11.2015 - 项目支持自2015年11月27日起停止
(+) （+）
- Tinny size of library - 图书馆的大小
- Simple in use - 使用简单

---

Tested by me on SGS2 (Android 4.1) (WiFi 8.43 Mbps) 我在SGS2（Android 4.1）上测试（WiFi 8.43 Mbps）
Official versions for Java, not for Xamarin! Java的官方版本，不适用于Xamarin！
October 19 2015 2015年10月19日

I prefer to use Glide. 我更喜欢使用Glide。
Read more here . 在这里阅读更多。
How to write cache to External Storage (SD Card) with Glide. 如何使用Glide 将缓存写入外部存储（SD卡） 。