8

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.

Viacheslav
  • 5,443
  • 1
  • 29
  • 36

2 Answers2

3

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.

Daniel Ryan
  • 6,976
  • 5
  • 45
  • 62
  • thanks for you answer, i was wondered see so serious bug on small resource platform. Google disappointing me :( I had tryed to use largeHeap option in manifest - it increase heap up to 280Mb, but has no effect. – Viacheslav Oct 15 '12 at 16:15
  • Serious bug indeed. Lucky everyone is moving to android 4 when it comes to tablets and android 3 market share is small. But as I said before you will have to make your images lower resolution when it comes to Android 3. – Daniel Ryan Oct 15 '12 at 22:27
  • Same bug appears on Acer Iconia Tab with android 4.0.3 – Viacheslav Oct 22 '12 at 17:41
  • Couldn't be the bug I said as that was fixed in 4.0. Try not get memory crashes is a hard one I've found. In fact I'm trying to fix an app with some now. Maybe the Acer Iconia Tab largeHeap isn't so large? You might have to do some debugging. I suggest dumping the memory of the device before it crashes and using the eclipse plugin Memory Analysis. Then you know exactly what is using your memory. – Daniel Ryan Oct 22 '12 at 21:31
1

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)?

Community
  • 1
  • 1
P.T.
  • 24,557
  • 7
  • 64
  • 95
  • Thanks for your answer, I founded many interesting and helpful info by your links. It's hard to say about disk data size but I think there are ~15-20Mb for textures for 3.x tablets, 0.25Mb for fonts and 2.5Mb for sounds and music. – Viacheslav Oct 03 '12 at 09:49