内存泄漏通过IClipboardDataPasteEventImpl

时间：2013-01-03 09:16:22

标签： android memory-leaks android-ui

我注意到我的一个活动内存增加了奇怪。因此我进行了一些测试：我多次打开对话框（打开 - 关闭 - 打开 - 关闭....）并且内存不断增加。所以我使用DDMS转储HPROF文件并在MAT（内存分析器）中打开它。泄密嫌疑人报告指出，内存消耗增长的主要原因是：

enter image description here

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

2 个答案:

答案 0 :(得分：8)

研究

以下是我的研究结果：

  • 内容视图由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

  • 它发生在我的三星Galaxy Tab GT-P7300 上运行 Android 4.0.4 ，但不在我的三星Galaxy Mini GT-S5570 < / em>正在运行 Android 2.2.1 。

  • 实际上，IClipboardDataPasteEventImpl个对象最终会被释放，但有时候似乎是不可预测的。

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

解决方案/ 解决方法

抱歉，没有解决方案，但这是我最好的解决方法：

在onDestroy()的{​​{1}}中，尽可能多地引用其他对象（尤其是大的，例如您的位图，集合和子视图活动），像这样：

Activity

这样，我们至少可以减少伤亡人数，并且在JVM有心情完成并收集所有这些邪恶的@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(); } 对象之前，希望不会失去记忆。

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

以下是我在问题中提到的original blog entry（中文）的翻译。希望这可以让每个人更好地了解这个问题。

  使用TextView

Galaxy S2内存泄漏      

不知道是不是哪边弄错

不知道哪里出错了

  

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

但 galaxy s2 的IClipboardDataPasteEventImpl导致内存泄漏

  

泄漏是发生在android.widget.TextView $ IClipboardDataPasteEventImpl这个接口上

泄漏在textview interface

上发生
  

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

它保留android.widget.TextView$IClipboardDataPasteEventImpl，阻止mContext成为 gc 'ed

  

同样的程式在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相关的资料

而且，我无法在网络上找到与activity相关的任何内容

  

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

甚至没有 android源代码，所以它似乎是 samsung 自己添加的东西...

  

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

opengl viewport bug 已经很头疼了， soundpool 相关的 bug 让很多人感到沮丧

  

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

现在，这里出现了内存泄漏搞乱......

  

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

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


  

[后记]

[P.S。]

  

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

经过一些测试后，我发现按 HOME按钮返回桌面即可释放泄漏 ...

  

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

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

  

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

似乎 galaxy s2 正在幕后的剪贴板上运行......

  

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

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

  

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

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

答案 1 :(得分：7)

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

糟糕的是我还没有找到解决方案：）

相关问题
最新问题