【问题标题】:Excessive garbage collection (GC_FOR_MALLOC) in Android emulator when using simpleframework使用 simpleframework 时 Android 模拟器中的过多垃圾收集 (GC_FOR_MALLOC)
【发布时间】:2012-07-27 20:12:11
【问题描述】:

我有一个使用 SimpleFramework 进行 XML 序列化的 Android 应用程序。该应用程序在我测试过的所有真实设备上运行良好,没有延迟,但在模拟器上运行时,垃圾收集器在每次启动应用程序时都会运行大约 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 时遇到过这种情况,如果是这样,有什么方法可以防止每次启动应用程序时(从 eclipse)启动 GC 吗?增加堆(当前设置为vm.heapSize=24)会有帮助吗?还是有其他解决方案?

【问题讨论】:

    标签: java android android-emulator garbage-collection simple-framework


    【解决方案1】:

    您需要升级到 2.6.7,现在注释处理已经完成,有相当大的变化。事实证明,Android 有一个众所周知的注释问题,奇怪的是,它与糟糕的 java.lang.reflect.Method.equals(Object) 实现相关。简单的 2.6.7 缓存了更多的注释处理,应该会更好。

    【讨论】:

    • 升级到新版本 (2.6.9) 似乎确实解决了这个问题。
    【解决方案2】:

    这是在黑暗中拍摄的,但是您是否尝试过更改初始 jvm 堆大小?它是 -xms 参数。它可能在您的模拟器上太低,因此在最初的几分钟内,它会不断尝试调整自身大小并卡住垃圾收集。看看这个链接:http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp

    【讨论】:

    • 好点,这和eclipse堆大小一样吗?我的 Eclipse 堆足够大:-XX:MaxPermSize=1G -Xms1G -Xmx2G。有没有我可以专门为模拟器配置的地方,也许是在 AVD 管理器或其他地方?谢谢。
    猜你喜欢
    • 2016-10-20
    • 2011-06-19
    • 2011-09-01
    • 2021-12-26
    • 1970-01-01
    • 2013-10-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多