JAVA(Android)のメモリ管理

@akisutesama さんのJAVAのメモリ管理を理解する行程が非常にいいと感じたので、残しておきます。
20
akisute/Masashi Ono @akisutesama

どっかにないかなー。うーん。

2011-09-18 17:28:14
akisute/Masashi Ono @akisutesama

Activity : Context -> Viewの関係ははっきりした。Acvitityを保持しているのは?プロセスそのものだけか?それ以外の参照はない?Activityがいるときに自身の別のActivityを立ち上げた場合は別プロセス?違うよな。サービスは別プロセスだが。

2011-09-18 17:30:36
akisute/Masashi Ono @akisutesama

この辺のまとめでいい奴どっかにないのー><

2011-09-18 17:30:59
akisute/Masashi Ono @akisutesama

http://t.co/jvhuzN7i ここを見てる感じだと恐ろしく大変なわけだ。一つわかったのはApplicationのほうがActivityより長生きする。Applicationは複数のActivityより参照できるから、やはりその辺は俺のイメージ通りかな

2011-09-18 17:34:53
akisute/Masashi Ono @akisutesama

やっぱりこのActivityがviewを参照する、viewはContextとしてActivityを参照する相互参照がデフォルトで存在する状態はクソだと思うんだけれどなぁ。そこにどこか一つ外部からの参照が加わると即座にActivity一つ分メモリリークするんだもん

2011-09-18 17:36:16
akisute/Masashi Ono @akisutesama

ダメだ、勉強すればするほどAndroidのメモリ管理は致命的にクソという結論になってしまう。まずnewするとクソ遅いからstaticにしましょう(これはGoogle自身が言ってる、http://t.co/SRH9ZeKT )。そうすっとstaticなインスタンスがいくつも出来る。

2011-09-18 17:39:56
akisute/Masashi Ono @akisutesama

staticは基本永続する。で、このstaticなインスタンスが何かの間違いでActivityかViewの一部をつかんでしまうと、そのActivity一つ分丸ごとメモリリークする。http://t.co/jvhuzN7i 特にViewだけが再生成されるタイミングが超危険。

2011-09-18 17:41:21
akisute/Masashi Ono @akisutesama

従ってActivityかViewが死ぬタイミングで適切にstaticな変数を解放してね、と。でもどこで何をつかんでるかはブラックボックスだよ(はあと)である。さっき出したDrawableの例は顕著。要するにクソ。

2011-09-18 17:42:11
akisute/Masashi Ono @akisutesama

やっぱりダメだ。クソという結論になった。どっか間違ってる?

2011-09-18 17:42:31
akisute/Masashi Ono @akisutesama

つーかnewするのが遅いから避けろってのが一番頭悪い気がしてならない。それって要するにObj-Cにたとえるなら全部グローバルにインスタンス持っておけっているような物でしてええ

2011-09-18 17:44:07
akisute/Masashi Ono @akisutesama

適切なタイミングで生成して殺す、というオブジェクトのライフタイムを実現するのが一番良いプログラミングであって、それを制約するようなのを推奨するってのはどういう理由があったとしても俺は許容できないね。つーか遅いとか言い訳するならJava採用すんじゃねえよ。

2011-09-18 17:45:16
akisute/Masashi Ono @akisutesama

なんかすっきりしない結論だ。だんだんAndroidがPHP見たいに見えてきてしまっていて良くない

2011-09-18 17:45:41
殺意駆動開発 @toru_inoue

でもせっかくだから一度はTweetした内容を上げておこう。 "純粋JavaじゃなくてActivityとかIntentが内部C実装になってる時点から全ての制約がキテルので、あいつのJavaは記法だけJavaっていう結論は1年前に出てるはずだよ。"

2011-09-18 17:47:06
akisute/Masashi Ono @akisutesama

クライアントアプリで、オブジェクトのライフタイムを自然で簡単に記述できないと、相当難易度上がって、複雑なアプリを構築できなくなると思うんだけれどなぁ。

2011-09-18 17:47:15
akisute/Masashi Ono @akisutesama

@toru_inoue 記法だけJavaなのはいいんですけど、オブジェクトのライフタイムの管理ぐらい簡単にさせろ、と思うわけです。

2011-09-18 17:48:10
AKIRA_TRYSTAR @AKIRA_TRYSTAR

@akisutesama そうすると、NDKで実装するのが良い…という方向になるかもですね。

2011-09-18 17:49:05
akisute/Masashi Ono @akisutesama

だいぶ前にコケにしたときよりさらにまじめに勉強して考えてみたのだがやはり同じ結論になってしまったのがどうにもかなしい

2011-09-18 17:49:08
akisute/Masashi Ono @akisutesama

まぁGoogleの言うことなんぞ無視してnewすりゃいいか。最近はハードウェアも速いしね。

2011-09-18 17:49:42
殺意駆動開発 @toru_inoue

@akisutesama むお、なんかデジャヴュw ダルビックだからね、、

2011-09-18 17:50:14
akisute/Masashi Ono @akisutesama

@toru_inoue 多分一年前に同じことやってますよw 今再度見直してみてもやっぱり同じだったとw

2011-09-18 17:50:40
akisute/Masashi Ono @akisutesama

でも一つ勉強になったぞ、一対一の通知の仕組みに関しては今のところ問題ない。ただしライフタイムは気をつけないとダメ。と。

2011-09-18 17:53:06
akisute/Masashi Ono @akisutesama

一対多と多対多について勉強しよう。

2011-09-18 17:53:12
akisute/Masashi Ono @akisutesama

お、あったあった。android.os.HnadlerとかMessageとか。これ棚多分

2011-09-18 17:56:47
akisute/Masashi Ono @akisutesama

NSNotification兼NSOperationみたいな実装になってるように見えるな。NSOperation的なのは、runnableを渡して別スレッドでどうぞみたいな。NSNotification的なのは、Messageを現スレッドのHandlerに渡して・・・みたいな

2011-09-18 18:02:33