メモリ漏洩チェックステップ-メモリ最適化(4)
8271 ワード
転載は出典を明記してください.http://blog.csdn.net/xx326664162/article/details/49949833文の出典:薛スーのブログ
あなたも私の他の同類の文章を見ることができて、あなたにも一定の出荷があります!
Android Device Monitor分析heap
Android Device Monitorは、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の値はますます大きくなり、上限に達するまでプロセスが殺されます.
MATはhprofを分析してメモリ漏洩の原因を特定する
メモリをデバッグするには、まずHPROFファイルを取得する必要があります.HPROFファイルはMATで認識できるファイルで、HPROFファイルには特定の時点、javaプロセスのメモリスナップショットが格納されています.これらのデータを格納するフォーマットは異なり、スナップショットがトリガーされたときにjavaオブジェクトとクラスがheapにある場合が含まれます.スナップショットは一瞬のことなので、heap dumpには、オブジェクトがいつ、どこ(どのメソッドで)割り当てられるかという情報は含まれません.
1、Android StudioでHPROFファイルを取得する(2つの方法)
1つ目は、Android Studioを使用して、対応するHPROFファイルをエクスポートすることです.
最新バージョンのAndroid Studioは、MATで開くには、ファイルを右クリックして標準のHPROFファイルに変換する必要があります.
2つ目:Android Device Monitorを開き、eclipseのDDMSに似ています
(私のところでは他の人のDDMS図を使っていますが、Android Device Monitorでの操作と同じです)
ストレージパスを選択して保存すると、対応するプロセスのHPROFファイルが得られます. MAT Eclipseプラグインで取得したDumpファイルであれば、変換する必要がなければMATで開くことができ、Adtは自動的に変換します. Android Studioは独立してインストールするMATが必要で、Android SDKが持参したツール(hprof-conv位置はsdk/platform-tools/hprof-conv)を使用して を変換します.
変換後のhprofファイルはMATツールで開くことができます.
2、Android Studioの学生はMAT独立ソフトを使って開く
3、メモリの漏洩箇所を調べる
1つ目の方法:
1.Histogram図では、図のような位置入力でクエリーを行い、例えば:
2、with incoming referencesを選択して下図に入り、これらの参照を持つオブジェクトのGCパスを分析します.図中のサブメニューの2つのオプションは、Phantom Ref(虚参照)とWeak Ref(弱参照)を除去することを示しています.理由はここを参照してください.
3、各オブジェクトのGCパスが正常かどうかを1つずつ分析する
このパスから、antiRadiationUtilツールクラスオブジェクトがMainActivityの参照を持っているため、MainActivityが解放されないことがわかります.この時点でコード解析に進むantiRadiationUtilのリファレンスの持ち方が妥当かどうか(antiRaditionUtilがMainActivityのcontextを持っていると番組終了後にMainActivityが破棄できなくなり、メモリリークになるのが一般的です).
2つ目の方法:
あるオブジェクトに漏洩が疑われた場合,OQLによりさらに証明することができる.OQLは、クラスのインスタンス情報をクエリーすることを主に使用する構文をクエリーすることで、特定のオブジェクト情報をクエリーできます.構文:
結果は図のようになります.
Class Name
Shallow Heap
Retained Heap
com.yunos.tv.launchersdk.view.component.ScreenContainer @ 0x443108e8
680
2,712
com.yunos.tv.launchersdk.view.component.ScreenContainer @ 0x42817648
680
16,289,472
図中説明com.yunos.tv.launchersdk.view.component.ScreenContainerクラスには2つのインスタンスがあり、2つのインスタンスが消費するメモリサイズはそれぞれ2712と16289472です.インスタンスの数が予想を超えている場合は、メモリ漏洩があることを示します.インスタンスが予想を超えている場合は、インスタンス内の参照に問題があることを示し、インスタンスの詳細をさらに分析できます.
ここでメモリ漏洩の原因と解決方法について詳しく説明します.
MATは操作前後のhprofと比較してメモリ漏洩の原因を特定する
メモリリークを検出するには、通常2つのDump結果を比較してNavigator Historyパネルを開き、2つのテーブルのHistogram結果をCompare Basketに追加します.
1.最初のHPROFファイル(usingFile>Open Heap Dump).
2、Histograviewを開きます.
3、NavigationHistory view(見えない場合はWindow>show view>MAT-Navigation History)でhistogramを右クリックしてAdd to Compare Basketを選択する.
4、2番目のHPROFファイルを開き、手順2と3をやり直します.
5、Compare Basket viewに切り替え、Compare the Results(右上の赤を表示!)アイコンをクリックします.
6、比較結果の分析
2つのhprofのデータオブジェクトの比較結果がわかります.これにより、操作前後に保持されるオブジェクトの増分を迅速に位置決めすることができ、現在の操作によるメモリ漏洩の具体的な原因は、どのようなデータオブジェクトが漏洩したのかをさらに特定することができる.
転載:https://mp.weixin.qq.com/s?__biz=MzA3NTYzODYzMg==&mid=400891536&idx=1&sn=0b6c629b0abe4a359d6552cd244c0c0c&scene=1&srcid=0303pbuNmzzdPnwQLozLrMip&pass_ticket=8HY76%2FaZXUVizdmMUJA7KW40UY8GIW54Sj85H1PLcNuzGxmipJ36D7AsqXOA%2BdRb#rd http://www.jianshu.com/p/d8e247b1e7b2#
私の公衆番号に注目して、もっと多くの技術を簡単に理解して勉強します.
あなたも私の他の同類の文章を見ることができて、あなたにも一定の出荷があります!
Android Device Monitor分析heap
Android Device Monitorは、heapの総メモリ使用量の大きさを分析し、漏洩の有無を初歩的に判断します.
Android Device Monitor， eclipse DDMS
Heapビューの中央にはdata objectというタイプがあります.つまり、データオブジェクト、つまり、私たちのプログラムに大量に存在するクラスタイプのオブジェクトです.data object行には「Total Size」という列があり、その値は現在のプロセスにおけるすべてのJavaデータオブジェクトのメモリ総量であり、一般的にこの値の大きさはメモリ漏洩の有無を決定します.
あるアプリケーションに入り、そのアプリケーションを継続的に操作するとともに、data objectのTotal Size値を観察することに注意し、通常、Total Size値は限られた範囲内に安定している.すなわち、プログラム中のコードが良好であるため、対象がゴミ回収されない場合はない.
だから、私たちの絶えずの操作は絶えず多くのオブジェクトを生成しますが、仮想マシンが絶えずGCを行う過程で、これらのオブジェクトはすべて回収され、メモリの占有量は安定したレベルに落ちます.逆に,コードにオブジェクト参照が解放されていない場合,data objectのTotal Size値はGCごとに有意に低下しない.操作回数が増えるにつれてTotal Sizeの値はますます大きくなり、上限に達するまでプロセスが殺されます.
MATはhprofを分析してメモリ漏洩の原因を特定する
メモリをデバッグするには、まずHPROFファイルを取得する必要があります.HPROFファイルはMATで認識できるファイルで、HPROFファイルには特定の時点、javaプロセスのメモリスナップショットが格納されています.これらのデータを格納するフォーマットは異なり、スナップショットがトリガーされたときにjavaオブジェクトとクラスがheapにある場合が含まれます.スナップショットは一瞬のことなので、heap dumpには、オブジェクトがいつ、どこ(どのメソッドで)割り当てられるかという情報は含まれません.
1、Android StudioでHPROFファイルを取得する(2つの方法)
1つ目は、Android Studioを使用して、対応するHPROFファイルをエクスポートすることです.
最新バージョンのAndroid Studioは、MATで開くには、ファイルを右クリックして標準のHPROFファイルに変換する必要があります.
2つ目:Android Device Monitorを開き、eclipseのDDMSに似ています
(私のところでは他の人のDDMS図を使っていますが、Android Device Monitorでの操作と同じです)ストレージパスを選択して保存すると、対応するプロセスのHPROFファイルが得られます.
hprof-conv xxx.xxx.xxx.hprof xxx.xxx.xxx.hprof 変換後のhprofファイルはMATツールで開くことができます.
2、Android Studioの学生はMAT独立ソフトを使って開く
3、メモリの漏洩箇所を調べる
1つ目の方法:
1.Histogram図では、図のような位置入力でクエリーを行い、例えば:
activity with incominng referencesを選択し、そのようなオブジェクト参照を持つ外部オブジェクトを分析する 2、with incoming referencesを選択して下図に入り、これらの参照を持つオブジェクトのGCパスを分析します.図中のサブメニューの2つのオプションは、Phantom Ref(虚参照)とWeak Ref(弱参照)を除去することを示しています.理由はここを参照してください. 3、各オブジェクトのGCパスが正常かどうかを1つずつ分析する
このパスから、antiRadiationUtilツールクラスオブジェクトがMainActivityの参照を持っているため、MainActivityが解放されないことがわかります.この時点でコード解析に進むantiRadiationUtilのリファレンスの持ち方が妥当かどうか(antiRaditionUtilがMainActivityのcontextを持っていると番組終了後にMainActivityが破棄できなくなり、メモリリークになるのが一般的です).
2つ目の方法:
あるオブジェクトに漏洩が疑われた場合,OQLによりさらに証明することができる.OQLは、クラスのインスタンス情報をクエリーすることを主に使用する構文をクエリーすることで、特定のオブジェクト情報をクエリーできます.構文:
select * from instanceof Class
， com.yunos.tv.launchersdk.view.component.ScreenContainer ：
select * from instanceof com.yunos.tv.launchersdk.view.component.ScreenContainer結果は図のようになります.
Class Name
Shallow Heap
Retained Heap
com.yunos.tv.launchersdk.view.component.ScreenContainer @ 0x443108e8
680
2,712
com.yunos.tv.launchersdk.view.component.ScreenContainer @ 0x42817648
680
16,289,472
図中説明com.yunos.tv.launchersdk.view.component.ScreenContainerクラスには2つのインスタンスがあり、2つのインスタンスが消費するメモリサイズはそれぞれ2712と16289472です.インスタンスの数が予想を超えている場合は、メモリ漏洩があることを示します.インスタンスが予想を超えている場合は、インスタンス内の参照に問題があることを示し、インスタンスの詳細をさらに分析できます.
ここでメモリ漏洩の原因と解決方法について詳しく説明します.
MATは操作前後のhprofと比較してメモリ漏洩の原因を特定する
メモリリークを検出するには、通常2つのDump結果を比較してNavigator Historyパネルを開き、2つのテーブルのHistogram結果をCompare Basketに追加します.
1.最初のHPROFファイル(usingFile>Open Heap Dump).
2、Histograviewを開きます.
3、NavigationHistory view(見えない場合はWindow>show view>MAT-Navigation History)でhistogramを右クリックしてAdd to Compare Basketを選択する.
4、2番目のHPROFファイルを開き、手順2と3をやり直します.
5、Compare Basket viewに切り替え、Compare the Results(右上の赤を表示!)アイコンをクリックします.
6、比較結果の分析
2つのhprofのデータオブジェクトの比較結果がわかります.これにより、操作前後に保持されるオブジェクトの増分を迅速に位置決めすることができ、現在の操作によるメモリ漏洩の具体的な原因は、どのようなデータオブジェクトが漏洩したのかをさらに特定することができる.
転載:https://mp.weixin.qq.com/s?__biz=MzA3NTYzODYzMg==&mid=400891536&idx=1&sn=0b6c629b0abe4a359d6552cd244c0c0c&scene=1&srcid=0303pbuNmzzdPnwQLozLrMip&pass_ticket=8HY76%2FaZXUVizdmMUJA7KW40UY8GIW54Sj85H1PLcNuzGxmipJ36D7AsqXOA%2BdRb#rd http://www.jianshu.com/p/d8e247b1e7b2#
私の公衆番号に注目して、もっと多くの技術を簡単に理解して勉強します.