Question

I’m currently using a filesystem cache to cache my images as I download them from the server. I have a ListView that contains custom views, each of which retrieves its image from the filesystem when getView() is called.

To improve performance, I implemented a java.util.WeakHashMap<String,Bitmap> that stores each of the bitmaps by a unique key. This allows me to tuck the images into the hashmap as they’re downloaded, and then retrieve them directly from memory to populate my listview. This avoids a file I/O operation and results in a much smoother scrolling experience.

The idea is that as the OS runs low on memory, it will clean out the WeakHashMap to free up memory.

However, this doesn’t work on Android 2.3 or earlier. The problem is that bitmaps are not kept in the Java Heap, and are instead kept in native memory. This means that the JVM garbage collector has no idea how much memory those images are occupying, and thus never bothers to free them up when the OS is low on native memory, resulting in OutOfMemory errors when there’s plenty of memory that can still be reclaimed.

This has been fixed in Android 3.0, since 3.0 stores bitmaps in JVM heap instead of native memory, but the question is how can I easily cache bitmaps on Android 2.3 and later without inadvertently causing unnecessary OutOfMemory exceptions?

Answer 1

So the answer seems to be that there’s a bug in the way the dalvik VM detects when it needs to do a GC pass. If you manually call System.gc() immediately before allocating memory for your bitmap, the OutOfMemory errors surprisingly go away.

    if(Build.VERSION.SDK_INT < 12) {
        Log.d("Running garbage collection for Bitmaps");
        System.gc();
    }
    return BitmapFactory.decodeStream(is);

Obviously, the VM should be doing this GC automatically before it throws an OutOfMemory, but it does not appear to do so.