为什么这么多GC_FOR_ALLOC在一个简单的应用程序? [英] Why so many GC_FOR_ALLOC in a simple app?

查看:593
本文介绍了为什么这么多GC_FOR_ALLOC在一个简单的应用程序?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我收到来自dalvikvm太多的GC_FOR_ALLOC。 我得到的XML从REST服务:在一个活动我分析100线编程(我)和其他活动我使用SimpleXML来解析200线

在我第一个获得50 GC_FOR_ALLOC。 在第二个我得到这样的300! (我甚至无法张贴这一切,会使体内29579个字符,这是允许的唯一30K)

我已经搜查,几乎每个人都抱怨gc_for_M黄金,而不是gc_for_Alloc。

时的SimpleXML的问题,因为情况下产生的?

我会后由dalvikvm的logcat的转储,也许值有一些信息。

非常感谢你的帮助。

 六月12日至11日:13:49.564:D / dalvikvm(6759):GC_FOR_ALLOC释放362K,13%免费4116K / 4688K,暂停181ms,总182ms
6月十二号至11日:13:50.074:D / dalvikvm(6759):GC_FOR_ALLOC释放303K,13%免费4134K / 4708K,暂停142ms,总142ms
....反复多次.....
6月十二号至11日:14:06.254:D / dalvikvm(6759):GC_FOR_ALLOC释放73K,13%免费4159K / 4768K,暂停53ms,共53ms
6月十二号至11日:14:06.314:D / dalvikvm(6759):GC_FOR_ALLOC释放103K,13%免费4159K / 4768K,暂停56MS,总57ms
6月十二号至11日:14:06.374:D / dalvikvm(6759):GC_FOR_ALLOC释放29K,12%的自由4203K / 4768K,暂停54ms,共54ms
6月十二号至11日:14:06.424:D / dalvikvm(6759):GC_FOR_ALLOC释放73K,13%FRE
 

解决方案

您可以看到使用DDMS分配追踪器(的内存调试文档,老博客文章 DDMS文档)。这会告诉你什么是被分配给你一个堆栈跟踪,其中正在执行分配的地方。

另一篇博客中介绍MAT及其他相关工具,虽然堆转储分析是这样的问题不太有用,因为它通常表明你的的对象没有的被释放,而你更感兴趣的是的的对象被释放。

I'm getting way too many GC_FOR_ALLOC from the dalvikvm. I'm getting XML from a REST service: in one activity I parse about 100 lines programatically(me) and in the other activity I use the SimpleXML to parse about 200 lines.

In the first one I get 50 GC_FOR_ALLOC. In the second one I get like 300!! (I can't even post it all, the body makes 29579 characters and it's allowed only 30k)

I've searched and almost everyone complains about gc_for_"M"alloc and not gc_for_"A"lloc.

Is the SimpleXML the problem because the instances created?

I'll post the logcat dump by dalvikvm, maybe the values have some information.

Thank you very much for your help.

12-11 06:13:49.564: D/dalvikvm(6759): GC_FOR_ALLOC freed 362K, 13% free 4116K/4688K, paused 181ms, total 182ms
12-11 06:13:50.074: D/dalvikvm(6759): GC_FOR_ALLOC freed 303K, 13% free 4134K/4708K, paused 142ms, total 142ms
.... repeated many times .....
12-11 06:14:06.254: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% free 4159K/4768K, paused 53ms, total 53ms
12-11 06:14:06.314: D/dalvikvm(6759): GC_FOR_ALLOC freed 103K, 13% free 4159K/4768K, paused 56ms, total 57ms
12-11 06:14:06.374: D/dalvikvm(6759): GC_FOR_ALLOC freed 29K, 12% free 4203K/4768K, paused 54ms, total 54ms
12-11 06:14:06.424: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% fre

解决方案

You can see the most-recently-allocated objects using the DDMS Allocation Tracker (memory debugging docs, old blog post, ddms docs). This will show you what's being allocated and give you a stack trace for the place where the allocation is being performed.

Another blog post describes MAT and other relevant tools, though heap-dump analysis is less useful for this sort of problem because it generally shows you the objects that haven't been freed, and you're more interested in the objects that are being freed.

这篇关于为什么这么多GC_FOR_ALLOC在一个简单的应用程序?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆