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.
Related
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
I want to make an Android application that has the same look as Instagram, which means every profile has a gallery of photos.
My question is about storing and retrieve those photos. I want to know what is the best practice for photo storage in a database (MySQL), more precisely:
Should I store photos with original size (2mb for example) or resize them with smaller size?
Should I store them with two version (smaller size photo, and normal size photo)?
Saving images in the database looks like overkill, it's not needed. Saving on disk should be fine.
Although you should focus on your business logic & leave this to image libraries which does this stuff & do best for memory & performance.
Some famous libs are:
Picasso
Glide
Universal image loader
Fresco
& you will find many more
Almost each library does lots of stuff for you, such as:
In memory cache(LRU Cache) - so that UI thread is not blocked from doing I/O
operation from disks
Disk Cache - To keep images saved for further
app sessions, also when memory cache reaches its limit its have to be
evicted from it., you can specify disk cache size.
Various image scaling strategies
Image transformations
Clearing up bitmaps for freeing up memory
Network operations on background threads
Background threads management & so on..
My suggestion is to go with one of the image library
I dont think the best practice is to store the photos in a database.
In the DB you store the link/location of the photos example a url to a photo.
About smaller size photo it depends on what you are trying to accomplish because now you need more space to pay for and maybe less bandwidth because you can put thumbnails and let it only load the original size when a user clicks on it. So it all depends what and how you want to archieve
Best practice for storing images is to simply cache them as files and not save them in a database. You could save them as blobs in an sql db but they should be less than 32px by 32px to make things smooth. Everything else should be saved as files. Let me give you an example of WhatsApp.
WhatApp caches most of it's images as files and only saves the pixelated thumbnail in a database.
Currently, I am using a WeakHashMap to store my BitMap and link it to my key, but I have noticed it begins to use a ton of RAM. Is there a better solution to caching the BitMaps till I need them? It is unlikely I will need the image after the application closes, so a long-term solution isn't really needed.
Thanks!
I need to keep them in memory in case the user swipes back to a
previous view to save bandwidth and make the ViewPager more responsive
FragmentStateAdapter is meant for precisely that. Also use setOffscreenPageLimit() and setRetainInstance() in conjunction with that.
Storing Bitmap objects in runtime memory is not a good idea and will sooner or later lead to OutOfMemoryErrors getting thrown.
It is unlikely I will need the image after the application closes, so a long-term solution isn't really needed.
Storing images in cache wont be a problem as system doesn't clear image from cache even after you close the application or unless you clear the app data from setting.
For image downloading you can use image libraries like:
Image loaders:
https://github.com/nostra13/Android-Universal-Image-Loader
It gives you option to save image in cache.
You can also use volley library. But in this you have to implement your own code for cache storing.
http://developer.android.com/training/volley/index.html
Otherwise you can also implement your own code for cache in which you can use memory disk for caching.
http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html#disk-cache
Use an LruCache. There are plenty of online guides on the developer site.
Is there a general guideline or rule of thumb on when I should cache a photo?
For example I have a grid view of smaller icon images. This page isn't at the beginning of the app so there's no guarantee a user sees it, these images could change server-side but for the most part they won't. Should I cache them because there are so many or not worry about them because they are small?
Another example would be if I click on one of the images mentioned above it will lead me to a view with one larger image, should I cache this image since it's larger or should I let the user make a network request each time?
I'm not looking for an answer for these specific questions, but rather a guideline to follow.
To clarify by caching I mean saving the file to storage. Also, is there a better method than this?
Thanks for the help!
Caching is an important feature in user experience, so even if there's no guarantee the user sees that particular 'page', it a nice thing to have.
Saving images in a cache depends directly on many variables:
- How much time does it take to regenerate images if not cached
- How many images are we talking about
- How often do they change
- What size is each image
For example, having 100 thumbnails of images that change every month makes a lot of sense. Caching 200 images with 1024x768 resolution that change very often doesn't.... or does it? The answer is very variable.
Also cache should always have storage boundaries. Even in the previous example with the large images, you could limit the cache to a a certain storage capacity.
Normally the cache saves a local copy of the most recently used items. But you can implement a more sophisticated algorithm, for example, saving the most visited images instead of caching the most recently used.
I have to believe there's a way to clear image data from memory once it's no longer required, but despite exhaustive searching I can't find a solution. Both stack and the google android dev list are full of questions regarding OOM errors, specifically "bitmap size exceeds VM budget", but I still don't see a clear answer.
I understand there are hard memory limits on devices, and I understand it's not realistic to load up and display or cache large amounts of image data, but there should be away to discard data that's no longer required.
For example, imagine this very basic hypothetical app, that emulates a lot of the behavior of the native gallery app:
An image gallery that allows the user to peruse images from a remote server.
There might be any number of images on that server.
The app displays 1 image at a time, and allows a user to go back or forward 1 image at a time through button presses or swiping.
There'd be a maximum of 3 images rendered at any one time (so the user can see the one immediately to the left or right of the current image when swiping). All other image data should be discarded.
Images are loaded using URL.openStream and Drawable.createFromStream or BitmapFactory.decodeStream. Streams are closed appropriately.
Images are sized appropriately on the server before being fetched.
Loading happens in AsyncTasks. Tasks that are no longer needed (due to moving away from an image with an incomplete task) are cancelled. Any references in the AyncTask are WeaklyReferenced.
When any image is no longer required, it's "cleared" via:
getBackground().setCallback(null)
Listeners are set to null
setImageDrawable/Bitmap(null)
removeView
This simple construct, that takes into account all the suggest practices I'm aware of, will inevitably crash with an OOM error at some point. Using BitmapFactory.Options inSampleSize and inPreferredConfig will delay the inevitable, but not forever, and at the cost of image quality. In this example, I've used remote images, but the issue exists with images stored in /assets/ or in internal memory, etc.
My feeling is that if we can display X amount of image data at one point, and we take all steps to remove that image data from memory, we should be able to display that same amount of data later, without having to compensate for what has happened before.
With the sheer quantity of questions about this very issue, I'd hope to have a standard solution documented, but if there is one, I can't find it. I've seen answers posted by Romain Guy, who otherwise seems very generous with his knowledge and active in the community, that say something like "Simple. Don't use so much memory". OK. Tell me how.
I should also mention that System.gc does nothing to help this. I'm also aware of bitmap.recycle, but unless I'm mistaken this can't be used in this fashion.
Am I missing something fundamental? Is there a way to discard image data once it's no longer being used? What is missing from the above to create a simple photo gallery? Assuming the built-in gallery app uses the framework and not the NDK, I imagine there has to be a way...
TYIA.
/this question has also been posted on the android developer google group list.
Through my work with Prime I found a few tips, one of which you have not mentioned. When you decode your Bitmaps make sure to use the inPurgeable and inInputShareable flags in your BitmapFactory.Options. That will help a little bit but I would recommend you look at my implementation of image loading in Prime. I use it in all of my products without any memory issues. I have found that 95% of memory problems are from the incorrect usage of the Bitmap class.
There is a very detailed article about the use of bitmaps on the android developer website.
Did you look at it ?
It explains how to load, cache and display bitmaps efficently and how to get rid of this famous OutofMemoryError.
There is also a sample application from an image gallery.
I think that's what you're looking for.