iQue wrote:
>
> Im making a game for android, Im about halfway trough (its my first real
> game that Im planning to release) and I just started using DDMS, and
> realised that my heap-size was at around 30 000, with a leak on around 3000
> every time I changed level. So I created a method that loaded my bitmaps
> with only 3 colors, and this reduced my heap-size down to 20 000, and I
> suspect that the memory leak is because the menu I have in between levels
> (with score etc) is a new activity started in realtime, Im gonna change
> this to a dialog-box so I never have to leave the main-activity in
> realtime.
>
> But obviously 20 000 heap size is still to much! I need to get down to 16
> 000, and like I said, I'm only halfway done. I Only have 5-6 different
> bitmaps onScreen at a time, sure there is around 5-6 enemies on screen that
> are using the same bitmap, aswell as several bullets using the same bitmap.
>
> So after all that, my question is, is there any common mistakes that
> beginners do that increases heap-size that I might have done? I've been
> reading about it for weeks and watched a couple of google-lectures on
> youtube. But nothing that really helps. Ive been trying to isolate the
> problem by removing 1 class at a time, then starting my game, but dosnt
> seem to go down. Going crazy! Been working for 6-7 months and now it might
> end up in the trash =/.
>
Removing a class is not a solution to heap issues. It's not even related to
heap issues.
The most common issue with heap exhaustion is packratting, the failure to
release references.
Consider an instance created an added to a 'Set':
Set<Foo> foos = new HashSet<Foo>();
foos.add(new Foo());
Now the collection 'foos' holds a reference to that new 'Foo'. Unless that
element is removed
from the collection, that instance cannot be garbage collected ("GCed").
ANother common error is to allocate an instance for too long a lifetime:
Foo foo = new Foo();
while (someCondition())
{
setAttributesFromResource(foo);
doSomethingWith(foo);
}
The instance pointed to by 'foo' will live as long as the loop takes.
while (someCondition())
{
Foo foo = new Foo();
setAttributesFromResource(foo);
doSomethingWith(foo);
}
Each 'Foo' instance will go out of scope at the end of each loop iteration,
and can be GCed then.
This is dangerous if there's a 'foos.add(foo)' inside that loop, for the
aforementioned reason - each
'foo' will be referenced by the collection and cannot be GCed until the
collection releases it.
Another problem is objects that use lots of resources, like native memory,
if they don't release those
resources in a timely fashion.
The bigger the object's heap footprint, the worse the problem.
So make sure object references go out of scope or are otherwise removed the
instant they
aren't needed.
--
Lew
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
