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 難しいです(>_<)。

openssl-1.0.0g 備忘録

VC9 x64 環境で試してみました。コンパイルするのに perl が必要なので ActivePerl x64版 をダウンロードしてインストールします。面倒なんで perl はパスに追加しておくようにします。 openssl-1.0.0g をダウンロードして解凍します。後は、INSTALL.X64に書いてあるとおりに進めます。

C:\>cd \libs\openssl-1.0.0g
C:\libs\openssl-1.0.0g>perl Configure VC-WIN64A
C:\libs\openssl-1.0.0g>ms\do_win64a
C:\libs\openssl-1.0.0g>nmake -f ms\ntdll.mak

特にはまりどころも無く構築できます。せっかくなんでテストしましょう。

C:\libs\openssl-1.0.0g>cd out32dll
C:\libs\openssl-1.0.0g\out32dll>..\ms\test

と、すんなりいけました。 このままでは、利用できないので、インストールします

C:\libs\openssl-1.0.0g>nmake -f ms\ntdll.mak install

これで、c:\usr\local\ssl というディレクトリにインストールされます。

zlib-1.2.6 備忘録

今回は、VC9 の x64 環境で構築してみた。 まず、zlib-1.2.6 をダウンロードし、解凍する。 Visual Studio 20XX x64 WIN64 コマンドプロンプトを開いて

C:\>cd \Libs\zlib-1.2.6
C:\libs\zlib-1.2.6>nmake -f win32\makefile.vc

たったコレだけの呪文でＯＫです。 念のために、テストもしてみましょうか？

C:\libs\zlib-1.2.6>nmake -f win32\makefile.vc test

ハマリどころも無く、簡単ですね？

android TableLayout のデザイン時における肝 備忘録

かなりイラッときたので、忘れないように、ここに記しておく。

• TableLayout には、android:shrinkColumns="0" を指定せよ
• レイアウトを整えるのは、 android:layout_span="n" を活用せよ

以上、これだけです。
　だいたいデザイン時には、うざいので XML を直接編集してます。感覚的には HTML の Table をレイアウトするのに慣れている人が多いと思います。android:shrinkColumns="0" を指定しなかったら、もうカオスです。例え１行しか無くても、android:layout_width は、丸無視されます。TableLayout 様が御乱心されて、手に負えません。これを指定しなくても良いのは、列数が２までです。

2012/10/11 追記: よくある入力フォームで、１列目に「項目名」、２列目以後にテキスト入力項目等を配置しており、その中の EditText に入力される文字列が長すぎると、EditText が間延びしていき、結果的に「項目名」の列を駆逐して、レイアウトがガタガタになりました。 このような場合には android:shrinkColumns を消して、android:stretchColumns="1,2,3" というように２列目以後の長さを調整するように設定するで、対応しました。

devfestx sapporo 2012 に参加した

非常に濃い２日間で、楽しかったです。特に Google の山崎さんは、フットワークが軽く、にこやかで、なるほど...グーグルが悪に感じるのは、きっと我々が悪だからなんだwww と、妙に納得した次第です。基本的にスピーカーの方々は、根明で謙虚で自分なりの価値観を持っている印象で、素晴らしかったと思います。１日目のハンズオンでは、Google Apps Script が大変勉強になりました。学習曲線で負荷のかかる場所と言えば、とっかかりの部分か、本格的にツッコミはじめる部分だと思うのですが、みんなで「わいわい」と手を動かしてコードを組むというのは、とても良かったです。MSオフィスのマクロみたいな事ができるらしいぐらいの知識しか無く、ドキュメントを開いて、コピーして、コピーしたドキュメントに対して正規表現で置換をかけてPDFに保存して電子メールで送信するなんて事ができるんだなーとわかった時は、ちょっと感動しました。Hangouts API で遊ぼうのセッションでは、Google Maps API のエキスパートの石丸さんとペアで、日頃から購読している Web OS Goodies の伊藤さんから手ほどきを受けるという、たぶん豪華なハンズオン。消化不良気味でしたが、普段は使った事のない Google Console とか使えて世界が広がった気がします。 　懇親会では、江川さんと足立さんに挟まれて、江川さんには「雪明かりの路」が良いですよと、オススメしたものの、日曜日の夜に家族で小樽まで出かけたら吹雪いていて遭難しそうになりました。もし、小樽に行かれてたとしたら、ごめんなさいです。足立さんも、後から考えてみればG＋で「Simeji」が買収されたという話が持ち切りだったので、もうちょっと自分の方でもピンと来てれば、もっと話が広がったかなーと反省してます。 　当初 Android のハンズオンを受けようかと思っていたんですが、ここんところ仕事で Android 漬けなんで、すんません、お腹いっぱいで受ける気力が起きなかったです。どっちにしろ、WebGL のセッションだけは、どうしても興味があったので、結果は変わらなかったとは思います。WebGL は独学ではきついなぁと感じていたので、情報が聞けて凄い良かったです。 　Google Maps のセッションで Fusion Tables というものがあるのは、知りませんでした。これで地図を描画できるようになったのは、何時からなんでしょうか？2010年の４月には、C++で ダイレクトに図形を描画してタイル化する PHP Extension (Closed source) を自分で作成してます。Google Maps API は使いこなせば凄いんでしょうけど、自分の会社はGISをやってて対局にあるので、ちょっと距離を置いて見てしまうところがありました。Fusion Tables は、ちょっと癪に障るから、もっと違うもん考えよっ。 　心残りは、GAE のハンズオンを受けれなかった事。 　抽選会では、初音ミクの「ねんどろいど」当たりましたwww。クリプトンフューチャーの皆様、ありがとうございました。 　今回の貴重な資料は　https://sites.google.com/site/devfestxsapporo/document　にあります。 　それから、ちょっと今、仕事がツボっていて書く暇がないですが、Zeemote というコントローラをもらったので、Android における Bluetooth 接続 のポストを書くかもしれません。多分、この辺に関する、まとまった情報はネット上にも無いと思います。

android における sqlite3 のスレッドによるアクセス

SQLiteOpenHelper を利用していて、IlligalStateException みたいなものに出くわしたので、スレッドによるアクセスは？データベースのインスタンスは？と、気になり、結局ソースコードを追った。ぐぐって見つけたのは、「SQLiteを使う場合の注意点」で、ここに書いてある事は概ね正しいです。 　SQLiteOpenHelper.java にて SQLiteDatabase は、mDatabase というメンバ変数に保持しているので、1クラスにつき、１インスタンスしか扱えません。
データベースに対しては、読み書きを行うでしょうから、getWritableDatabase 関数をコールして、内部で保持しているデータベースのインスタンスを取得する事になります。スレッドで読取り専用であっても、データベースは、DBOpenHelperに対して、ひとつのインスタンスなのでしょうがないです。内部のコードを追っていると、DBOpenHelper::getReadableDatabase 関数の中から DBOpenHelper::getWritableDatabase をコールしている場所があるので、現時点では、あまり違いは無いかもしれません。ただし、現在どっちのモード（読取り専用かどうか）でデータベースを開いているかは、内部で管理しているみたいで、整合性が合わないと、IlligalStateException がスローされます。
カーソルを作成すると、データベースの読取領域がメモリ上に読み込まれる感じになるので、この同じデータベース・インスタンスに対して、別スレッドから同時アクセスしても、そんなに大きな問題にはならないでしょう。ただし、これが可能なのは、１つの書き手と残りは複数の読み手に限られます。書き込みトランザクション中に別スレッドから読取操作が行われながらトランザクションが完了するので、非常に気持ちの悪い動作になります。よって、常識的にコードを書くならば、スレッド１個に対してDBOpenHelperのインスタンスを１つ用意すべきでしょう。そうすれば、読取り専用と書き込みの区別もできます。
　あと、この辺の情報を検索していて、データベースを開いた状態でメンバ変数に保持する事や、カーソルを開いたままメンバ変数に保持するのは、ご法度だみたいな事を書いている人もいるみたいですが、これは間違いです。Android では、デバイスから得られる情報を取得するためのイベント・リスナ中の関数は、別スレッドになるので、ここら辺を意識できないでコードを組む人には、そのような説明をした方が都合が良いからだと思われます。

最近読んで、良かった本

「ビッグデータ・ビジネスの時代」 北海道だと、まだまだIT化さえ進んでいない所が多いというのに、第１段階目のIT化されているレベル、第２段階目のIT化によってデータが集積できているレベル、第３段階目の集積されたデータを活用できているレベル、このうちの３段目のレベルのお話です。ほんの１年前までは、NoSQLやHadoopなんて、ちょっと毛色の変わった人の話という感じでした。しかし、最近では頻繁に、これらの事例を目にするように（ウェブ上）なりました。うちの社長には、ビッグデータ・ビジネスは、うちの会社のビジネスじゃないだろ・・・という風に言われました。半分は当たってますが、今から念頭に置いておかないと浦島太郎になりそうです。本書を読んで、そう思いました。この本を読む前から、データ実証主義の行き着く先は、この辺になるだろうから、どこかでビッグデータを取り扱う話にぶち当たる予感はありました。
「グレイトフル・デッドにマーケティングを学ぶ」いやいや、凄いビジネス書です。万人にわかりやすく書かれていて、素晴らしい。今の時代のビジネスの本質をついてると思います。