使用simpleframework时，Android模拟器中的垃圾收集过多(GC_FOR_MALLOC)

Question

我有一个Android应用程序，它使用SimpleFramework进行XML序列化。该应用程序在我测试过的所有真实设备上运行良好，没有滞后，但当在模拟器上运行时，垃圾收集器在每次启动该应用程序时会启动大约3分钟。

以下是我迄今为止观察到的情况：

• 垃圾回收在将对象序列化为XML之前开始
• 它只发生在第一个对象序列化并通过网络发送之前，而不会发生在连续调用中
• 序列化代码在一个单独的库中，该库被打包并作为.jar文件添加到项目中

以下是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...

以下是我目前用于序列化的代码：

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 "";
}

显然，这占用了很多时间，每次我更改代码并重新部署应用程序时。其他人在使用libaray时有没有经历过这种情况？如果有，有没有什么方法可以防止GC在每次启动应用程序（从eclipse）时介入？增加堆（当前设置为vm.heapSize=24）有帮助吗？还是有不同的解决方案？

Answer 1

您需要升级到2.6.7，现在注释处理已经完成，有相当大的更改。事实证明，Android在注释方面有一个众所周知的问题，它与一个糟糕的java.lang.reflect.Method.equals（Object）实现有着奇怪的联系。Simple2.6.7缓存了更多的注释处理，应该会更好。

Answer 2

这只是一个未知数，但您是否尝试过更改初始jvm堆大小？它是-xms参数表。它可能在你的模拟器上太低了，所以在最初的几分钟里，它一直在尝试调整自己的大小，并陷入垃圾收集。查看此链接：http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp