4


MapActivityを拡張するアクティビティのメモリリークを解決するためにEclipseMemoryAnalyzer を使い始めたばかりですが、その出力を正しく理解しているかどうかわかりません。リークを分析するために、アクティビティを開始して画面を数回回転させてから、ヒープダンプを取得して開きました。私が最初にしたことは、ヒストグラムビューを開いて 、自分のアクティビティ（ChangeLocationActivityと呼ばれる）を探すことでした。同じアクティビティのインスタンスが3つあるため、これは確かにメモリリークのように見えます。そこで、着信参照を持つオブジェクトのリストを取得し、3つのインスタンスすべての弱参照を除いた「GCルートへのパス」を取得しました。これが最初のインスタンスのパスです、これ2番目のインスタンス（カスタムMyLocationOverlayは、一部のMotorolaデバイスのバグをバイパスするために作成された非常に単純なクラスであり、drawMyLocation（）で例外をキャッチすることを除いて特別なことは何もありません）、最後にこれは3番目のインスタンスのクラスです。これは現在表示されているもののように見えます。

前に言ったように、これらの結果を正しく理解しているかどうかはわかりませんが（Eclipse Memory Analyzerは非常に強力ですが、非常に複雑です）、メモリリークの原因はGoogleマップライブラリに関連しているように見えます。私が正しいのか、それともこれらの結果を理解していないのか、誰か教えてもらえますか？

4

1 に答える 1

0

すべてのアクティビティを選択し、「GCルートへの最短パスのマージ」を使用します。ここに結果を投稿してください。EventListenerを登録したため、2番目のアクティビティは生きているようです。

「GCルートへの最短パスのマージ」は、MATで最も重要なコマンドの1つです。オブジェクトからルートへのすべてのパスを表示しますが、それらをマージします。したがって、同じパスを共有しているため、どのオブジェクトがまだ生きているかを分析できます。スクリーンショット（3つのサブツリーを展開してください）から、3つのアクティビティが3つのルートオブジェクトで保持されているようです。リークでは、マージされたルートパスに沿っていくつかの共通オブジェクトを共有するのが一般的です。通常、私があなたのケースで見たものから、各アクティビティが異なるルートオブジェクトによって保持されているため、リークの理由は複数あります。テストを繰り返して、できるだけ多くのアクティビティがリークされるようにすることをお勧めします。

よろしく、マーカス

于 2011-12-14T08:46:32.010 に答える