Android: LibGDX 2D game memory consumption

Question

I'm facing some troubles with memory consumption while developing 2D game using libGDX.

It's a 2D game with rich graphic content - there are many textures, animations, fonts etc. For some reasons all graphic content is loaded on game start - and here is a problem with memory. I've tested memory allocation (native & heap) on different devices and got different results: (I've divided all devices for groups by textures sizes)

Group 1 (textures adopted for ~840*480 screens)

HTC Desire (Froyo): 178Mb(native) - 12Mb(heap) - application loads successfully

HTC One V (ICS): 30Mb(native) - 12Mb(heap) - application loads successfully

HTC Desire S (Jelly Bean): 30Mb(native) - 12Mb(heap) - application loads successfully

Group 2 (textures adopted for ~1366*768 screens)

Samsung(Google) Galaxy Nexus 329Mb(native) - 18Mb(heap) - works perfectly

Galaxy TAB (Honeycomb) 164Mb(native) - 10Mb(heap) - application crashes (Surface.OutOfResouresException).

I think there could be some significant memory management difference on all android versions, which brings me these troubles.

Can anyone explain what exactly happens while loading textures on android 3.x? Or maybe post some links to understand what need to be done to resolve this problem.

SOME UPDATE

Toady I'd made some additional tests on 3.x emulators (I know this is not best way, but logs was similar on emu and Galaxy Tab before)

1. I've run game with textures adopted for 1024*600 - app crashes on 80% loading resources (158 native memory allocation)
2. With textures for 800*480 - app crashes on 100% loading (145Mb native memory allocation)

And finally I have run app on new Google Nexus tablet (Jelly Bean) which uses same textures as 3.x tablets (1280*800px) - ~30Mb native memory and ~12Mb vm heap.

Now I completely lose understanding of what's going on - same memory allocation for textures 800*480 and 1280*800...

FINALLY

I have been resolve this situation using load resources on demand with some progress bar. After all attemptions I have no found another way.

Answer 1

If your wondering why Android 3 is crashing more than 2.X, it's because of a ByteBuffer bug. ByteBuffer use 4 times the memory. So you have to use lower res images for Android 3. This was solved in Android 4.

http://code.google.com/p/android/issues/detail?id=16941

Lucky for Android 3+ you have the large heap option (gives about 128+ megs) which is what I had to turn on for our app.

Answer 2

I believe the run-time memory usage of a bitmap can inflate if the format of the bitmap doesn't match the format of the display (the system will end up creating a copy with the right format to blit). I think this is more of a problem on older Android systems, and probably isn't what you're seeing on 3.0, but may be worth looking into. (See the Performance bit at the end of Romain's post here)

Memory accounting for the byte arrays underlying bitmaps changed in 3.0 (Honeycomb), the memory moved from the native side to the Java heap. However, this just shifted memory around, and should not have impacted actual limits (the native memory was still accounted against the same limit, it just wasn't visible to some tools).

The heap limit is different on different devices, too. (See Android heap size on different phones/devices and OS versions)

This Google I/O talk covers a bunch of issues around memory management changes in 3.0 that might be useful: http://dubroy.com/blog/google-io-memory-management-for-android-apps/

You can load a scaled-down version of your bitmaps on lower-memory devices. Its probably worth reading through the rest of http://developer.android.com/training/displaying-bitmaps/index.html, too.

How much on-disk image data does your application have? How big is the other non-image data your're loading (fonts, animations, etc)?