Excessive garbage collection (GC_FOR_MALLOC) in An

I have an Android app that uses the SimpleFramework for XML serialization. The app runs fine on all real devices I have tested it on with no lags, but when run on the emulator, the garbage collector kicks in a runs for about about 3 minutes on each launch of the app.

Here is what I have observed so far:

Garbage collection kicks in just before serializing objects to XML
It only happens before the first object is serialized and sent over the network, and does not happen for successive calls.
Serialization code is in a separate library that is packaged and added as a .jar file in the project.

Here is the output from LogCat:

07-27 08:17:10.275: D/dalvikvm(682): GC_FOR_MALLOC freed 10179 objects / 482344 bytes in 32ms
07-27 08:17:10.435: D/dalvikvm(682): GC_FOR_MALLOC freed 13927 objects / 535968 bytes in 33ms
....... About 300 more similar entries...

Here is the code I'm presently using for serialization:

public String fromElement(Object request) {
    Writer writer = new StringWriter();
    try {
        serializer.write(request, writer);
        String res = writer.toString();
        Log.d(LOG_TAG, res);
        return writer.toString();
    } catch (Exception e) {
        e.printStackTrace();
    }
    return "";
}

Obviously, this is taking up a lot of time, each time I make a change in my code and redeploy the app. Has anyone else experienced this when using the libaray, and if so, is there some way I can prevent the GC from kicking in each time I launch the app (from eclipse)? Would increasing the heap (currently set at vm.heapSize=24) help? Or is there a different solution?

回答1:

You need to upgrade to 2.6.7, there are pretty major changes to now annotation processing is done. It turns out Android has a fairly well know problem with annotations, relating strangely enough to a bad java.lang.reflect.Method.equals(Object) implementation. Simple 2.6.7 caches much more of the annotation processing and should be much better.

回答2:

This is a shot in the dark, but have you tried changing your initial jvm heap size? It is the -xms parameeter. It might be too low on your emulator so that during the first couple of minutes it is constantly trying to resize itself and stuck garbage collecting. Check out this link: http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp