Take the 2-minute tour ×

I have done following things to handle my bitmaps in application:

  1. LruCache for Bitmaps with size of 1/8 of memory
  2. Using BitmapFactory.Options to calculate inSampleSize
  3. Catching OOM when creating Bitmaps, calling evictAll and System.gc() there
  4. Also there are AsyncTask decoding sometimes for Bitmaps

I use BitmapFactory.decodeFile and it looks like VM is not freeing Bitmaps fast enough from memory. I read somewhere that there might be bug using BitmapFactory.decodeFile so I tried to use BitmapFactory.decodeFileDescriptor, but there I randomly get following:

skia --- decoder->decode returned false

So is there something wrong with FileInputStream needed to fix here if I wan't to use BitmapFactory.decodeFileDescriptor or something else to do.

This has taken me too much time and I've read all solutions based on this and how Google advices Bitmap handling and I've come to dead end.


share|improve this question
What do you want to do with Bitmaps? If you ask this question, I'm sure you load'm alot –  Maxim Shoustin Sep 17 '13 at 11:53
I suspect you are using bitmaps in listview or gridview and it is causing OutOfMemoryError. If this is the case You should consider WeakReferences for Bitmaps. Can you Elaborate your scenario further –  Pankaj Sep 17 '13 at 12:00
Both in ListView and GridView, also fullscreen scaled –  Niko Sep 17 '13 at 12:03
If I use WeakReferences of Bitmap on my LruCache, does garbage collector actually work better when entries are evicted and bitmap is not used anywhere? –  Niko Sep 17 '13 at 12:11
I'm designing something similar. How did you catch the OOM errors? I'm using the function I posted in my question here: stackoverflow.com/questions/26512276/… but doesn't work very well. –  Anonymous Oct 23 at 1:05

4 Answers 4

up vote 1 down vote accepted

I ended up using SoftRefences with Bitmap here. Now I can see GC freeing my unused Bitmaps all the time when fast scrolling GridView which draws them.

Tested setting my LruCache size full memory size and still didn't get OOM.

Penalty using this method is not that visible, my GridView scrolls pretty smoothly considering it's drawing very custom image.

share|improve this answer
One should always use SoftReferences or else gc still thinks the bitmap is still in use as its reference is being currently held by something in memory. –  PravinCG Sep 17 '13 at 13:02

System.gc() won't help you and doesn't guarantee anything.

If you absolutely sure, that evicted bitmaps are no longer needed and there is no reference to them anywhere (will catch "Can't draw recycled bitmap" exception otherwise) I would suggest you to add an EvictionListener to your LRU cache and call bitmap.recycle() on every evicted value.

Can't remember if default LRU cache provides convenience methods for setting eviction listener, but if not, it's extremely easy to extend it and add required functionality.

P.S. I would advice against WeakReferences since you lose any control of your bitmaps and purpose of LRU. Even if you load 8 bitmaps that nicely fit in your 1/8 of memory, but screen can only display 4 of them at a time (ImageViews holding a strong references to Bitmaps) gc will clear remaining 4 as soon as possible. And I really mean ultra fast. You'll have to reload bitmap for each new row (in case of ListView) you are displaying. And every bitmap that went offscreen will have to be reloaded again.

share|improve this answer
I can override entryRemoved on LruCache, but I have no idea how to detect with 100% guarantee that Bitmap is not used somewhere and I can call recycle to it. So isn't that where WeakReference would become good option, because GC might detect it to be garbage and free memory? –  Niko Sep 17 '13 at 12:24
Why do you think that gc can't keep up, do you get OOM? –  Alex Orlov Sep 17 '13 at 12:30
1/8 is a tiny amount of memory. You need to load a lot of bitmaps in a short period of time to overflow it so much, that you get an OOM –  Alex Orlov Sep 17 '13 at 12:33
Yes I do get OOM, maybe SoftReferences for my LruCache Bitmaps could do magic for GC to understand freeing memory little bit harder? –  Niko Sep 17 '13 at 12:35
Well, that means List with WeakReferences is your best option, using LRU in such a case is meaningless, since your bitmaps are controlled by references and not by LRU algorithms. –  Alex Orlov Sep 17 '13 at 12:57

Please have a look into this link


i think this may helps u.

share|improve this answer
Our company policy doesn't allow any third party libraries. –  Niko Sep 17 '13 at 12:10
Not even open source libraries? It's very hard to build good apps without any third party code. –  DrJerkberg Oct 5 at 11:52

Using large Bitmap always there is a chance to get Out Of Memory Exception.. So to handle go through Android blog


And always recycle the Bimap

ImageView mImage;
Drawable toRecycle = mImage.getDrawable();
        if ( toRecycle != null && toRecycle instanceof BitmapDrawable ) {
            if ( ( (BitmapDrawable) mImage.getDrawable() ).getBitmap() != null )
                ( (BitmapDrawable) mImage.getDrawable() ).getBitmap().recycle();
share|improve this answer
This looks pretty nasty way, shouldn't platform automatically recycle that bitmap when it's not used anywhere? –  Niko Sep 17 '13 at 12:04
Also all my Bitmap's are in LruCache so I'm looking for answer more universal where bitmap recycling happens in one place, not single solution based on one ImageView's bitmap. –  Niko Sep 17 '13 at 12:27

Your Answer


