深夜のAndroidメモリ管理TL

mhidaka@技術書典 @mhidaka

RT @youten_redo: 結局ぐぐって出てくるのがthrow Lifeというのがパネェ。http://www.adamrocker.com/blog/248/overview-of-the-dalviks-object-management.html

mhidaka@技術書典 @mhidaka

RT @youten_redo: 結局ぐぐって出てくるのがthrow Lifeというのがパネェ。http://www.adamrocker.com/blog/248/overview-of-the-dalviks-object-management.html

ひょろも @hyoromo

もしかしてAndroid上で System.gc() しても、明示的にGC起こさせない設定になっててGC走ってくれないとか？

ひょろも @hyoromo

気のせいだった、ちゃんとしてくれてる。

mhidaka@技術書典 @mhidaka

あ、ついでなので混在しないように注釈しとくとBitmapImageのロード時はライブラリのSkia経由なのでVMHeapとは別にmallocしてます。オブジェクトはVMさん管理ですが、BitmapDataのメモリ確保はVMさん管理外です。

ひょろも @hyoromo

@mhidaka せんせい、つまり BitmapFactory.decodeResource でデコードする時にOOMが発生してる場合、VM外のメモリが足らないって事になるんですか？

mhidaka@技術書典 @mhidaka

@hyoromo VM外メモリ不足の可能性も高いと感じてます。decodeResource する際は瞬間的に読み込みたいBitmap以上のメモリを要求されてるんだと思います。

mhidaka@技術書典 @mhidaka

今ぼくのなかで疑問なのはBitmapFactory.decodeResourceされた画像データのメモリ確保がNDK経由なのでVMさん管理外なのは間違いなさそう。ということはVMHeapは早々消費されないはずなんだけど・・・経験的にはVMHeap足りてないよなぁ、です。

mhidaka@技術書典 @mhidaka

@keiji_ariyama あれ。1MBで開始してる風なコードですね。

ひょろも @hyoromo

@mhidaka ほうほう、なるほど。

ひょろも @hyoromo

何パターンかの実験コードを書いたお陰で、今抱えてるバグが解消できそうな気がしてきた。ちょーねむいから、もうねよう。

mhidaka@技術書典 @mhidaka

@keiji_ariyama VMのオプションで選べるみたいです。kMinHeapSizeはheapSizeMaxの下限マクロ、kMinHeapStartSizeは起動時のheapSizeStartの下限値マクロらしい。

ARIYAMA Keiji @keiji_ariyama

@mhidaka なんか、普通にコマンドラインでusageとか出るんですね。意外ー

mhidaka@技術書典 @mhidaka

デバッギングツールのDDMSなんかで見えるメモリ使用量はプロセスHeap単位だからVMHeapが消費されているのかどうかなんかわからない？ いや、でも詳しくメモリ確保の様子が分かるので、キチンと追えば解が見つかりそうな気がする

mhidaka@技術書典 @mhidaka

@keiji_ariyama dvmは、おもしろいつくりしてますねー。勉強になります。

mhidaka@技術書典 @mhidaka

なんか本来の調査方向と異なった調査になったがよくあること。（とても充実している）

mhidaka@技術書典 @mhidaka

そろそろEmbedded C++はC++で置き換わらないものか。

Makoto Nishikawa @mnishikawa

@mhidaka まだまだメモリの使い方決める要素と、Linuxから見る方法があります。いくつかヒントを教えれるので、気分転換に僕の席までどうぞー

Makoto Nishikawa @mnishikawa

@mhidaka DDMSで出てくるのはPSS(proportional set size，sharedを共有してるプロセスの平均メモリ＋private)だから、sharedをzygoteが抱えるAndroidでは参考程度に思っといた方がいいです。

Makoto Nishikawa @mnishikawa

@mhidaka /proc/${pid}/smaps 見たらわかる。