Question

I’ve spent the last few days trying to remove memory leaks in my game, resulting in many out of memory errors. I’m on the verge of adding a significant amount of graphics, that while not hugely complicated, will add significantly to the processing requirements of my system, and I’m a bit worried about my memory usage, and I was hoping someone might have some tips for me. I don’t want to go below Android 2.1, so please tailor any answers to that end.

First of all, my game consists of:

1. 2 activities, 13 XML files (Some relating to a small part of a layout, some dialogs, and 2 directly related to activities.
2. A number of drawables, made in Adobe Illustrator and converted to PNG. These are probably large, but not unusually large, and for the most part, only small amounts of them are in memory at any given time.
3. Quite a few dialogs.
4. Targeted towards Android 1.6 and above.
5. I used the newest Admob, and as a result, I have to build against 3.2.
6. My default heap size for my emulators is around 24 MB.

A few sample images from my game:

What I have learned:

1. Despite my total app size being only around 500K, I somehow am taking up 24 Megs, as calculated by adb shell procrank.
2. I have done considerable optimization, but am not seeing large increases in memory.
3. Using tools to find what is in the Heap typically only show around 7 MB avaliable, with around 3 MB being used. Sometimes, when opening new dialogs and the like, I see an increase, but I can’t say that I see it being all that large…
4. MAT shows that none of my classes are using an unusually large amount of memory.

So, given all of this, my questions.

1. Is 24 Mb an actual requirement to develop to (1.6+ android)?
2. Assuming it is, how can I both allow for nicer graphics for systems which can handle it, but not crash and burn for older systems?
3. What are some common gotchas that I can use to improve my memory usage?

Answer 1

Without seeing your actual code, I can’t say if the following will be relevant to you or not. However, it is worth a shot.

If you are not already doing so, you can consider using something called an LruCache. http://developer.android.com/reference/android/util/LruCache.html

Using this tool, you can determine at what point your cached objects (such as Bitmaps) will become eligible for garbage collection. So, if you want to set it at 4mb (for example) the OS will deal with it should it try to grow beyond it. (See docs for implementation details and a good example).

The only downside is that that little gem only came along with 3.2, so you would have to make that your min SDK in the AndroidManifest, or do a check programatically at run time for the api level to determine if you can use it. Pre 3.2 I would say you need to call recycle() on any Bitmaps you are using, but if you have optimized already I would think the chances are good you are already doing this.

This is a nice little snippet about the difference between the heap and native memory. http://code-gotcha.blogspot.com/2011/09/android-bitmap-heap.html It may (depending on what you are doing) help you to understand why you are not seeing the drop in memory you are expecting.

And finally this post from SO should help when dealing with heap size as well:
Detect application heap size in Android

Hope that helps.