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

Question

I'm looking for an open source image loading/caching solution.

I am looking in to:

Google's Volley,

Square's Picasso

Universal Image Loader

I want to be able to handle async image loads from disk as well as network, however I'm not sure if Google's volley handle's loading from disk.

Does Volley allow resource loading from disk??

An example of what I would like to do is available with AQuery.

Loculus

Notice a good answer in stackoverflow.com/questions/19995007/… – Depilatory

Answer 1

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

Rubenrubens

this seems to be the case, unfortunately. I liked that feature of picaso, so I will have to choose.... – Loculus

Answer 2

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.

Dovecote

+1, Interesting ! Volley have it's own image loader class (NetworkImageView), can you explain what is the advantage of plugging volley into Glide ? why can't we directly use NetworkImageView? – Alleman

Essentially Volley's image loading code is rudimentary at best. It's really focused on network operations, the image loading code seems like it was added as an afterthought. Glide gives you a large number of things that Volley's NetworkImageView doesn't, including vastly more efficient disk and memory caches, as well as bitmap recycling, exif handling, and a large number of optimizations to make image loading smooth and fast. I used Volley for Glide because I wanted to include support for displaying remote images and it seemed like the best library available to do so. – Dovecote

@Monkeyless hi! Is there a way to tell Glide which Bitmap.Config to use when loading bitmaps? E.g. if I want to force some specific one. – Salahi

Hi, thanks for the question! Unfortunately there isn't a straightforward way to do this. Your best bet would be to apply a Transformation that converted the Bitmap to the specific type you want. Glide tries to be intelligent about choosing the format to save memory (RGB_565 is 2 bytes per pixel and ARGB_8888 is 4 bytes per pixel), but that doesn't make it straightforward to change. I'll do my best to make this easier in the upcoming 3.0 branch: (github.com/bumptech/glide/tree/3.0a) – Dovecote

It even has Volley integration! I'll have a look at it. +1!! – Nike

@SamJudd you said "I used Volley for Glide because I wanted to include support for displaying remote images and it seemed like the best library available to do so.". What is the meaning of "remote images" here? As far as i know, Glide can load images easily from network by just providing the url. Is the statement is for old version of Glide? – Metralgia

Answer 3

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.

Alleman

Answer 4

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 .

Auberbach

thanks for comment, but I am looking for a way to load existing images from files, not caching. I was hoping Volley would handle loading images async and all the performance issues with loading images. – Loculus

Ah my apologies. Volley being a network request library I assumed you were after cache from disk. As far as i know it does not have any classes for loading assets from disk. – Auberbach

This isn't true. Look at CacheDispatcher and DiskBaseCache classes in the Volley source. – Griggs

You are correct. Early on there was little documentation. Shortly after I wrote the original blog I figured out how the desired approach for implementing Volley and updated the blog to reflect the correct approach. – Auberbach

Answer 5

Just use Picasso library :

Picasso.get()
  .load("/images/oprah_bees.gif")
  .resize(50, 50)
  .centerCrop()
  .into(imageView)

This will allow you to load specific file from SD and you can pass the imageView too where u can set this image.

To Read more feature into Picasso Library

Leibniz

Answer 6

Volly can also be used to load files on disk.

Use:

networkImageView.setImageUrl(Uri.fromFile(newFile(filename)).toString(),mImageFetcher);

Tapestry