2011年6月5日日曜日

BroadcastReceiverとプロセスって

androidアプリでバッググラウンド処理でほげほげするには、サービスやら非同期タスクやらスレッドやらを使ったりしますよね。

常駐アプリを作ろうとすると、UIキックじゃなくて端末起動時などの状態変化時も考慮する必要が出てきます。
そこで用意されているBroadcastReceiverの話です。

BroadcastReceiverのonReceiveでブレークしっぱなしにしながらワンピースみてたらandroidに長すぎって怒られて強制終了しちゃいました。

確かにすっかりTV見てた俺が悪いのですが、そのときBroadcastReceiverキックの処理だけではなくUI操作側のアプリも閉じちゃいました。

あれ、プロセス一緒なの?と思ったのでプロセスIDを取得してみることにしたわけです。

プロセスIDはandroid.os.Process.myPid()なんてやると取れますね。

[結果]
UI側のPID
→25907
UIからキックしたサービスのPID
→25907
adbからのBOOT_COMPLETEDを受け取ったBroadcastReceiverのPID
→25907
BroadcastReceiverからキックしたサービスのPID
→25907

おお、全部一緒だ。
そういえばここここを見るとBroadcastReceiverは別プロセスにできるともあるな。

別プロセスにするメリットはなんだろう。
片方が死んでも、片方は生き残ること?

同一プロセスのメリットはなんだろう。
javaのsynchronizedで排他制御ができること?

性能を考えなければDBとPreference操作のためにsynchronizedでメソッド丸ごと排他すると楽チンだから同一プロセスのままにしておくのが良いかな。

0 件のコメント:

コメントを投稿