One of the most common errors that I found developing Android Apps is the “java.lang.OutOfMemoryError: Bitmap Size Exceeds VM Budget” error. I found this error frecuently on activities using lots of bitmaps after changing orientation: the Activity is destroyed, created again and the layouts are “inflated” from the XML consuming the VM memory avaiable for bitmaps.

Bitmaps on the previous activity layout are not properly deallocated by the garbage collector because they have crossed references to their activity. After many experiments I found a quite good solution for this problem.

First, set the “id” attribute on the parent view of your XML layout:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="fill_parent"
 android:layout_height="fill_parent"
 android:id="@+id/RootView"
>
...

Then, on the onDestroy()  method of your Activity, call the unbindDrawables() method passing a refence to the parent View and then do a System.gc()

@Override
protected void onDestroy() {
	super.onDestroy();

	unbindDrawables(findViewById(R.id.RootView));
	System.gc();
}

private void unbindDrawables(View view) {
	if (view.getBackground() != null) {
		view.getBackground().setCallback(null);
	}
	if (view instanceof ViewGroup) {
		for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
			unbindDrawables(((ViewGroup) view).getChildAt(i));
		}
		((ViewGroup) view).removeAllViews();
	}
}

This unbindDrawables() method explores the view tree recursively and:

  • Removes callbacks on all the background drawables
  • Removes childs on every viewgroup

This solved the problem on many of our Mobialia apps.

UPDATE 2011-03-30:

Today @luiskap from SpartanBits told me another good solution: if you don’t need different layouts for portrait and landscape modes, you can make your activity react to orientation changes (avoiding activity destroy) adding to your activity’s manifest: android:configChanges="keyboardHidden|orientation" and overriding the onConfigurationChanged method, calling setContentView reusing the already created views. There is a good explanation on StackOverflow.

8 thoughts on “Dealing with the “Bitmap Size Exceeds VM Budget” error

  1. Thanks a lot for this post.
    Since I started developing for Android I’m fighting against the OutOfMemoryErrors related to bitmaps and layouts and I’m not the only one: http://code.google.com/p/android/issues/detail?id=8488.

    There’s one improvement I would recommend:
    try {
    viewGroup.removeAllViews();
    }
    catch (UnsupportedOperationException mayHappen) {
    // AdapterViews, ListViews and potentially other ViewGroups don’t support the removeAllViews operation
    }

    Reply
  2. Looking at doing this for my drawables, I assume you got this idea from the Home App Source.

    My question is why do you explicitly call the GC? It’s going to be called anyway isn’t this inefficient?

    Reply
  3. why am I getting these errors:


    - ViewGroup cannot be resolved to a type
    - Incompatible conditional operand types View and ViewGroup

    basically on each of this lines:

    “if (view instanceof ViewGroup) {
    for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
    unbindDrawables(((ViewGroup) view).getChildAt(i));
    }
    ((ViewGroup) view).removeAllViews();
    }
    "

    Thanks!

    Reply
  4. Thanks a lot for this post.My activity contains no.of views(means layouts),here i am using swipe for move one view to another view.some times its show error(Bitmap).
    just i used above code. its showing exception,

    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): java.lang.NullPointerException
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.qteq.softmenuapplication.ItemsScreen.unbindDrawables(ItemsScreen.java:2598)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.qteq.softmenuapplication.ItemsScreen.access$0(ItemsScreen.java:2595)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.qteq.softmenuapplication.ItemsScreen$20.onTouch(ItemsScreen.java:1725)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.view.View.dispatchTouchEvent(View.java:3705)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:852)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.android.internal.policy.impl.PhoneWindow$DecorView.superDispatchTouchEvent(PhoneWindow.java:1659)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.android.internal.policy.impl.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1107)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.app.Activity.dispatchTouchEvent(Activity.java:2061)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.qteq.softmenuapplication.ItemsScreen.dispatchTouchEvent(ItemsScreen.java:2923)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchTouchEvent(PhoneWindow.java:1643)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.view.ViewRoot.handleMessage(ViewRoot.java:1691)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.os.Handler.dispatchMessage(Handler.java:99)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.os.Looper.loop(Looper.java:123)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at android.app.ActivityThread.main(ActivityThread.java:4363)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at java.lang.reflect.Method.invokeNative(Native Method)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at java.lang.reflect.Method.invoke(Method.java:521)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
    09-29 16:09:25.203: ERROR/AndroidRuntime(1284): at dalvik.system.NativeStart.main(Native Method)

    Reply
  5. I noticed calling unbindDrawables in onPause reduces the “OutOfMemoryError” crashes in my app , however in some cases, when I go back to the activity (eg : if my activity is in an activity group and I go back), I get a blank screen.

    Any suggestion ?

    Reply
  6. From Eclipse DDMS,
    If only use view.getBackground().setCallback(null); after the onDesctroy, both the “Heap size” and the “Allocated” almost the same.

    If add view.setBackgroundResource(0); after view.getBackground().setCallback(null); then the “Heap size” is the same but the “Allocated” decrease largely.

    Is it necessary to add the view.setBackgroundResource(0); ?

    Thanks…

    best
    Andrew

    Reply

Leave a reply

required

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>