内存泄漏通过IClipboardDataPasteEventImpl

我注意到我的活动中有一个奇怪的记忆增加。 因此,我跑了一个小testing:我多次打开对话框(打开 – closures – 打开 – closures….)和内存不断增加。 所以我用DDMS转储一个HPROF文件,并在MAT (内存分析器)中打开它。 泄漏的怀疑报告指出,内存消耗增长的主要原因是:

在这里输入图像说明

所以我做了一个直方图,检查对话框,我运行我的testing,并保持它活着。 事实certificate,它的AutoCompleteTextViews保持活力,而后者又通过android.widget.TextView $ IClipboardDataPasteEventImpl保持活跃状态。 但是IClipboardDataPasteEventImpl没有直接支配者(当然GC根除外)。 我试图find在互联网上的IClipboardDataPasteEventImpl,我search了grepcode(android源码),但我唯一能想到的就是这个博客条目 。 我无法读懂任何语言,但我能读的是英文单词,这表明它可能是三星Galaxy SII(我使用的手机,运行android 2.3.x)的一个错误,与ClipboardManager相关。 然而,我不确定这(我想解决这个问题,因此我不愿意接受它是一个不可修复的bug),我不知道这个剪贴板是在哪里产生的,为什么。 关于这个问题,我将不胜感激。

Solutions Collecting From Web of "内存泄漏通过IClipboardDataPasteEventImpl"

我memleak调查也带我到这里。 我有问题的活动泄漏的EditText。 android.widget.TextView $ IClipboardDataPasteEventImpl对象正在持有EditText这是举行的活动。 这发生在三星Galaxy Tab 10.1和Galaxy Tab 2 10.1,7.0。 我无法在其他非三星设备(华硕,macros碁)上重现它。

坏事是,我没有find它的解决scheme呢:)

调查

这是我的研究成果:

  • 它发生在内容视图由EditText组成的任何Activityfinish()Activity并没有得到垃圾收集,因为它被引用,如下所示:

     activity com.example.MyActivity <- mContext android.widget.TextView <- this$0 android.widget.TextView$IClipboardDataPasteEventImpl <- this$1 android.widget.TextView$IClipboardDataPasteEventImpl$1 <- referent java.lang.ref.FinalizerReference 
  • 这发生在我运行Android 4.0.4的 三星Galaxy Tab GT-P7300上,但运行Android 2.2.1的 三星Galaxy Mini GT-S5570上却没有。

  • IClipboardDataPasteEventImpl对象实际上最终被释放,但只是在似乎是不可预知的时候。

由于它们被java.lang.ref.FinalizerReference引用,所以我相信IClipboardDataPasteEventImpl对象正在等待finalize() ,这只有在JVM感觉到时才会发生。 有关详细信息,请查看以下问题:

  • 是内存泄漏? 为什么java.lang.ref.Finalizer会吃这么多的内存
  • 非常奇怪的OutOfMemoryError

解决scheme/解决方法

对不起,没有解决办法,但这是我最好的解决方法:

在您的Activity onDestroy()中,尽可能多地引用其他对象 (特别是大型活动的位图,集合和子视图),如下所示:

 @Override protected void onDestroy() { // Free reference to large objects. m_SomeLargeObject = null; m_AnotherLargeObject = null; // For ArrayList, if you are a paranoid to null, you may call clear() and then trimToSize(). m_SomeLargeArrayList.clear(); m_SomeLargeArrayList.trimToSize(); // Free child views. m_MyButton = null; // Free adapters. m_ListViewAdapter = null; ... etc. // Don't forget to chain the call to the superclass. super.onDestroy(); } 

这样,我们至less可以减less人员的伤亡,并希望在JVM有心情收集所有那些邪恶的IClipboardDataPasteEventImpl对象之前,不要忘记内存。

在垃圾收集环境的理想世界里,这是没有必要的,但我想大家应该明白,我们的世界并不完美,我们只能忍受这些缺陷。


以下是我在这个问题中提到的原创博客条目的翻译(中文)。 希望这可以让大家更好地了解这个问题。

Galaxy S2内存泄漏与TextView

不知道是不是哪边弄错

不知道哪里出了问题

但是galaxy s2的textview会产生内存泄漏

但是s2textview会导致内存泄漏

泄漏是发生在android.widget.TextView $ IClipboardDataPasteEventImpl这个界面上

interface android.widget.TextView$IClipboardDataPasteEventImpl上发生泄漏

它会抓住mContext造成整个活动没办法被GC

它拥有mContext ,停止activitymContext

同样的程式在htc sensation(2.3.4)跟se xperia arc(2.3.4)和acer liquid(2.1)都没有问题

同样的应用程序在htc感觉(2.3.4) ,第二弧(2.3.4)acer液体(2.1)上没有这样的问题,

而且网路上完全找不到android.widget.TextView $ IClipboardDataPasteEventImpl相关的资料

而且,我找不到任何与web上的android.widget.TextView$IClipboardDataPasteEventImpl相关的东西

android源代码里也找不到看起来应该是samsung自己加的东西…

即使在Android的源代码 ,所以它似乎是由三星自己添加的东西…

之前的opengl viewport bug已经够头痛了接下来soundpool相关bug也搞累很多人

opengl视口的bug已经很让人头疼了,而且与soundpool相关的bug也让很多人感到失望

现在这个memory leak又来搅局…

现在,这里出现了一个内存泄漏

看来手机外型还是比较重要/ _ \ …外型好先吸到人来买bug再慢慢修就好

似乎手机的外观比较重要/外观吸引顾客好; 错误可以稍后修复

[后记]

[PS]

经过一些试验发现只要按HOME键回到桌面,那些泄漏就会被释放掉…

经过一些testing,我发现泄漏将通过按HOME键返回到桌面释放…

logcat会显示一行在开始input时隐藏剪贴板对话框:由别人完成…!

它显示在启动input隐藏剪贴板对话框:由别人完成…!logcat

看起来galaxy s2里面有偷偷对剪贴板作一些操作…

看起来, 银河s2是在引擎盖下的剪贴板上运行的…

但如果一直保持在app里面运作的话,那些泄漏还是会存在…最后应该会发生OOMexception

但是,如果我们留在应用程序 ,这些泄漏仍然存在…最终会发生OOMexception

现在只能期望galaxy s2的ics版会修掉这个怪问题了…

现在我们只能希望这个奇怪的问题可以在星系s2ics版本中解决…