OutOfMemoryError 避けが悪影響だけ出している

第 1 章駄目コードとその対策 6

1.11 OutOfMemoryError 避けが悪影響だけ出している

ServiceCon-nection

のリークに繋がります。この例では

Service

^を

bind/unbind

^{するタイミングは}

on-Start()/onStop()

を使用していますが、

onCreate()/onDestroy()

や

onPause()/onResume()

など、

Activity

のライフサイクル上で必ず通る組み合わせを使用するとリークを回避すること

ができます。

Eclipse

の場合、このプラグインをインストールすると、

DDMS

^{パースペクティブの}

Dump

HPROF file

ボタンを押すとダンプしたメモリを解析できるようになります。

図1.2 Dump HPROF file^ボタン

たとえば次のような無駄に大きな

byte

^{配列をもつ}

Activity

の解析をしてみましょう。メンバ変数として

16MB

^の

byte

配列を保持しています。

リスト1.34: LargeBytesActivity.java

public class LargeBytesActivity extends ActionBarActivity { private byte[] mLargeBytes = new byte[16 * 1024 * 1024];

@Override

protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

} }

この

16MB

^の

byte

配列をメモリリークの原因ということにして、

MAT

^{を使って追ってみ} ましょう。

まず最初に

Dump HPROF file

ボタンを押します。すると図

1.3

のような画面が表示されます。この画面ではおおよそメモリを大きく使用しているクラスが何であるのかが円グラフで表示されます。

図1.3 Memory Analyzerの初期表示

今回はメモリを大きく保持しているクラスが何であるかを確認したいので、ヒストグラムを表示します。ヒストグラムを表示するには図

1.4

のヒストグラムのボタンを押します。

図1.4 Create a histogram^ボタン

すると図

1.5

のように、各クラスのインスタンスの数と、どれだけメモリを占有しているかが表示されます。今回の場合では

byte

配列が一番大きくメモリを占有しているのがわかります。

図1.5 Histogram

次に

byte

配列のインスタンスを個別に見てみましょう。図

1.6

のように右クリックのメニューの

List objects

からインスタンスの一覧を表示できます。

図1.6 List objects

リストの

Retained Heap

^{で並べ替えると図}

1.7

^{のように一番大きい、}

16MB

^の

byte

^配列を見つけることができました。

図1.7 16MBのbyte配列

次にこの

byte

配列はどこから参照されているのか、そしてなぜ

GC

^{によって回収されない} のかを調べます。調べるには右クリックのメニューから

Path to GC Roots

を選択することで解析できます。

図1.8 Path to GC Roots

解析結果は図

1.9

のようになります。するとこの

16MB

の

byte

配列は、

mLargeBytes

という変数名で

LargeBytesActivity

というクラスが保持していることまで特定できました。

図1.9 ^{リーク原因の特定}