Bescottee » leak

メモリリークを発見！Androidアプリのメモリ解析手法　その２ OQL (Object Query Language)利用方法

admin — Thu, 18 Aug 2011 10:22:38 +0000

「メモリリークを発見！Androidアプリのメモリ解析手法」でEclipse Memory Analyzer(MAT)のインストール方法と使い方の紹介をしました。今回は、Eclipse Memory Analyzer (MAT)のさらに踏み込んだ使い方を紹介します。

Eclipse Memory Analyzer(MAT)のインストール方法

MATがまだインストールしていない場合は、以下の手順でインストールしてください。

Eclipseのメニューバーの（日本語化済みの場合）「ヘルプ」⇒「新規ソフトウェアのインストール」
- 作業対象：–すべての使用可能なサイト–
- フィルター入力：memory
Memory Analyzer (MAT)インストール画面
「Memory Analyzer」と「Memory Analyzer(Charts)[オプション]」にチェックをいれて、「次へ」を選択し、インストールを継続
まだ再起動せずに、続いて、「Memory Analyzer(Charts)[オプション]」で利用する図作成ライブラリ（BIRT)をインストール。これをいれておくとメモリ利用状況がMAT上で綺麗な図で表示されます。是非インストールしておきましょう。

Memory Analyzer Charts向け図作成ライブラリBIRTインストール
インストール後は、eclipse 再起動を求められるので、再起動しましょう。

OQL (Object Query Language)利用方法

Eclipse Memory Analyzer(MAT)には、以下の主要な機能があり、OQLはクラスオブジェクトの任意の抽出方法を定義でできるものです。

アクション
- ヒストグラム(Histgram)：クラスごとのインスタンス数を表示
- クラスオブジェクトごとの木構造(Dominator Tree)：もっとも大きなクラスとそれらの存在期間を表示
- 上位の消費者(Top Consumers)：クラスごととパッケージごとにもっともメモリを利用しているクラスを表示
- クラスの複製(Duplicate Classes)：複数のクラスローダからロードされているクラスを発見（レビューコメント頂いたkare様、ありがとうございました）
レポート
- メモリリーク予想(Leak Suspects)：メモリリークの予想とシステム概要をレポート
- 上位のコンポーネント(Leak Suspects)：全体のヒープの1%よりも大きなコンポーネントをレポートする機能
OQL (Object Query Language):は、Javaヒープの検索をするために利用できるＳＱＬのような問い合わせ言語です。OQLはJAVAヒープから必要な情報を選択したり、フィルターしたりすることができます。ＯＱＬは、JavaScrip埋め込み型言語（JavaScript Expression Language)をベースとしています。OQLのクエリー定義は以下のようなものです。
```
select 
   [ from [instanceof]  
   [ where  ] ]
```
class name にはフルパスの Javaクラス名（例えば、 java.lang.String）を指定します。

OQLは、以下のMATのメニューから選択できます。

Eclipse Memory Analyzer(MAT) OQL選択画面

OQLは特定のクラスオブジェクト検索を行えるものです。具体例として、100文字以上のString を保持しているオブジェクトを検索したい場合は以下のようなSQLに近いコマンドを実行します。OQLのテキストボックスに以下のコマンドを記載し、「！」ボタンをクリックすると実行されます。

Eclipse Memory Analyzer(MAT) OQL実行方法
```
SELECT s FROM java.lang.String s WHERE (s.count >= 100)
```
実行結果は以下のようになります。

Eclipse Memory Analyzer(MAT)のOQL実行結果

さらに、以下のようなクラスオブジェクトの中身の値も表示することができます。以下の例は、Fileオブジェクトの持っている path フィールドの中身の値を一覧で表示する例です。
```
select file.path.value.toString() from java.io.File file
```
実行結果は以下のようになります。

Eclipse Memory Analyzer(MAT) OQL実行例 Fileオブジェクトのpathを表示
```
SELECT cl FROM INSTANCEOF java.lang.ClassLoader cl
```
実行結果は以下のようになります。

Eclipse Memory Analyzer(MAT) OQL実行結果

プリミティブ配列を利用する場合は以下のように利用します。
```
select a from int[] a where a.length >= 256
```
Android的なOQLの利用方法

Android開発でOQLを利用する方法としては、まだ良いものは思いついていませんが１つ紹介します。

以下の例は、Activity を継承したクラスの一覧を表示するOQLです。いくつかの画面遷移を行うアプリの場合、ライフサイクルの管理をきちんと行っている前提で、画面遷移した直後やメモリを消費する処理を行った場合にヒープダンプを保存しておいて、後から以下のコメントでどのＡｃｔｉｖｉｔｙが残っているかを調査するのに役立ちます。
```
SELECT ac FROM INSTANCEOF android.app.Activity ac
```
今回のテストで利用したソースは以下です。ボタンを押すと、ActivityContextActivity⇒ActivityContext2Activity⇒ActivityContext3Activity ⇒ActivityContext4Activity の順番にActivityを立ち上げていくのみのサンプルで、ActivityContext4Activityまで画面遷移してから実行した結果です。
```
public class ActivityContextActivity extends Activity {

    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }

    public void onClickButton(View v) {
        Intent intent = new Intent(this, ActivityContext2Activity.class);
        startActivity(intent);
    }
}
```
```
	
```
OQLを利用してみた感想

javaの世界では一般的な本ツールも、Androidの世界ではまだ Memory Analyzer ですら利用されていない状況ですが、Eclipse を利用したAndroid開発を進めていくうえで、Eclipse で提供されている JAVA テクノロジーには大変良いものが多く、是非活用していきたいと思っています。OQL以外にもまだまだ利用できるものがありそうなので調べていきたいと思います。

Android開発でMemory Analyzer やOQLの便利使い方をご存じの方は是非コメント頂ければうれしいです。
このページを見た人は、以下のページも見ています。

メモリリークを発見！Androidアプリのメモリ解析手法

admin — Sun, 03 Apr 2011 04:50:19 +0000

googleのAndroid開発者向けブログに「Memory Analysis for Android Applications」という記事があったため、自分のために訳しました。参考になれば幸いです。本エントリを見るうえで、eclipse の基本的な使い方を理解している必要があります。

Androidアプリのメモリ解析手法

Dalvikランタイムは、ガベージコレクトしてくれるかもしれませんが、それはメモリ管理を行わなくてもよいというわけではありません。モバイル端末上でのメモリ利用状況は特に注意を払わなければなりません。本投稿では、開発するアプリのメモリ利用状況の把握を支援する Android SDK で提供しているメモリプロファイリングツール群のいくつかを紹介させて頂きます。

メモリ利用時の問題はいくつか明らかになっています。例えば、もしあなたのアプリがユーザの画面タッチ操作のたびにメモリリークするとすると、最終的には OutOfMemoryError のきっかけになる可能性が高いでしょう。他の問題はもっと複雑で、（あなたのアプリがガベージコレクトが頻繁に発生し、かつ長い時間発生すると）そのアプリと全体のシステムの両方のパフォーマンスを下げる原因になるかもしれません。

解析・分析のためのツール

Android SDK はアプリのメモリ利用状況をプロファイリングする手法として、2つの方法を提供します。DDMSの”Allocation Tracker”タブとヒープダンプです(heap dums)。Allocation Tracker は、与えられた時間間隔の中で発生しているメモリ割り当ての種類を知りたいときに便利です。Allocation Trackerについてもっと情報が必要な場合は、Tracking Memory Allocations を見てください。
しかし、それらはアプリケーションヒープの概要の状態に関する情報しか提供されません。本投稿の趣旨は、より強力なメモリ解析・分析のツールであるヒープの表示（dump）にフォーカスをあてていく予定です。

ヒープダンプは、HPROF と言われているバイナリフォーマットの形式で保存されるスナップショット（ある瞬間の情報（点としての情報））です。Dalvik は似たようなフォーマットを利用しますが、java の HPROF Toolとまったく同じではありません。実行中のAndroidアプリのヒープダンプを生成するいくつかの方法があります。１つは DDMS の HPROF ファイルに保存する機能です。もし、あなたがもっと正確にダンプを作成したいときはandroid.os.Debug.dumpHprofData() メソッドを利用してプログラム上からヒープダンプを作成することもできます。

ヒープダンプを解析するために、jhatやEclipse Memory Analyzer (MAT)のような一般的なツールも利用できます。
しなしながら、最初に .hprof(拡張子）ファイルを Dalvik フォーマットから J2SE HPROF フォーマットに変換する必要がでてきます。
そのためにAndroid SDK の中で提供されている hprof-conv ツールを利用できます。

たとえば、

hprof-conv dump.hprof converted-dump.hprof

というコマンドで実行できます。

例：メモリリークをデバッグする

Dalvikランタイムの中で、プログラマは明示的にフリーなメモリを割り当てることはできません、そのため　C や C++ の言語のように本当にメモリがリークしているかどうかを知ることができません。

ソースコード上にある”メモリリーク”は、不必要に長い間オブジェクトを参照し続けた場合に発生します。たまに単一参照（single reference)は、大きな（大量な）オブジェクト群のガベージコレクタの実行を妨げることができます。

Android SDKの中にある Honeycomb の Gallary Sample アプリを利用して、実例を用いて理解していきましょう。これは新しいHoneycomb API群のいくつかの使い方を知るためのシンプルな写真閲覧アプリです。

ビルド方法とサンプルコードのダウンロード方法は、手順書(Android 開発者サイトのサンプルの取得方法）をご覧ください。

どのようにデバッグできるかの手法を紹介するためにこのアプリに故意にメモリリークを追加しました。

ネットワーク上から画像を取得するために、このアプリを修正したいと考えてみてください。よりレスポンスをよくするために、最近閲覧した画像を保持するキャッシュの実装を決めたとします。 ContentFragmen.java ファイルにいくつかの小さな変更を行ってみましょう。クラスの上部に新しいスタティック変数を追加しましょう。

private static HashMap sBitmapCache = new HashMap();

これは、ネットワークからロードするビットマップ群のキャッシュです。続いて updateContentAndRecycleBitmap() メソッドをネットワークからロードする前にキャッシュに存在するかどうかの確認を行うために変更し、ロード後にキャッシュにビットマップを追加します。

    void updateContentAndRecycleBitmap(int category, int position) {
        if (mCurrentActionMode != null) {
            mCurrentActionMode.finish();
        }

        // 描画するためのビットマップを取得し、ImageViewを更新

        // キャッシュにビットマップが存在するかどうかを確認
        String bitmapId = "" + category + "." + position;
        mBitmap = sBitmapCache.get(bitmapId);

        if (mBitmap == null) {
            // キャッシュにない場合、ビットマップをロードし、キャッシュに追加
            // 危険・注意！ 常にビットマップを削除することなしにキャッシュにアイテムを追加
            mBitmap = Directory.getCategory(category).getEntry(position)
                .getBitmap(getResources());
            sBitmapCache.put(bitmapId, mBitmap);
        }
        ((ImageView) getView().findViewById(R.id.image)).setImageBitmap(mBitmap);
    }

私はここで故意にいれたメモリリークを紹介します。常にキャッシュを削除することなしにビットマップをキャッシュに追加します。実際にアプリでこのような実装する場合は、いくつかの方法でキャッシュサイズに制限をかけたいを考えるでしょう。

DDMSを利用してヒープの利用状況を確認

Dalvik Debug Monitor Server (DDMS) は、主要なAndroidデバッグツールの１つです。DDMSは ADT Eclupse プラグインの一部で、単体動作版はAndroid SDKの tools/ ディレクトリの中にあります。DDMSに関する情報をもっと知りたい場合は、DDMSを利用してみましょう。

それでは、このアプリのヒープ利用状況を確認するためにDDMSを利用しましょう。DDMSを起動する方法は2つあり、そのどちらでも起動できます。

Eclipse上からメニューバーを以下の順序で選択する方法

Windows > Open Perspective > Other … > DDMS

コマンドライン上から tools/ ディレクトリの中にある ddms を起動する。

（追記：Windowsの場合は、ddms.bat が起動され、Mac/Linux の場合は、ddmsが起動される。（それぞれに PATH を通している必要があります））

左のパネルからcom.example.android.hcgalleryプロセスを選択して、ツールバー上の”Show heap updates”ボタンをクリックします。
それから DDMS の VM Heap タブに切り替えます。

ヒープメモリ利用状況について GC毎に更新されるいくつかの基本情報が見れます。最初の更新を行うために、”Cause GC”ボタンをクリックします。

我々は live setという（割り当てメモリ列）8MBを少し超えるものをみることができます。サンプルアプリの写真をフリックすると、数字が増加していくのが見れます。このアプリは13枚の写真しかありませんが、リークしたメモリの容量が割り当てられていきます。このような場合リークの最悪のパターンが訪れます。しかしながら我々は決してリークすることにより OutOfMemoryError を起こしてはいけません。

ヒープダンプ(heap dumps)を作成

問題を追うためにヒープダンプを作ってみましょう。DDMSツールバーのDump HPRPF fileボタンをクリックして、保存場所を選択して、それから hprof-conv でコンバートしてください。この例では、MAT(Ver 1.0.1)のスタンドアローンバージョン(Stand alone version)を利用しています。これはMATダウンロードサイトで提供されています。

もし、ADT(DDMSのプラグインの親元)が実行している場合や Eclipse に MAT がインストールされている場合は、”dump HPROF”ボタンを押すと自動的にコンバート（hprof-convを実行）してくれ、Eclipse内（MATでオープンされる）で変換された hprof ファイルを開いてくれます。

MATを利用したヒープダンプの解析・分析

MATを実行し、いま先ほど作成したコンバート済みの HPROF ファイルをロードしてください。（上記のように必要なツールがインストールされていれば、自動的にコンバートとMAT起動を行ってくれます）。MATは強力なツールですべての機能を説明するためには本投稿の範囲を超えてしまいます。そのためいまはリークを発見するために利用する１つの方法として、Histogram View（ヒストグラムビュー）を紹介します。ヒストグラムビューはインスタンスの数でソートされたクラスのリストと表面上のヒープ（表層ヒープ：shallow heap）（すべてのインスタンスで利用しているメモリの総合計）と保持されたヒープ（保持ヒープ：retained heap）（他のオブジェクトへの参照をもっているオブジェクトを含めたすべてのインスタンスで生きているメモリの総合計）を表示します。

もし shallow heap でソートすれば、byte配列のインスタンスが上部に表示されます。Android 3.0(ハニカム）の場合、ビットマップオブジェクトのピクセルデータは byte配列に保存されます。（以前は Dalvik heap に保存されませんでした）
そして、それらのオブジェクトのサイズを参考にして、メモリリークしたビットマップのための裏にあるメモリだと賭けても(bet)あっている(safe)でしょう。

byte[] クラス上で右クリックで押して、
List Objects → incoming references
を選択します。これは、ヒープの中に byte 配列のすべてをリストで表示したもので、Shallow Heapの利用状況をベースにソートすることのできます。

大きなオブジェクトの一つを選び、ドリルダウンしていきましょう。これは、オブジェクトのrootからの path を見せてくれます。生存しているオブジェクト参照のつながりを表しています。ほら、我々のビットマップキャッシュがありますね。

MATはこれがリークかどうかを教えてはくれません。なぜなら、それが必要なものか、そうでないかがわからないためです。それはプログラマのみができることなのです。今回の場合、キャッシュは比較的アプリの休憩中（ユーザが操作していない場合）にメモリの大きな容量を使っています。そのためキャッシュのサイズの上限を検討しないといけません。

MATでヒープダンプを比較

メモリリークをデバッグしているとき、2つの異なったポイントのヒープ利用状況を比較すると、とても有益です。それを行うために、2つの異なる HPRPOF ファイルを作成する必要があります。（hprof-convを使ってコンバートは忘れずに！）

では、ここでどうやって MAT で2つのヒープダンプを比較すればよいかをお伝えします。（少し重ねればよいのです）

最初のHPROFファイルを開く（Fie > Open Heap Dump)
ヒストグラムビュー(Histogram view)を開く
Navigation History view（eclipe のメニューのWindow > Navigation History。なければ Window > Other… > Memory Analyzer Views < Navigation Historyで選択）の中の histogram を選択し、右クリックして「Add to Compare Basket」を選ぶ
2つ目の HPROF ファイルをステップ2と3を繰り返してください
「Compare Basket view」に切り替えて、Compare the Results（Compare Basket viewの上部の右上にある赤い！アイコン）をクリック

結論

本投稿ではどのように allocation Tracker とヒープダンプ(heap dumps)はアプリのメモリ利用状況のよりより見え方・感じ方を得るための方法を紹介しました。私はまたどのよに Eclipse Memory Analyzer(MAT) がアプリのメモリリークを追う方法を紹介しました。MATは強力なツールであり、私もこのツールで何ができるかの表面しか紹介しませんでした。

もしあなたがよりもっと学びたいとお考えなら、以下のURLのいくつかを読むことをお勧めします。

Memory Analyzer News（英語）
- Eclipse MAT プロジェクトの公式ブログ

Markus Kohler’s Java Performance blog（英語）
- 多くの役に立ち記事があります。ここには Eclipse Memory Analyzer を利用したAndroidアプリのメモリ利用分析があったり、Eclipse Memory Analyzerのための10個の役に立つ開発術があります。

メモリリークを避けるためにお薦め本

Effective Java 第2版

まだお持ちでないなら、メモリリークを避けるためにも必読です。

増補改訂版Java言語で学ぶデザインパターン入門

先人の知恵であるパターンを利用することによって大幅にメモリリークを避けられるようになります。

増補改訂版 Java言語で学ぶデザインパターン入門マルチスレッド編

マルチスレッド環境ではメモリリークが発生しやすくなります。マルチスレッドを扱う場合は必読です。