android 開発におけるメモリーリーク 備忘録

いやー、android 開発、難しいですねー。嵌りました。罠に…。 どんな罠か？って言うと、 Androidのソースコードレビュー(メモリリーク)に書いてあるような罠に、はまりました。気が付いたのは、BitmapFactory.decodeResource という関数をコールしている所で、OutOfMemoryException が発生するのが、きっかけでした。色々と探っていくと、自分で確保した Bitmap は、自前で recycle をしないといけないらしい事も、わかってきました。てっきり、GC の対象だと思っていたんですが…。コードまで追ってないので、本当のところは、わかりません。 　さて、android のAPIには、Context を引数にとるものが多数存在します。この Context に渡すのは、どの context なのか？気になりますよね？ getApplicationContext() で全部処理できれば万歳なんでしょうけど、終了確認のダイアログを出すときに、getApplicationContext()を引数として渡すと、お亡くなりになりました。いやー難しいですねー。 　ふと思ったのは、Activity が Context を継承している設計は、失敗だったんじゃないでしょうか？という事です。

 interface ISecurityContext {
  Context getContext();
 }

 class Activity ... implements ISecurityContext {
   private Context mContext_;

   public Context getContext() { return mContext_; }
   ...
 }

こんな風に設計されていれば、循環参照でActivityがメモリリークする事も無かったのではないでしょうか？ あと、自前でコードから生成した View には onDetachedFromWindow とかのイベント発生しないようで、クリーンナップのコードも自前でコールしないといけないんでしょうか？ 　Java の GC は、とっても安全ですね。android 難しいです(>_<)。