in my recent android project I have to get a large number of images from the web and show them in my main activity (something like explore part of the Instagram app). I used a recyclerView with gridLayoutManager of 3 columns and I have to get something like 700 images from URL. When I open the app and comment the getting image part, app work perfectly fine (the app get the information of each tile but doesn't display the images). But when I start setting image bitmaps the app start becoming laggy and crash after about a hundred images loaded.
What do you recommend me to do ?
And another question: Was using recyclerView a smart idea ?
Thanks for your reply.
Don't load hundreds of images. That requires a few things:
1)Don't store images in memory in the adapter. Store the url/resourceid/whatever of the image so you can load it on demand.
2)Use an LRU cache of images, limited in size and load your images through that.
3)Make sure that however you download images does not spawn too many concurrent requests, and that requests are canceled when no longer needed (when the view it would go into is recycled).
4)I'd suggest downloading the images and writing them to disk, then loading them from disk as needed. This will prevent you from having to keep the entire file in memory to decode it while downloading it, which will reduce your memory usage while downloading.
5)Do not decode the image on the UI thread. Do it on another thread.
6)If you don't need to display images fullsize, make thumbnails.
Images in a RecyclerView, especially if being downloaded need a lot of work to do well and handle rapid scrolling.
You should post some code here but seems you are asking for some efficient setup.
First of all, try using some image caching libraries like Glide or
Picasso. It manages and caches your images locally so you don't end up
making multiple requests for the same image.
This solves most of your problem and don't try to load 700 images
altogether and display use lazy loading means load first 10-20 images
first and when user scrolls make another API call for another 10-20
and so on.
Here is an article on how to use Glide and how it works.
https://futurestud.io/tutorials/glide-image-resizing-scaling
Related
In my application I have to show many images (say >1000).
All these images comes from network. For now, I am downloading all images and passing them to an adapter which was set to GridView.
My problem is downloading all images at once occupies a lot of runtime memory. So I want to change my design.
Is there any way to handle images/bitmaps in large number effectively? Like downloading 100 images, then again another 100 erasing previous 100 (as per need).
You can try these optimisations:
Decrease number of images, do you really need 100 in one go?
Download image thumbnails, do you really need full-sized non-compressed images?
Cache next images, pre-load some images before user asks for them
Profile your app, see where time is consumed
Use several threads, at least one for pulling data and one for UI
I think you need to take a look at UIL
Which is helpful to you.
I'm trying to create a CRUD android application.
Now, when the List Activity is shown, it will display the items created along with a thumbnail of the original image.
What is the best practice for displaying a thumbnail in an Android application with Volley? Should I generate a thumbnail for the images uploaded or just re-size the image at the client side?
It's hard to come up with a general answer for this questions because it all depends on how many images you're trying to download and how important showing the thumbnails is.
I would personally generate the thumbnails on the server side as soon as they are uploaded by the user. Doing this has several advantages:
All your app has to do is request the thumbnail and render it, which is much simpler and less CPU-intensive than using Volley's ImageRequest.
Smaller images means less data usage. You definitely don't want your app to download a 10MB 25-megapixel image over a 3G connection just to shrink it to a 100x100 thumbnail that the user might not even care about.
The only drawback that I can think of is that you might have to generate multiple thumbnails, one for each screen size (e.g. one for hdpi screens and another for xxhdpi). This is slightly more expensive on the server side but might make your UI look much better.
Also, remember to cache thumbnails in your app's cache directory so you don't have to re-request them every single time you want to show them.
My Problem deals with Memory, I have a Web service that provide me a List of Urls. Each URL corresponds to a large image. My Mobile app have to parse the xml provided by the web service and than show in a GridView these images. I tried several features in order to display images such as:
Multithreading
Lazy Loading
Reduce image size using inSampleSize ( this causes my app takes too long)
should i have to attach for each large image a thumbnail image, and make the web service return to me the list of all thumbnails, after that show these thumbnail to the user, and if he clicks on one of them than i have to show the large image in a separate view, i have this idea because i noticed when i show one image i don't get an outofMemory exception!!
Is this a reliable solution? is there a better way?
Welcome to one of the hardest issues on Android. First I would start by reading this new documentation google wrote on how to handle bitmaps. Its not a light read, but you probably need to read it all the way through. It has only been up for a few weeks so you may not have seen it. It details many of the things you mentioned such as multithreading, lazy loading, and down sampling. They also recommend using an image cache.
Downloading the large images for each image and then down sampling is going to be very inefficient. First the download size is larger than needed. Second you need to load it into memory to perform the down sample and third down sampling is somewhat slow.
I would have the web api return you a list of thumbnail urls and full image urls that you can lazy download as the view comes on screen and use the cache to keep them around a while. Make sure you down sample the sizes of the thumbnails as well. I would then when the user clicks on an image go download the full image and on the background when it arrives down sample it before displaying it.
This could potentially be a duplicate but I after spending several hours reading about ImageView, ImageSwitcher, Gallery Views, Lazy Loads, and more I decided I should just ask.
I am working on an app and in one of the screens there may be an image or multiple images associate with what I am talking about. The other data for this intent will be pulled from a local database. In the database it will also have a list of URLs of images that are associate with each thing that I am discussing. So I would like to know the best way to display a thumbnail of these pictures (if there are any) on the screen. Then if these pictures are clicked on it can open up the bigger version of these pictures. I don't necessarily want to download these pictures since I don't want to save them locally for the app. Plus I don't want to make the page delay in loading while it waits to download the pictures.
What is the best way to handle this scenario?
I have to caution you, that with newer versions of Android, applications can't make connections to the internet that build the UI directly on the UI thread. Instead, it must be accomplished in a background thread such as ASyncTask. So if you're going to go with making ImageViews without src in your XML, that's fine, but you can't just have the ImageViews go download their images via URL in the onCreate of your main activity any longer. It has to be done in the background, else you'll get an error.
It makes the process fairly more complex, to be honest, but it does improve application responsiveness.
For now, since images aren't the main focus of my app, I decided to just embed a webview in my page and then display the image in some custom html ( I had a list of URLs to the images online). I also calculate the width of the screen and then I adjust how wide the images are going to be in my html.
This was the easiest since the webview takes care of the "threaded" part and I don't have to worry about how to handle/save/and display the images.
It would have been helpful to see a best practices guide when it comes to android and handeling images.
I am building an "Image Gallery" app that would fetch about 50 - 60 HD images from a site. The site will update the image list thrice a week and so new images will have to be fetched and old images discarded when the app is launched the next time.
What's the best way to cache these images and lazy load them without running
into OutOfMemory and SoftReference issues? Lazy loading would be needed because each Image thumbnail has a caption and freezing the thumbnail UI till the image loads is not a good idea.
Also, for lazy loading images - is it really a good design to spawn a thread for each thumbnail and implement a queue to handle the threads? Is there an easier way?
Please help!
Thanks for reading!
You can have a loot at PicHelper from Zwitscher source for a class that does the fetching and storing on the local file system, as well as reading Bitmaps from those files again.
Within the main code you would start an AsyncTask to fetch the images (in its doInBackground() method. To prevent OOME I'd put the list of images to fetch in a "queue" and fetch them in serial, rather than parallel. Many handsets out there only have 48MB of heap or less.
As the question is general, so is my attempt to help you. Some ideas:
- load images in one separate thread
- either store them as files with names on the SD card, or... download them each time the app is run!
- put them in a GridView. You can use a message handler (messages from the thread to the main UI thread) to update the GridView
- if you decide to store the images on the phone, identify them either by filenames, or store the names in local database.
Actually I have implemented a GridView for reading images on the SD card, and lazy loading images for a list, not exactly what you are trying to do, but it is definitely doable and you can probably find some code on the net.