Menu
I am looking for an asynchronous image loading and caching library in Android. I was going to use Picasso, but I found Universal Image Loader is more popular on GitHub. Does anyone know about these two libraries? A summary of pros and cons would be great.
(All my images are on disk locally, so I don't need networking, therefore I don't think Volley is a fit)
643
Glide's loading times are faster and it uses a small amount of memory for cache, but the library size is quite large. It, too, is easy to implement. Glide might be a better alternative to Picasso when memory footprint is less of a concern or more and larger images need to be processed.
How does the Glide caching mechanism work? By default, Glide uses memory and disk caching to avoid unnecessary network calls, it checks into multiple layers of caches before initiating a new request call for an image.
By default, they will store into a local disk first for the extended keeping cache. Then the memory, for the instance usage of the cache. You can use the built-in indicator in Picasso to see where images form by enabling this.
Fresco is a graphics library for displaying and managing images in Android applications. It caches the image in a memory-efficient manner. One of the most important features is that it displays a placeholder image until the image loads from the URL. This saves on data and makes efficient use of the CPU.
Update Sep 2018: After several years, I needed the almost same thing for a local image caching solution. This time around, UIL has not been in active development. I compared the popular libraries, and the conclusion is pretty no-brainer: just use Glide. It's much more powerful and configurable. Years ago I had to fork and make changes to UIL. Glide supports all my use cases in terms of caching strategy and multiple levels of resolution caching with custom keys. Just use Glide!
Koushik Dutta's comparison is mostly for speed benchmark. His post only touched very basic things, and is not specific for local images. I'd like to share my experiences with Picasso and UIL after I asked the question. Both Picasso and UIL can load local images. I first tried Picasso and was happy, but later I decided to switch to UIL for more customization options.
Picasso:
Picasso's fluent interface is nice. But jumping around with "with", "into", "load" you actually don't know what's behind the scene. It's confusing what's returned.
Picasso allows you to specify exact target size. It's useful when you have memory pressure or performance issues, you can trade off some image quality for speed.
Images are cached with size in its key, it's useful when you display images with different sizes.
You can customize the memory cache size. But its disc cache is only for http requests. For local images, if you care about loading speed, it's good to have a thumbnail disk cache so you don't have to read several MBs for an image every time. Picasso does not have this mechanism resizing and saving thumbnails on disk.
Picasso does not expose the access to its cache instance. (You can get a hold of it when you first configure Picasso and keep it around...).
Sometimes you want to asynchronously read image into a bitmap returned by a listener. Surprisingly Picasso doesn't have that. "fetch()" dose not pass back anything. "get()" is for synchronously read, and "load()" is for asynchronously draw a view.
Picasso only has a few simple examples on the homepage, and you'll have to read through the unordered javadoc for advanced usages.
UIL:
UIL uses builders for customization. Almost everything can be configured.
UIL does not allow you to specify the size you want to load into a view. It uses some rules based on the size of the view. It's not as flexible as Picasso. I have no way to load a lower resolution image to reduce memory footprint. (Edit: this behavior can be easily modified by adding an ImageSize argument in in the source code and bypass the view size checking)
UIL provides customizable disc cache, you can use this to cache the thumbnails with specified size. But it's not perfect. Here are the details. (Edit: if you care about speed and want multiple levels of thumbnail caching, like my case, you can modify the source code, let the disk cache use "memoryKey", and make it also size sensitive)
UIL by default caches images of different sizes in memory, and it can be turned off in configuration.
UIL exposes the backing memory and disk cache you can access.
UIL provides flexible ways you can get a bitmap or load to a view.
UIL is better in documentation. UIL gives the detailed usages on the Github page, and there's a linked tutorial.
I suggest starting with Picasso, if you need more control and customization, go for UIL.
141
If you read this post on G+ by Koush you will get clear solutions for your confusions, I have put the summary of that, in that Android-Universal-Image-Loader is the winner for your requirement!
Picasso has the nicest image API if you are using network!
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(if you are using network)
Android-Universal-Image-Loader is the most popular one out there
currently. Highly customizable.
This project aims to provide a reusable instrument for asynchronous image loading, caching and displaying. It is originally based on Fedor Vlasov's project and has been vastly refactored and improved since then.
Upcoming changes in new UIL version (1.9.2):
Possibility to call ImageLoader out of UI threadNew Disk Cache API (more flexible). New LruDiscCache based on Jake Wharton's DiskLruCache.
Considering all this Android-Universal-Image-Loader suites your requirement (Loading the images are on disk locally)!
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
