Android:使用 Eclipse 内存分析器检测泄漏 [英] Android: Detecting leaks with Eclipse Memory Analyzer

查看:18
本文介绍了Android:使用 Eclipse 内存分析器检测泄漏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有这个问题 Android:屏幕方向错误 + VM 不会让我们分配 x 字节所以我决定下载 Eclipse Memory Analyzer.我在出现错误时运行它,并且我怀疑有 3 个问题,但我不明白它可能来自哪里.+ 我真的不知道我的问题是否是由于内存泄漏造成的,因为可能的泄漏只占用 2.2;B 空间

I have this problem Android: Screen orientation error + VM won't let us allocate x bytes so I decided to download Eclipse Memory Analyzer. I run it when my error is appearing and I have 3 problems suspects but I don't understand where it might come from. + I don't really know if my problem is due to a memory leak as the possible leaks take only 2.2;B space

问题嫌疑人 1

2,094 instances of "java.lang.Class", loaded by "<system class loader>" occupy 789,200 (33.76%) bytes. 

Biggest instances:
•class android.text.Html$HtmlParser @ 0x4018d3f0 - 126,632 (5.42%) bytes. 
•class org.apache.harmony.security.fortress.Services @ 0x400e2e58 - 53,880 (2.30%) bytes. 
•class com.android.internal.R$styleable @ 0x400882c0 - 38,072 (1.63%) bytes. 
•class libcore.icu.TimeZones$CachedTimeZones @ 0x40444fa8 - 37,712 (1.61%) bytes. 
•class android.R$styleable @ 0x40055940 - 37,640 (1.61%) bytes. 
•class android.content.res.Resources @ 0x40075178 - 36,032 (1.54%) bytes. 
•class android.text.AutoText @ 0x40178980 - 31,656 (1.35%) bytes. 


Keywords
java.lang.Class

问题嫌疑人 2

128 instances of "org.bouncycastle.jce.provider.X509CertificateObject", loaded by "<system class loader>" occupy 455,112 (19.47%) bytes. These instances are referenced from one instance of "java.util.Hashtable$HashtableEntry[]", loaded by "<system class loader>"

Keywords
org.bouncycastle.jce.provider.X509CertificateObject
java.util.Hashtable$HashtableEntry[]

问题嫌疑人 3

6,822 instances of "java.lang.String", loaded by "<system class loader>" occupy 418,104 (17.89%) bytes. 

Keywords
java.lang.String

你认为我有泄漏吗?我们可以从我发布的内容中说出来吗?谢谢

Do you think I have a leak? Can we say it from what I have posted? Thank you

推荐答案

在 Android 上,我认为泄漏 Activity 上下文非常容易.因此,我用来查找内存泄漏的最常用方法是打开一个 OQL 选项卡,然后输入 'select * from instanceof android.app.Activity' .然后你可以看到那里有多少Activity实例,你可以通过自己的判断来判断是否存在泄漏.您也可以右键单击 Activity 实例之一,然后单击GC 路径"-->排除所有软/弱/幻像引用".然后您可以在链中看到对 Activity 的引用.祝你好运!

On Android, I think it quite easy to leak an Activity context. So the most frequently way I used to find a memory leak, is to open an OQL tab, and input 'select * from instanceof android.app.Activity' . Then you could see how many Activity instances there, and you could tell whether there is a leak or not by your own judgement. Also you could right-click on one of the Activity instances, and click 'Path to GC'--> 'exclude all soft/weak/phantom references'. Then you could see the references to the Activity in chain. Good luck !

这篇关于Android:使用 Eclipse 内存分析器检测泄漏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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