JAVA(Android)のメモリ管理
Activity : Context -> Viewの関係ははっきりした。Acvitityを保持しているのは?プロセスそのものだけか?それ以外の参照はない?Activityがいるときに自身の別のActivityを立ち上げた場合は別プロセス?違うよな。サービスは別プロセスだが。
2011-09-18 17:30:36http://t.co/jvhuzN7i ここを見てる感じだと恐ろしく大変なわけだ。一つわかったのはApplicationのほうがActivityより長生きする。Applicationは複数のActivityより参照できるから、やはりその辺は俺のイメージ通りかな
2011-09-18 17:34:53やっぱりこのActivityがviewを参照する、viewはContextとしてActivityを参照する相互参照がデフォルトで存在する状態はクソだと思うんだけれどなぁ。そこにどこか一つ外部からの参照が加わると即座にActivity一つ分メモリリークするんだもん
2011-09-18 17:36:16ダメだ、勉強すればするほどAndroidのメモリ管理は致命的にクソという結論になってしまう。まずnewするとクソ遅いからstaticにしましょう(これはGoogle自身が言ってる、http://t.co/SRH9ZeKT )。そうすっとstaticなインスタンスがいくつも出来る。
2011-09-18 17:39:56staticは基本永続する。で、このstaticなインスタンスが何かの間違いでActivityかViewの一部をつかんでしまうと、そのActivity一つ分丸ごとメモリリークする。http://t.co/jvhuzN7i 特にViewだけが再生成されるタイミングが超危険。
2011-09-18 17:41:21従ってActivityかViewが死ぬタイミングで適切にstaticな変数を解放してね、と。でもどこで何をつかんでるかはブラックボックスだよ(はあと)である。さっき出したDrawableの例は顕著。要するにクソ。
2011-09-18 17:42:11つーかnewするのが遅いから避けろってのが一番頭悪い気がしてならない。それって要するにObj-Cにたとえるなら全部グローバルにインスタンス持っておけっているような物でしてええ
2011-09-18 17:44:07適切なタイミングで生成して殺す、というオブジェクトのライフタイムを実現するのが一番良いプログラミングであって、それを制約するようなのを推奨するってのはどういう理由があったとしても俺は許容できないね。つーか遅いとか言い訳するならJava採用すんじゃねえよ。
2011-09-18 17:45:16なんかすっきりしない結論だ。だんだんAndroidがPHP見たいに見えてきてしまっていて良くない
2011-09-18 17:45:41でもせっかくだから一度はTweetした内容を上げておこう。 "純粋JavaじゃなくてActivityとかIntentが内部C実装になってる時点から全ての制約がキテルので、あいつのJavaは記法だけJavaっていう結論は1年前に出てるはずだよ。"
2011-09-18 17:47:06クライアントアプリで、オブジェクトのライフタイムを自然で簡単に記述できないと、相当難易度上がって、複雑なアプリを構築できなくなると思うんだけれどなぁ。
2011-09-18 17:47:15@toru_inoue 記法だけJavaなのはいいんですけど、オブジェクトのライフタイムの管理ぐらい簡単にさせろ、と思うわけです。
2011-09-18 17:48:10だいぶ前にコケにしたときよりさらにまじめに勉強して考えてみたのだがやはり同じ結論になってしまったのがどうにもかなしい
2011-09-18 17:49:08@toru_inoue 多分一年前に同じことやってますよw 今再度見直してみてもやっぱり同じだったとw
2011-09-18 17:50:40でも一つ勉強になったぞ、一対一の通知の仕組みに関しては今のところ問題ない。ただしライフタイムは気をつけないとダメ。と。
2011-09-18 17:53:06NSNotification兼NSOperationみたいな実装になってるように見えるな。NSOperation的なのは、runnableを渡して別スレッドでどうぞみたいな。NSNotification的なのは、Messageを現スレッドのHandlerに渡して・・・みたいな
2011-09-18 18:02:33