View Single Post

Default 

August 25th, 2013, 18:14
Ok, this is bad. After a few days of researching memory issues in Android it appears that Android two sets of memory, the active and the external heap.

I managed to get the thing to start playing a lot smoother by manually calling the garbage collector ( System.gc() ) but I was still having the same issues when I drew the weaponImage saying I've hit the offending limit of 40mb or somesuch. I removed the above Invisibility status image and thought this took care of it. But after stressing the maching with spells I suddenly run into a 24mb limit.

24mb is the limit on the heap size of the external heap I've gleaned. Older versions of Android limit this to 16mb. Android 2.2 and before and Honeycomb (3.0) and above have ways to increase the heap size, but Gingerbread (2.3), which 33% of all Android users still use, does not. In addition Honeycomb automatically gc's the heap (I think).

Worse, the heap does shrink once its grown. However, I've seen it shrink, particularly when I've finished an Activity.

The main cultprit of an evergrowing heap size are bitmaps. Or, it should be noted, are the chief thing you can clear up by use of .recycle(). Like Windows recycle it just means trash.

So I tried many techniques to recycle the background drawables by first converting them to bitmap but I still got either Out of Memory errors or attempting to use recycled bitmaps.

This was caused from either a) a destroyed image or b) attempting to recycle an image in use. It seems once an image is destroyed it can't be brought back - but I use them dynamically.

Caching the images will increase performance but will still increase the size of the heap. I need to look at LRUCaching to see if this is still true. LRUcaching replaces weakreferences which made them a bigger target for gc in theory but apparently did next nothing in Android.

It has been recommended to use OpenGL textures or the NDK to control memory. The NDK allows for external languages like the libc to connect to Android. They never use external memory and the libc can use malloc and free so you can control the memory yourself. The big problem is is I would need to completely rewrite the code.

Unbinding the drawables once you've destroyed the Activity is a great tip I found. This doesn't work until the Activity is finished so it doesn't help my immediate problem. However, it appears rotating the screen is bad for leaving the drawables still bound to the old destroyed activity (memory leak garbage) so implementing this is still important.

One solution I'm going to try is the BitmapFactory which can take an image and create a bitmap out of it the precise dimensions of the ImageView. This keeps the ImageView from having to adjust the background image itself. On top of that I can try and recycle the bitmap once I'm through with it. This is a complicated process but I'll see how it goes.



I managed to squeeze Munch's The Scream as one of the antagonists. I can use it because even though Munch died in 1944, this is from a lithograph he made and a reproduction's copyright begins on the date it was created. And in the US any print created before 1923 is considered public domain.

Spoiler


Its pretty much how I feel at this point.

Developer of The Wizard's Grave Android game. Discussion Thread:
http://www.rpgwatch.com/forums/showthread.php?t=22520
Last edited by Lucky Day; August 25th, 2013 at 18:34.
Lucky Day is offline

Lucky Day

Lucky Day's Avatar
Daywatch

#79

Join Date: Oct 2006
Location: The Uncanny Valley
Posts: 3,172