Which provides better Image Loading/Caching - Volley or Picasso?

I have collected few important information from http://blog.bignerdranch.com/3177-solving-the-android-image-loading-problem-volley-vs-picasso/ (the comparison between older ver Picasso 2.0 vs volley)

Picasso is totally focused on image loading. As a result, if you have quirks in your image loading process

Volley, on the other hand, is totally focused on handling individual, small HTTP requests. So if your HTTP request handling has some quirks, Volley probably has a hook for you. If, on the other hand, you have a quirk in your image handling, the only real hook you have is ImageCache. It’s not nothing, but it’s not a lot, either.but it have more other advantages like Once you define your requests, using them from within a fragment or activity is painless. And unlike parallel AsyncTasks

Picasso does just one thing, while Volley tries to solve a more general problem.

Android does not handle high-res images well at all. I have a small obsession with the pattern of catching OutOfMemoryError in Android apps. It seems like a ridiculous tactic, but Volley is the only way to reliably handle some image scenarios compare to hassle with Picasso's scaling and fitting big images correctly. Picasso doesn’t respect the scaleType attribute on your ImageViews(not sure it's is fixed in latest ver).

Test Ex: I found that Volley catches OutOfMemoryError while loading the original resolution image instead of the thumbnail version, comparing to the Picasso version doesn’t blow up (it catches OutOfMemoryError, too), but picasso fails to load any images that are too large. Not only does Volley not blow up, but Volley displays all these large images!!!.

According to Android Hacker Koushik Dutta:

Testing ALL the Android Image and http Libraries

I've been testing and benchmarking a bunch of the various image loading and http request libraries available, since a couple of them were released in the past week.

Lineup:

• AndroidAsync + UrlImageViewHelper (koush)
• Volley (Google)
• okhttp + Picasso (Square)

All support cached and conditionally cached responses, keep alive, etc.

Thoughts:

• Picasso has the nicest image API. I am going to steal their currying API style for my future/current stuff. Picasso is also noticeably the slowest. Especially on 3g vs wifi. Probably due to their custom okhttp client.
• UrlImageViewHelper + AndroidAsync is the fastest. Playing with these other two great libraries have really highlighted that the image API is quite dated, however.
• Volley is slick; I really enjoy their pluggable backend transports, and may end up dropping AndroidAsync in there. The request priority
  and cancellation management is great.

Update These aren't really http libs. Just image loaders. but there were requests for comparisons in the comments... Android-Universal-Image-Loader is the most popular one out there currently. Highly customizable.

AQuery; like jquery, but for Android? I guess it's nice, if you're into that sort of thing. Don't use this one though; it craps on the UI thread or something. Loading a bunch of images on my Nexus 4 in a listview made it seem like I was back on my HTC G1 all over again. Major stuttering.

Tests with caches clear:

Cold is fresh app start. Warm is caches clear with http connections presumably kept alive.

Cold/Warm (in milliseconds, avg of 10 runs, clearing data every run):

• Picasso 12142/11892
• UrlImage 7378/4525
• Volley 8292/7520
• Android-Universal-Image-Loader 14484/11243
• AQuery 11341/9637 (this one seems to lock up the UI thread... don't use it)

Here's the test code base: https://github.com/koush/AndroidNetworkBench

Conclusion: These tests are hardly conclusive. I just tested concurrent network access with many images. Admittedly, there's more to testing a library than that. I like how Volley plays nice with the Activity lifecycle, for example. None of the other libraries do that.

So, whatever floats your boat really. I(Koush) want Volley with Picasso's API.

volley' Request class deal with all network requests. I have not yet found any class loading resource from disk..

Out of the box Volley does not include its own disk cache implementation. You need to take a DiskLruCache (or a hybrid memory/disk cache if you prefer) and have it implement the Volley ImageCache interface.

This blog post sums up how to implement a disk based cache with Volley to load images: http://blogs.captechconsulting.com/blog/raymond-robinson/google-io-2013-volley-image-cache-tutorial .

If you're ok with newer/less stable software, I just released an open source library called Glide: https://github.com/bumptech/glide

It's designed to allow you to efficiently load any image you can get an InputStream to. It includes some basic http/file loading implementations, but also allows you to plug in your own or use some external library (like Volley) via callbacks.

It includes memory and disk caching, as well as bitmap recycling on newer devices. All you need to do is implement an interface to get an input stream for your data model (path/url/uri etc) and pass it along with whatever transformations, placeholders, or animations you want to the Glide singleton.

Happy to speak with you or anyone who is curious, we've used it extensively at Bump to interface with a variety of libraries.