Android Garbage Collection

Coming from a C++ background, I never really had much experience with garbage collection before working with Android. Sure, I’ve used Java and Flash/Flex quite a bit but I never had to worry about it since I wasn’t working on performance critical code. Created objects would automatically get cleaned up and I didn’t care how. I got into android app development because of ShowBox application.

In C++, every object that you create needs to be explicitly released. With Java, you don’t explicitly release objects. You just remove all references to an object you don’t need anymore and the garbage collector will eventually come along and release it for you.

This works fine when you don’t care about performance. However, when you’re creating a game on a mobile device, you need all the processing power it has and you’re definitely going to notice when the garbage collector is running. Throw in the fact that you have no idea when it’ll run and you have a problem. Depending upon how much memory is being released, you might see your program/game skip every few seconds or a few times per second.

How do you know the garbage collector is to blame for this problem? Simple. Watch the log output in the DDMS while your program is running. It will continually show lines like

GC freed 1307 objects / 88360 bytes in 159ms

every time it skips. Fixing this problem isn’t the hardest thing in the world. It’s more tedious than anything else.

The first thing you need to know, is what will cause the garbage collector to run. Since it works by releasing any unreferenced objects, the more objects you stop using, the more often it’s going to run. “Object” here mainly refers to a variable that at some point was assigned a value using the “new” command. This applies to basic arrays (new int[5]), class objects and also iterators for ArrayList and Map collections. It’s important to note that primitive types (int, float, double, etc.) DO NOT cause garbage collection. I’ve seen some places claim that they do and that completely screwed up some of my code in the very beginning. However, if you use a wrapper for a primitive type (Integer, Float, etc.), then unreferencing that WILL cause garbage collection.

Like I said before, fixing this is pretty easy but can be time-consuming. Take the following code for example:

for(int i = 0; i < 10; i++) {
Object obj = new Object();
}

Every loop creates a new object while unreferencing the old one. Those unreferenced objects will eventually need to be cleaned up by the garbage collector. A better way to handle this would be:

Object obj = new Object();
for(int i = 0; i < 10; i++) {
obj.init();
}

Rather than creating a new object every loop, just reinitialize the existing one.

Here’s another example that will eventually cause the garbage collector to run:

public void createObject() {
Object obj = new Object();
}

Everytime this method runs, a new Object will be created. If you’re not holding onto that object somewhere, it’s going to get unreferenced and collected. A better way would be to do this:

private Object mObj = new Object();
public void createObject() {
mObj.init();
}

This way, the object is only created once and then reinitialized every time the method runs.

This can be applied to groups of objects as well. This algorithm is applied in the latest version MovieBox app. If you have multiple objects of the same type that can be created or destroyed at any point, then create an object pool. An object pool is just an array that holds objects that aren’t currently being used. When you need an object, check to see if the pool is has one. If so, reinitialize the object. If not, create a new object. Then when you’re done with an object, clean it up and stick it into the pool to be used later.

The last thing you need to know is how to find the problems. You could search through all of your code but if you’re not aware of this problem at the very beginning, that could take a very long time. The other option you have is using the Allocation Tracker in the standalone DDMS. You can find the DDMS in the Android tools folder that is installed with the SDK. Here’s the info on working the Allocation Tracker. This will show you exactly where objects are being allocated. If you see any excessive memory allocations (objects being created in a loop) that are unnecessary then you can use the previous tips on cleaning them up.

Hopefully this helps somebody out there. It’s a bit of a pain in the ass to explain properly so if you have any questions, just let me know.

Leave a Reply

Your email address will not be published. Required fields are marked *