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).
Related
I have a question about mechanisms used by Picasso for downloading and caching images.
How does Picasso download an image? I know that it is using in sample size. Am I right? If image on a server is 1000x1000 but ImageView is only 400x400 then it will be download only 500x500 image and it will be cached. Or maybe it will be downloaded in full resolution and then scaled to a specific size.
Here is actual code I am - and I'm sure many more people are - using
Picasso.with(context).load(url).fit().centerCrop().into(imageView);
Picasso has no way of knowing it should download only 500*500 pixels. The fit() and centercrop() methods will make it fit even when picture is bigger than needed.
You can browse source-code of Picasso at: https://github.com/square/picasso.
Downloading images
You can see that Picasso downloads images with implementation of Downloader interface. It uses default downloader named OkHttpDownloader, which utilizes OkHttp library. When it can't be loaded, Picasso uses UrlConnectionDownloader.
Recognizing size of the images
Picasso doesn't know size of the images before download. If you are developing back-end server, you can specify size of the images in some way, so your mobile application will know it by performing a concrete request, but it can't be recognized by Picasso itself. Picasso has to download image in a full size and then this image can be cropped or resized by this library.
Cache
We can find the following information about Cache in the Picasso documentation placed in source code:
Picasso instance is automatically initialized with defaults that are
suitable to most implementations.
LRU memory cache of 15% the available application RAM
Disk cache of 2% storage space up to 50MB but no less than 5MB. (Note: this is only available on API 14+ or if you are using
a standalone library that provides a disk cache on all API levels like
OkHttp)
Three download threads for disk and network access.
It explains usage of cache in this library quite clearly.
I'm just not sure, if Picasso stores images before transformation (resizing, cropping, etc.) or after transformation in cache. First option seems more reasonable for me, because we decide to apply a different transformation later, so we may want to keep original image.
I need to access an image that has been cached after it has been transformed (or cropped) using Picasso.
What I am doing is taking a large image resource, cropping a screen-size piece of it out of it at run-time, and setting it to the background of a RelativeLayout. So far I have used Picasso to accomplish this successfully.
Later in the app, I change the app layout by calling:
setContentView(R.layout.OTHER_LAYOUT);
I would like to then access the cache where Picasso stored the cropped version of the image, and dynamically set the background of OTHER_LAYOUT to the stored version of the cropped image.
This S.O. post seems relevant to accessing a bitmap cached by Picasso on device.
I am considering giving this solution a try. But one user's comment (a comment on the accepted answer) makes me wonder if there is a better way. Complicated solutions often seem more bug-prone.
"it seems can work. but in my opinion, it is not well offer. files are being saved somewhere. lib should give them to developers. it would be good instead of adding millions feature to picasso lib, adding very simple and essential features. I gave up to use picasso because of this. It has millions garbage features and very limited nice features."
Is there some way that Picasso allows me to access the image that was transformed and cached, and use it somewhere else (in a way that is simple & easy to use)?
If not, would another library give me greater convenience?
Don't think too much about reusing cached images, Picasso is very good at that and is well optimized for it. Just load the same URL / drawable and apply the transformation. If Picasso already cached it, it will be very fast, you can check if it is cached by setIndicatorsEnabled(true) on Picasso instance.
When dealing with images in android for bitmap objects I used to recycle them in order to save when moves to the next screen.
But there are times I had to use drawable s instead of bitmaps any way of dealing with these.
Recycle drawable objects just like bitmaps bitmap.recycle() method.
Thanks
You can use third party image libraries. Some good libraries are:
Nostra’s Universal Image loader
Picasso
UrlImageViewHelper by Koush
Volley – by Android team # Google (mainly network library)
Novoda’s Image loader (depraceted)
Additionally you can check technotalkative blog for more details:
Here you go with libraries for better image management:
Picasso
Fresco
I gave you links to description of libraries on purpose, so you get to know them at least a bit before you just drop them in project. Understanding what they are for and basic concepts about them it will will save you a lot of time later.
Here is how to apply HolderPattern to your list to avoid creating of new object over and over.. Again I would advice to read carefully not just to copy-paste.
One more useful tip and more material to learn - Managing Bitmap Memory ;)
Welcome to Android development ;)
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.
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.
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.
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 .
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
Volly can also be used to load files on disk.
Use:
networkImageView.setImageUrl(Uri.fromFile(newFile(filename)).toString(),mImageFetcher);