メモリ漏洩入門から三部作に精通するまでの調査方法編
4870 ワード
テンセントBugly特約作者:姚潮生
最も元のメモリ漏洩テスト
重要な不審なパスを複数回繰り返し、メモリモニタツールからメモリカーブを観察します.上昇傾向があり、プログラムが戻ったときに明らかに下落しないかどうかを確認します.この方式は最も基本的で、最も明らかなメモリ漏洩の問題で、ユーザーに対する価値が最も大きく、操作の難易度が小さく、性価比が極めて高いことを発見することができる.
MATメモリ分析ツール
2.1 MATはheapの総メモリ占有量の大きさを分析して漏れがあるかどうかを初歩的に判断する Devicesで、監視するプログラムをクリックします. Devicesビュー画面の一番上のアイコンの「Update Heap」 をクリックします. Heapビュー をクリック Heapビューの「Cause GC」ボタン をクリックここまで検出が必要なプロセスを監視することができる.
Heapビューの中央にはdata objectというタイプがあります.つまり、データオブジェクト、つまり、私たちのプログラムに大量に存在するクラスタイプのオブジェクトです.data object行には「Total Size」という列があり、その値は現在のプロセスにおけるすべてのJavaデータオブジェクトのメモリ総量であり、一般的にこの値の大きさはメモリ漏洩の有無を決定します.次のように判断できます.
あるアプリケーションに入り、そのアプリケーションを操作し続けるとともに、data objectのTotal Size値を観察することに注意すると、通常、Total Size値は限られた範囲に安定します.つまり、プログラム中のコードが良好であるため、対象がゴミ回収されない状況はありません.
だから、私たちの絶えずの操作は絶えず多くのオブジェクトを生成しますが、仮想マシンが絶えずGCを行う過程で、これらのオブジェクトはすべて回収され、メモリの占有量は安定したレベルに落ちます.逆に,コードにオブジェクト参照が解放されていない場合,data objectのTotal Size値はGCごとに有意に低下しない.操作回数が増えるにつれてTotal Sizeの値はますます大きくなり、上限に達するまでプロセスが殺されます.
2.2 MATはhprofを分析してメモリ漏洩の原因を特定する.
これはメモリ漏洩が発生した後にMATを用いて問題の位置決めを行う有効な手段である. Dump出メモリ漏洩当時のメモリミラーhprof,分析漏洩疑いのクラス: このようなオブジェクト参照を持つ外部オブジェクトを分析する .参照を持つオブジェクトを解析するGCパス 各オブジェクトのGCパスが正常かどうかを1つずつ分析する このパスから、antiRadiationUtilツールクラスオブジェクトがMainActivityの参照を持っているため、MainActivityが解放されないことがわかります.この時点でコード解析に進むantiRadiationUtilのリファレンスの持ち方が妥当かどうか(antiRaditionUtilがMainActivityのcontextを持っていると番組終了後にMainActivityが破棄できなくなり、メモリリークになるのが一般的です).
2.3 MATは操作前後のhprofと比較してメモリ漏洩の原因を特定する.
メモリリークを検出するには、通常2つのDump結果を比較してNavigator Historyパネルを開き、2つのテーブルのHistogram結果をCompare Basketに追加します.最初のHPROFファイル(usingFile>Open Heap Dump). Histograviewを開きます. NavigationHistory view(見えない場合はWindow>show view>MAT-Navigation History)でhistogramを右クリックしてAdd to Compare Basketを選択する. 2 2 2番目のHPROFファイルを開いて、手順2および3をやり直します. Compare Basket viewに切り替え、Compare the Results(右上隅の赤"!)をクリックします.を選択). 分析比較結果 2つのhprofのデータオブジェクトの比較結果がわかります.これにより、操作前後に保持されるオブジェクトの増分を迅速に位置決めすることができ、現在の操作によるメモリ漏洩の具体的な原因は、どのようなデータオブジェクトが漏洩したのかをさらに特定することができる.
注意:
MAT Eclipseプラグインで取得したDumpファイルであれば、変換する必要がなければMATで開くことができ、Adtは自動的に変換します.
携帯電話のSDk Dumpから出たファイルは変換されてMATに認識され、Android SDKはこのツールhprof-conv(sdk/toolsの下にある)を提供しています.
まず、コンソールからandroid sdk toolsディレクトリにアクセスして、次のコマンドを実行します.
例えば
携帯電話の執事のメモリ漏洩の毎日の監視方案
現在、携帯電話の執事のメモリ漏洩は、漏洩対象の大きさにかかわらず、漏洩の疑いのある報告メールが自動的に実行され、出力されます.これに関連するコア技術は主にAspectJ,MLD自己研磨ツール(原理は虚引用)とUIAutomatorである.
3.1 AspectJ杭挿入監視コード
携帯電話の執事は現在、antスクリプトを使用してMLDの監視コードを追加し、AspectJの構文を通じて杭を挿入しています.AspectJを使用する理由は、プロジェクトのソースコードとモニタリングコードを柔軟に分離し、異なるコンパイルスクリプトを通じて異なる用途のインストールテストパッケージをパッケージ化することです.もしテストパッケージがAspectを介してMLDモニタリングコードを挿入した場合、実行が完了すると、指定したフォーマットのログファイルが出力され、後続の分析作業のデータベースとなります.
3.2 MLD監視コアロジックを実現
これは携帯電話の執事内のツールプロジェクトで、正式なパッケージは打ち込まれず、BVTなどの毎日監視テストパッケージは打ち込むことができます.入力後に、addObjectインタフェース(ツールが含まれているかどうかを反射して確認し、呼び出す)などのモニタリングが必要な検出オブジェクトを追加することができ、このツールは、指定されたタイミング(例えば、執事を終了する)で、オブジェクトが漏洩しているかどうかを自動的に検出します.
このメモリリーク検出の基本原理は、
ダミーリファレンスは、主にオブジェクトがゴミ回収器で回収されたアクティビティを追跡するために使用されます.ダミーリファレンスはリファレンスキュー(ReferenceQueue)と組み合わせて使用する必要があります(ダミーリファレンス関数では関連付けて指定する必要があります).ゴミ回収器がオブジェクトを回収する準備をしている場合、ダミー参照があることが判明すると、オブジェクトのメモリを回収する前に、このダミー参照が関連付けられた参照キューに自動的に追加されます.プログラムは、参照キューに虚参照が含まれているかどうかを判断することによって、参照されたオブジェクトがゴミ回収されるかどうかを知ることができる.
以上の原理に基づいて、MLDツールは、インタフェースaddObjectを呼び出してモニタタイプを追加すると、そのタイプのオブジェクトにダミー参照を追加します.ダミー参照は、オブジェクトが正常に回収されることに影響しません.したがって、回収されていないモニタオブジェクトが指定したバルブ値を超えているかどうかは、ReferenceQueueリファレンスキューで統計できます.
PhantomReferences(ダミーリファレンス)とReferenceQueue(リファレンスキュー)を使用して、PhantomReferencesが関連するReferenceQueueに追加された場合、オブジェクトはすでにゴミ回収器回収段階にあるか、またはゴミ回収器回収段階にあるかのいずれかになります.
MLDモニタ原理コア
現在、携帯電話の執事はすでに大部分の分類に対してメモリの漏洩の監視を完成して、各種activity、serviceとviewページなどを含んで、技術の上でユーザーに最も滑らかな製品の体験をもたらすことができることを求めます.
次に、このツールの判断の核心を簡単に紹介します.ダミーリファレンスが監視するメモリの状態に応じて、メモリ漏洩の有無を複数のポリシーで判断する必要があります.最も簡単な方法は、監視に直接参加するときにこのタイプの最大存在個数を設定することであり、例を挙げると、各DAOオブジェクトは理論的に最大1つしか存在しないため、同じDAOが2つ現れると、一般的に漏れてしまう. 第2のケースは、ページ終了プログラムが終了したときにgcを取得した後に解放できないオブジェクトリストであり、これらのオブジェクトタイプもメモリ漏洩の疑いの対象となる. 最後のケースは複雑で、基本原理は履歴操作に基づいて対象数の増加幅を判断することである.オブジェクトの成長に基づいて最小二乗法でそのオブジェクトタイプの成長速度をフィットし、経験値を超えると漏洩の疑いのあるオブジェクトのリストに登録されます.
3.3 UIautomatorによる重複操作の自動化
最後の一歩は簡単です.このようなUI操作を繰り返すと、人手で注文するのはもったいない.UIAutomatorを使用して自動化操作テストを行います.
現在、携帯電話の執事の毎日の自動化テストは各機能の主な経路をカバーし、プロファイルの方式を通じて用例の削除・変更を柔軟に駆動し、バージョンの推移に伴う用例の多重化価値を最大限に保証している.
これで携帯電話の執事のメモリ漏洩テスト案の紹介が終わり、各道の牛人がより強いメモリ漏洩ツールボックス案を交流することを歓迎します.
Buglyはテンセント内部の製品品質監視プラットフォームの外発バージョンで、その主な機能はAppが発表された後、ユーザー側で発生したCrashとカートン現象を監視し、報告し、開発学生にAppの品質状況を最初に理解させ、タイムリーに機種を修正させることができる.現在、テンセント内部のすべての製品は、オンライン製品の崩壊監視に使用されている.
最も元のメモリ漏洩テスト
重要な不審なパスを複数回繰り返し、メモリモニタツールからメモリカーブを観察します.上昇傾向があり、プログラムが戻ったときに明らかに下落しないかどうかを確認します.この方式は最も基本的で、最も明らかなメモリ漏洩の問題で、ユーザーに対する価値が最も大きく、操作の難易度が小さく、性価比が極めて高いことを発見することができる.
MATメモリ分析ツール
2.1 MATはheapの総メモリ占有量の大きさを分析して漏れがあるかどうかを初歩的に判断する
Heapビューの中央にはdata objectというタイプがあります.つまり、データオブジェクト、つまり、私たちのプログラムに大量に存在するクラスタイプのオブジェクトです.data object行には「Total Size」という列があり、その値は現在のプロセスにおけるすべてのJavaデータオブジェクトのメモリ総量であり、一般的にこの値の大きさはメモリ漏洩の有無を決定します.次のように判断できます.
あるアプリケーションに入り、そのアプリケーションを操作し続けるとともに、data objectのTotal Size値を観察することに注意すると、通常、Total Size値は限られた範囲に安定します.つまり、プログラム中のコードが良好であるため、対象がゴミ回収されない状況はありません.
だから、私たちの絶えずの操作は絶えず多くのオブジェクトを生成しますが、仮想マシンが絶えずGCを行う過程で、これらのオブジェクトはすべて回収され、メモリの占有量は安定したレベルに落ちます.逆に,コードにオブジェクト参照が解放されていない場合,data objectのTotal Size値はGCごとに有意に低下しない.操作回数が増えるにつれてTotal Sizeの値はますます大きくなり、上限に達するまでプロセスが殺されます.
2.2 MATはhprofを分析してメモリ漏洩の原因を特定する.
これはメモリ漏洩が発生した後にMATを用いて問題の位置決めを行う有効な手段である.
2.3 MATは操作前後のhprofと比較してメモリ漏洩の原因を特定する.
メモリリークを検出するには、通常2つのDump結果を比較してNavigator Historyパネルを開き、2つのテーブルのHistogram結果をCompare Basketに追加します.
注意:
MAT Eclipseプラグインで取得したDumpファイルであれば、変換する必要がなければMATで開くことができ、Adtは自動的に変換します.
携帯電話のSDk Dumpから出たファイルは変換されてMATに認識され、Android SDKはこのツールhprof-conv(sdk/toolsの下にある)を提供しています.
まず、コンソールからandroid sdk toolsディレクトリにアクセスして、次のコマンドを実行します.
./hprof-conv xxx-a.hprof xxx-b.hprof例えば
hprof-conv input.hprof out.hprofの場合にout.hprofはeclipseのMATで開きます.携帯電話の執事のメモリ漏洩の毎日の監視方案
現在、携帯電話の執事のメモリ漏洩は、漏洩対象の大きさにかかわらず、漏洩の疑いのある報告メールが自動的に実行され、出力されます.これに関連するコア技術は主にAspectJ,MLD自己研磨ツール(原理は虚引用)とUIAutomatorである.
3.1 AspectJ杭挿入監視コード
携帯電話の執事は現在、antスクリプトを使用してMLDの監視コードを追加し、AspectJの構文を通じて杭を挿入しています.AspectJを使用する理由は、プロジェクトのソースコードとモニタリングコードを柔軟に分離し、異なるコンパイルスクリプトを通じて異なる用途のインストールテストパッケージをパッケージ化することです.もしテストパッケージがAspectを介してMLDモニタリングコードを挿入した場合、実行が完了すると、指定したフォーマットのログファイルが出力され、後続の分析作業のデータベースとなります.
3.2 MLD監視コアロジックを実現
これは携帯電話の執事内のツールプロジェクトで、正式なパッケージは打ち込まれず、BVTなどの毎日監視テストパッケージは打ち込むことができます.入力後に、addObjectインタフェース(ツールが含まれているかどうかを反射して確認し、呼び出す)などのモニタリングが必要な検出オブジェクトを追加することができ、このツールは、指定されたタイミング(例えば、執事を終了する)で、オブジェクトが漏洩しているかどうかを自動的に検出します.
このメモリリーク検出の基本原理は、
ダミーリファレンスは、主にオブジェクトがゴミ回収器で回収されたアクティビティを追跡するために使用されます.ダミーリファレンスはリファレンスキュー(ReferenceQueue)と組み合わせて使用する必要があります(ダミーリファレンス関数では関連付けて指定する必要があります).ゴミ回収器がオブジェクトを回収する準備をしている場合、ダミー参照があることが判明すると、オブジェクトのメモリを回収する前に、このダミー参照が関連付けられた参照キューに自動的に追加されます.プログラムは、参照キューに虚参照が含まれているかどうかを判断することによって、参照されたオブジェクトがゴミ回収されるかどうかを知ることができる.
以上の原理に基づいて、MLDツールは、インタフェースaddObjectを呼び出してモニタタイプを追加すると、そのタイプのオブジェクトにダミー参照を追加します.ダミー参照は、オブジェクトが正常に回収されることに影響しません.したがって、回収されていないモニタオブジェクトが指定したバルブ値を超えているかどうかは、ReferenceQueueリファレンスキューで統計できます.
PhantomReferences(ダミーリファレンス)とReferenceQueue(リファレンスキュー)を使用して、PhantomReferencesが関連するReferenceQueueに追加された場合、オブジェクトはすでにゴミ回収器回収段階にあるか、またはゴミ回収器回収段階にあるかのいずれかになります.
MLDモニタ原理コア
現在、携帯電話の執事はすでに大部分の分類に対してメモリの漏洩の監視を完成して、各種activity、serviceとviewページなどを含んで、技術の上でユーザーに最も滑らかな製品の体験をもたらすことができることを求めます.
次に、このツールの判断の核心を簡単に紹介します.ダミーリファレンスが監視するメモリの状態に応じて、メモリ漏洩の有無を複数のポリシーで判断する必要があります.
3.3 UIautomatorによる重複操作の自動化
最後の一歩は簡単です.このようなUI操作を繰り返すと、人手で注文するのはもったいない.UIAutomatorを使用して自動化操作テストを行います.
現在、携帯電話の執事の毎日の自動化テストは各機能の主な経路をカバーし、プロファイルの方式を通じて用例の削除・変更を柔軟に駆動し、バージョンの推移に伴う用例の多重化価値を最大限に保証している.
これで携帯電話の執事のメモリ漏洩テスト案の紹介が終わり、各道の牛人がより強いメモリ漏洩ツールボックス案を交流することを歓迎します.
Buglyはテンセント内部の製品品質監視プラットフォームの外発バージョンで、その主な機能はAppが発表された後、ユーザー側で発生したCrashとカートン現象を監視し、報告し、開発学生にAppの品質状況を最初に理解させ、タイムリーに機種を修正させることができる.現在、テンセント内部のすべての製品は、オンライン製品の崩壊監視に使用されている.