調査
ここに私の研究結果があります:
これは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を実行しているSamsung Galaxy Tab GT-P7300 では発生しますが、 Android 2.2.1を実行しているSamsung Galaxy Mini GT-S5570 では発生しません。
- 実際には、
IClipboardDataPasteEventImpl
オブジェクトは最終的に解放されますが、予測できないように思われる場合にのみ解放されます。
それらは によって参照されているのでjava.lang.ref.FinalizerReference
、IClipboardDataPasteEventImpl
オブジェクトは 'd されるのを待っていると思いますfinalize()
。これは、JVM がそうしたいと感じた場合にのみ発生します。詳細については、次の SO の質問を確認してください。
解決策/回避策
申し訳ありませんが、解決策はありませんが、これが私の最善の回避策です。
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
オブジェクトをファイナライズして収集する気分になる前にメモリ不足になることはありません。
ガベージ コレクション環境の理想的な世界では、これは必要ありませんが、私たちの世界は完璧ではなく、欠陥と共に生きなければならないことを認識すべきだと思います。
以下は、質問に記載されている元のブログ エントリ(中国語)の私の翻訳です。これにより、この問題についての理解を深めることができれば幸いです。
TextView による Galaxy S2 のメモリ リーク
不知道是不是哪邊弄錯
どこが悪かったのか不明
ただし、galaxy s2 の textview メモリ リーク
しかし、textview
galaxy s2のメモリ リークが発生します。
漏れは發生在android.widget.TextView$IClipboardDataPasteEventImpl這個インターフェイス上</p>
リークが発生interface
android.widget.TextView$IClipboardDataPasteEventImpl
它會抓住mContext造成個活動沒辦法被gc
を保持しmContext
、がGCactivity
されるのを防ぎます
同樣的式は、htcensens(2.3.4)に加え、xperia arc(2.3.4)とacer Liquid(2.1)都沒有問題</p>
htc sense(2.3.4)、se xperia arc(2.3.4)、acer Liquid(2.1)の同じアプリでそのような問題はありません
さらに、ネットワーク上では完全に android.widget.TextView$IClipboardDataPasteEventImpl に到達していません</p>
android.widget.TextView$IClipboardDataPasteEventImpl
そして、私はウェブ上で関連するものをまったく見つけることができません
Android ソース コード裡也找不到 看起來應これ是 samsung 自己加的東西...
Androidのソースコードにもないので、サムスン自身が追加したもののようです...
今までのopenglビューポートのバグ已經夠頭痛了
opengl ビューポートのバグはすでに頭痛の種であり、soundpool関連のバグは多くの人を苛立たせていました。
現在這い個メモリリーク又來障害局...
そして今、ここでメモリリークが発生します...
看來手機外型還是比較重要 /_\... 外型好先吸到人來買 bug再慢慢修就好
携帯電話は外見の方が重要なようですね /_\... 見栄えの良さがお客様を惹きつけます。バグは後で修正される可能性があります
[後記]
【追伸】
經過一いくつかの試驗發現ただ要ホームボタンを回して桌面へ,それらのリーク就會被釋放掉...
いくつかのテストの後、ホームボタンを押してデスクトップに戻るとリークが解放されることがわかりました...
logcat會顯示一行 開始入力でクリップボードダイアログを非表示: 他の誰かによって終了... !
Starting input: finished by someone else... で [Hide Clipboard] ダイアログが表示されます。logcatで
看起來galaxy s2裡面には偷偷對clipboardがいくつか操作されています...
どうやらギャラクシーs2はボンネットの下のクリップボードで動作しているようです...
しかし、もしそうなら、アプリの面で成功した話、いくつかのリーク還は會の存在です...最後にこの會發生OOM例外を適用します
しかし、アプリにとどまると、それらのリークが残ります...最終的にOOM例外が発生します
現在只今能期望galaxy s2 的ics版會修掉這個怪問題了...
この奇妙な問題がGalaxy s2のicsバージョンで解決されることを願うばかりです...