内存泄漏通过IClipboardDataPasteEventImpl

Question

我注意到我的一个活动内存增加了奇怪.因此我进行了一些测试:我多次打开对话框(打开 - 关闭 - 打开 - 关闭....)并且内存不断增加.所以我使用DDMS转储HPROF文件并在MAT(Memory analyzer)中打开它.漏洞可疑报告指出,内存消耗增长的主要原因是:

所以我做了一个直方图,检查我运行测试的对话框是什么让它保持活力.事实证明,它通过它的AutoCompleteTextViews保持活跃,而后者又由android.widget.TextView $ IClipboardDataPasteEventImpl保持活着.但是IClipboardDataPasteEventImpl没有直接的支配者(GC当然除外).我试图在互联网上找到IClipboardDataPasteEventImpl并且我搜索了grepcode(android源码),但我唯一想到的就是这个博客条目.我无法阅读任何语言,但我能读到的是投入的英文单词,这表明它可能是三星Galaxy SII(我正在使用的手机,运行android 2.3.x)上的一个错误,与ClipboardManager相关.但是我不确定这个(我想解决这个问题,因此我不愿意接受它只是一个无法修复的错误)而且我不知道这个剪贴板产生的原因和原因.我非常感谢有关此事的任何指示/想法.

Answer 1

调查

这是我的研究结果:

• 任何Activity内容视图都包含的内容都会发生EditText.finish()在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感觉到时才会发生.有关详细信息,请查看以下SO问题:

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

解决方案/解决方法

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

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

@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();
}

通过这种方式,我们至少可以减少人员伤亡,并且在JVM有心情完成并收集所有这些恶意IClipboardDataPasteEventImpl对象之前,希望不会失去记忆.

在垃圾收集环境的理想世界中,这是不必要的,但我想我们都应该意识到我们的世界并不完美,我们只能忍受这些缺陷.

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

Galaxy S2内存泄漏与TextView

不知道是不是哪边弄错

不知道哪里出错了

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

但textview的银河S2导致内存泄漏

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

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

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

它拥有的mContext,停止activity被GC "版

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

在htc sensation(2.3.4),se xperia arc(2.3.4)和acer liquid(2.1)上的相同应用程序没有这样的问题

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

而且,我根本找不到与android.widget.TextView$IClipboardDataPasteEventImpl网络相关的任何内容

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

甚至没有在android源代码中,所以它似乎是由三星自己添加的东西......

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

在OpenGL的视口的bug很是头疼不已,和的Soundpool相关的bug已经受挫很多

现在这个内存泄漏又来来搅......

而现在,这里出现了内存泄漏 ......

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

似乎手机的外观更重要/ _\...良好的外观吸引着顾客; 错误可以在以后修复

[后记]

[PS]

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

经过一些测试,我发现通过按HOME按钮返回桌面可以解除泄漏 ...

logcat会显示一行在开始输入时隐藏剪贴板对话框:由其他人完成...!

它在启动输入时显示隐藏剪贴板对话框:由其他人完成...!在logcat中

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

似乎galaxy s2正在引擎盖下的剪贴板上运行......

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

但是如果我们留在应用程序中,那些泄漏仍然存在......最终会发生OOM异常

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

现在我们只能希望在Galaxy s2的ics版本中解决这个奇怪的问题......

Answer 2

我的memleak调查也把我带到了这里.我在EditText上出现Activity泄漏问题.android.widget.TextView $ IClipboardDataPasteEventImpl对象持有保存活动的EditText.这发生在Samsung Galaxy Tab 10.1和Galaxy Tab 2 10.1,7.0上.我无法在其他非三星设备(华硕,宏碁)上重现它.

糟糕的是,我还没有找到解决方案:)