Develop Reference

Android Picasso store files or use cache

I'm using Picasso to initially download images of products to my app from a server. Since the images aren't changing nearly at all for a certain product, I save the images to the disk from the ImageView. In the app I have to display these images all over again in different sizes. To do so I'm using Picasso again, loading the saved file into an ImageView and do fit().centercrop() so I don't get any OutofMemory issues.
Since Picasso is also capable of using OkHttp's cache and doing the caching by its own, I want to know:
Are there any advantages about letting Picasso do the caching, over saving it to storage manually and handing it over again to Picasso later?
And would it be a good way to store the shrinked image (after using .fit()) as a new file so the calculation hasn't to be done all the time.

Picasso v/s Imageloader v/s Fresco vs Glide vs Coil [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
The community reviewed whether to reopen this question 9 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Findings:
Difference between Picasso v/s ImageLoader here
...
Info about the library GLIDE here ...
Facebook has its own library
Fresco
Newest addition to the list Coil
Questions:
What is the difference between Picasso v/s Imageloader v/s Fresco v/s Coil
Which is the best library to use.
If each library has its own significance, what are they ?

I am one of the engineers on the Fresco project. 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. You can get it at our GitHub repo.
I should also point out that Fresco is available on Maven Central, as com.facebook.fresco:fresco.
Fresco offers features that Picasso, UIL, and Glide do not yet have:
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.
There are many others (see our documentation), but these are the most important.

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.
Having used Fresco the least, the answer might evolve as I continue to use and understand it for current exploits. The used personally is having used the library atleast once in a completed app.
*Note - Fresco now supports GIF as well as WebP animations

Fresco sources | off site
(-)
Huge size of library
No Callback with View, Bitmap parameters
SimpleDraweeView doesn't support 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)
GIF support
WebP and Animated Webp support
Picasso sources | off site
(-)
Slow loading big images from internet into ListView
(+)
Tinny size of library
Small size of cache
Simple to use
UI does not freeze
WebP support
Glide sources
(-)
Big size of library
(+)
Tinny size of cache
Simple to use
GIF support
WebP support
Fast loading big images from internet into ListView
UI does not freeze
BitmapPool to re-use memory and thus lesser GC events
Universal Image Loader sources
(-)
Limited functionality (limited image processing)
Project support has stopped since 27.11.2015
(+)
Tinny size of library
Simple to use
Tested by me on SGS2 (Android 4.1) (WiFi 8.43 Mbps)
Official versions for Java, not for Xamarin!
October 19 2015
I prefer to use Glide.
Read more here.
How to write cache to External Storage (SD Card) with Glide.

These answers are totally my opinion
Answers
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.

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. In addition, it also helps preventing an app from popular OutOfMemoryError. GIF Animation loading is a killing feature provided by Glide. Anyway Picasso decodes an image with better quality than 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. The rest would do your job great!
Method count of Picasso and Glide are at 840 and 2678 respectively.
Picasso (v2.5.1)'s size is around 118KB while Glide (v3.5.2)'s is around 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 use less memory by default with RGB_565.
+1 For Picasso Palette Helper.
There is a post that talk a lot about Picasso vs Glide post

I want to share with you a benchmark I have done among Picasso, Universal Image Loader and Glide.
Fresco was out of the benchmark because for the project I was running the test, we didn't want to refactor our layouts (because of the Drawee view).
What I recommend is Universal Image Loader because of its customization, memory consumption and balance between size and methods.
If you have a small project, I would go for Glide (or give Fresco a try).

Whether picasso supports image disk caching

Before I had worked on Volley and I have used the DiskLruCache [link] with Volley to cache images on disk.
Now I have been working with app that is using Picasso.
I would like to know whether Picasso supports disk caching.
If it supports how can I fix the cache size.
Which will be useful when loading images from remote with disk caching?

Picasso supports disk caching, and it's relying on the HTTP client for this.
If you're using it with OkHttp, the default size for the disk cache will be around 50 MB (2% of total space, max 50MB, min 5MB).
If this doesn't meet your needs, you can either implement your own disk cache or manually initialise the OkHttpDownloader with a larger disk cache size when you initialise your Picasso using the Picasso.Builder.
I would recommend the latter, it should look something like
new Picasso.Builder(context).downloader(new OkHttpDownloader(MAX_CACHE_SIZE)).build();

Loading drawable from web file format to drawable, not using bitmap Android

I have a slight problem. I'm trying to dynamically load images (Jpeg, PNG, etc) from the web and display them in my Android App. This works 99% of the time. However, sometimes the images tend to be so large, that the bitmap blows through the available memory and causes OutOfMemoryExceptions.
I find that, even though a 3000px by 3000px Jpeg might be only 200 kilobytes, the resulting bitmap can be hundreds of megabytes. Is there a way to load Jpeg/PNG files from the web, into a drawable without converting to a bitmap first?

Playing with bitmap in android is a little tricky, I highly recommend you to read THIS and THIS link from android developer site to get better idea how to load bitmap into memory efficiently.
You can also use Universal Image Loader library which is very powerful and plugable library.
It takes care of loading bitmap efficiently into memory and there are lots of configuration for you. It also download the image for you from the web.
You can set memory or disc cache for it. Also specify amount of cache size.
You can provide you custom image downloader for example in case you need authentication.
You can set FileNameGenerator for cache files.
You can set to consider ExifParams.
Set image scale type
UIL can load bitmap from file based on its ImageView container size. So you have better memory management. instead of loading a big size image, it will load a scaled down version of image base on ImageView size.
and lost of other options

Local image caching solution for Android: Square Picasso, Universal Image Loader, Glide, Fresco?

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)

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.

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)!

I would like to share my experience with these 3 libraries: UIL, Picasso and Volley. I previously used UIL but then I came to the conclusion I can't really recommend it and I would suggest to use Volley or Picasso instead which are both developed by highly talented teams. UIL is not bad at all but it lacks the attention to detail of the other two libraries.
I found UIL being less nice with the UI performance; it tends to lock up the UI thread more than Volley or Picasso. This may be in part due to the fact that UIL does not support batching the image responses while Picasso and Volley do that by default.
Also, I didn't like the disk cache system of UIL. While you can choose between various implementations, I need to point out that at the moment there is no way to limit the UIL disk cache both by total size and by entity expiration time. Volley and Picasso do that, and they use the expiration time returned by the server by default while UIL ignores it.
Finally, UIL allows you to set a global image loader configuration which includes the selected disk cache and memory cache implementations and settings and other details, but this configuration will be applied everywhere in your app. So if you need more flexibility like two separate disk caches, it's a no go for UIL. Volley on the other hand allows you to have as many separate image loaders as you want, each with its own configuration. Picasso uses a global instance by default but also allows you to build separately configurable instances.
To sum it up: Picasso has the best API but it uses the global HTTP disk cache shared between all HttpURLConnection instances, which can be too restrictive in some cases. Volley has the best performance and modularity but is less user friendly and will require that you write a module or two of your own to make it work like you want. Overall I would recommend them both against UIL.
Edit (Dec 18 2014): Things have changed since I wrote this initial answer and I felt it was necessary to improve it:
Picasso 2.4 is even more configurable than older releases, and when used with OkHttp (which is highly recommended) it is also able to use a separate disk cache for each instance so there is really no restriction in what you can do.
More importantly, I noticed that the performance of Picasso and OkHttp has improved a lot and in my opinion it's now the fastest image loader solution for Android, period. Please note that in my code I always use .fit() in combination with .centerCrop() or .centerInside() to lower memory usage and avoid bitmap resizes on the UI thread. Picasso is actively developed and supported and that's certainly a big plus.
Volley hasn't changed that much but I noticed two issues with it in the meantime:
Sometimes under heavy load, some images are not loaded any more because of some disk cache corruption.
Thumbnails displayed in a NetworkImageView (with its scale type set to centerCrop) are quite blurry compared to what you get with the other libraries.
For these reasons I decided to stop using Volley.
UIL is still slow (especially the disk cache) and its API has a tendency to change quite often.
I also tested this new library called Glide 3 which claims to be more optimized than Picasso with a Picasso-like API. According to my personal experience it's actually slower than Picasso and Volley during network requests under heavy load, even when used in combination with OkHttp. Worse, it caused a few crashes with my apps under Lollipop when leaving an activity. It still has 2 advantages over its competitors:
It supports animated GIFs decoding
It puts the final downscaled bitmaps in the disk cache, which means reading back from the disk cache is extremely fast.
Conclusion: I now recommend to use Picasso + OkHttp because it provides the best flexibility, API, performance and stability combined. If you need GIF support you can also consider Glide.

I have implemented an app that should constantly get and show images from the internet. I was about to program an image cache mechanism, before that a friend recommended me the universal image loader.
The UIL is very good customizable. It's so customizable that a newbie can easily make something wrong. However, the UIL was slow in my application and it became a bit slower. My use case was a ListView with images.
Yesterday I was looking for an alternative to the UIL, and I discovered Picasso. Picasso was easy to integrate and to use: Just Picasso.context(context).load(url).into(imageview) and the image could be faster and smoothly be integrated.
For me, Picasso is definitely the API to use. My experience with UIL wasn't good.

I think ImageLoader is more customizable and flexible comparing to Picasso library.