2012-05-06 8 views
5

ここに、私が に経験豊富な意見を聞くことを望む初心者のメモリ管理の観察があります。xmlリークメモリのAndroidビットマップは?

xml レイアウトでandroid:backgound = "@ drawable/xyz"と設定すると、アプリでメモリが失われるようです。 OOMエラーが発生するまで、それぞれのアクティビティは をスタックしています。これは、デバイスの向きを にすると、特に当てはまります。

しかし、setBackgoundResource()で同じリソースをロードしてから コールバックをクリアし、バックグラウンド参照をnullに設定すると、リークはまったくありません。 onCreateで最初の、onDestroy()内

mMainLayout.setBackgroundResource(R.drawable.background_general_android); 

、その後で

()

mMainLayout.getBackground().setCallback(null); 
mMainLayout.setBackgroundDrawable(null); 

これはおおよそ正しいですか、私には必要不可欠何かが足りないのですか?

+0

私は時々非常に同じ問題に直面します。私はonCrateとonDestroyでビットマップを管理しようとします。 ty – guness

答えて

1

これは、たとえば、ドロアブルのコピーを静的キャッシュに保持している場合にのみ発生します。また、あなたの活動を漏らしている可能性があり、drawablesをnullに設定すると、少しだけ問題が隠されます。あなたは、MATのようなツールを使ってヒープの内容を検査し、何が起こっているのか把握する必要があります。

+1

上記の観測は、MATとの長い痛い週末に基づいています:)私は基本的に、500kのバックグラウンドリソースのビットマップと何もせずsetContentView()でxmlをロードしたアクティビティだけで、ベアボーンの線形レイアウトを作成しました。ビットマップがxml =>メモリ損失とOOMの内部で設定されたとき。プログラムによってロードされ、onDestroy()でクリアされても、問題はありません。しかし、私は、この最小限のテスト活動以外では、アプリの残りの部分がかなり大きく、結果に影響を与える可能性があることを言及する必要があります。私は特に「本当のアプリの中で」テストすることを望んでいました。 Androidのバージョンは2.2(レベル8)です。 – perza

関連する問題