Picasso and thumbnails
Currently I am working of support of old project created by other developers.
I have task to improve images processing.
I can see there, that app creates resized small copy for every image downloaded from server for thumbnails using.
Then images loaded to ImageView with using of BitmapFactory.decodeFile in recycler view.
I know about Picasso and that this is the good practice to use it.
I believe that using of Picasso for creation of thumbnails images for list from original image is better
than creation of separate resized thumbnail for every image.
Is i am correct or maybe wrong ?
You don't have to reinvent the wheel.
If you have to deal with multiples images (for example: a list of images), resize, etc, I think that Picasso is a good option. This library has the best practice in resize, crop, memory leak related with Image.
Of course, is on your own, but you have to use it when it's possible
Nice coding!
Related
I am loading images in a recyclerView using picasso in my app. The image files are all local files. The problem is that the listview scrolling is not smooth, it is jittery. I searched about it and I saw that a lot of people have had similar problems but it is really strange that there is no clear solution available.
Horrible performance when loading local files
Picasso is awesome, but for loading local device images as thumbnails into a gridview (for example), Picasso is slower ...
Recyclerview painfully slow to load cached images form Picasso
From the above links it seems that picasso works great when fetching images from the web but for locally stored images it doesn't do that great.
Is it even recommended to use Picasso in this case? Should I have my own implementation of LruCache and remove Picasso? I have done it without Picasso using caching myself using LruCache. Though the scrolling is flawless in that case but Picasso is much more clean and compact, so I thought it might be the better solution in the long term.
There could a lot of reasons for this kind of behaviour. One issue could be that your row layout may be very deep rather than being wide. Another issue could be the size of images, if images are of large size, there is a good chance that all of them might not fit into Picasso's cache.
If the problem is due to the size of images, you can try Fresco by Facebook. It is very good at loading large images. It uses native as well as ashmem cache, so it can hold large amounts of images in cache compared to other similar libraries like Picasso or Glide. Another thing you can do is, android:largeHeap="true" in your AndroidManifest.xml inside the Application tag.
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.
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).
I am writing an android app which will have an image feed, something like in for example the instagram app. My question is how can I cache these images so i dont get an out of memory exception?
I have read some tutorials, but all of them are caching Bitmaps in LruCache. I might be wrong but as I think the bitmap in the ImageView and a cached one use the same ammount of memory.
I'm thinking about storing the compressed images (for example JPEG) in an in-memory cache (and of course on the disk) and showing it only when it is visible on the screen, but then the CPU will eat up the battery as it will constantly clearing the ImageView when it's not visible and decompressing the image and showing it when it is in the viewport. And I'm not really sure that the scrolling will be lagless, even if I do it on a new thread.
An alternative is to do the same as I described above, but I wont remove the bitmap from the imageview immediately, only when there are a lot of images and i will run out of memory.
What do you think?
Here is an example step-by-step on how to cache images, in memory and disk:
http://androidexample.com/Download_Images_From_Web_And_Lazy_Load_In_ListView_-_Android_Example/index.php?view=article_discription&aid=112&aaid=134
But you can also use libs that already work pretty well like :
http://square.github.io/picasso/
The first link also contains explanation on how you should treat bitmaps to avoid outOfMemory.
Hi and happy new year!
I'm trying to download images from internet and put them into different ImageViews. The ImageViews are dynamically created as the user scrolls. When user arrives to the bottom of the scrollview, I load 10 images more.
The images are loading ok, but when i have a lot of images I get a java.lang.OutOfMemoryError.
I know the problem is that I have a lot of images consuming a lot of memory, so... what's the way to go on my scenario?
Thanks!
Try using a ListView instead of a ScrollView. Then you can use a lazy loading technique like Universal Image Loader. The ListView utilizes view recycling which will be easier on your memory, and you can also cache images using the image loader. This library also has a few options for memory management as well.
You are going to have to keep track of the images you have loaded and start recycling them when they are out of view.
You might find the LruCache a valuable tool. There was a good talk at IO12 "Doing More With Less: Being a Good Android Citizen" that went over lots of memory issues and includes some discussion on how to use the LruCache starting around the 4 minute mark.