7

アプリでランダムに（メモリ不足で）クラッシュするので、ヒープの分析を開始しました。アクティビティAからアクティビティBに移動すると、ヒープが27MBから35MBに増加することに気付きました（多くの画像の遅延読み込みが原因）。ただし、アクティビティBをfinish（）してアクティビティAに戻すと、ヒープサイズはGC操作でも同じに保たれます!!

厄介なのは、アクティビティBにもう一度移動すると、ヒープが42MBに増加することです。私はこれを時々行うことができ、ヒープは増え続けるだけです。

これは私が使用している怠惰な画像読み込みライブラリです：

LazyList https://github.com/thest1/LazyList

これらはヒープのスクリーンショットです

以前： http： //i.stack.imgur.com/7eTzm.png

後： http： //i.stack.imgur.com/txeC6.png

変換されたヒープダンプファイルは、リクエストに応じて利用できます

アップデート

私のデバッグからは、LazyListライブラリの問題のようですが、それでも100％確実ではありません。これは、ライブラリにコメントしている人々への参照です：

https://github.com/thest1/LazyList/issues/20

4

3 に答える 3

1

すでにロードされているアクティビティに切り替えるのではなく、毎回新しいアクティビティを開始しているように思えます。アクティビティを切り替えるときに、 Intent.FLAG_ACTIVITY_REORDER_TO_FRONTを含めるようにインテントにフラグを設定してみてください。

これを見る

于 2013-01-25T19:42:24.607 に答える
1

私の推測では、アクティビティをリークしている可能性があります (これにより、保持しているすべての変数がリークされる可能性があります)。コンテキストを渡す必要のあるすべての OS 呼び出しが登録解除されていること、アクティビティへの参照を保持するオブジェクトがないこと (特にコンテキストを保持することによって)、および onDestroy で可能なすべてを null にすることを確認してください。または onStop (すべての主要なオブジェクトでもそうします)。

それだけでは不十分な場合は、hprof を見て、アクティビティを強制終了した後にどのような大きなオブジェクトが横たわっているか、また誰が参照を保持しているかを確認してください。修正して繰り返します。

于 2013-01-25T19:23:18.510 に答える
0

使用している画像の可能性があるようです。AndroidのBitmapFactoryは不変のビットマップを作成するため、これらのビットマップに加えた変更は元の画像から分離されます。

さらに悪いことに、recycleと指示したとしても、ガベージ コレクションされるかどうかは参照に依存します。

于 2013-01-25T23:41:56.330 に答える