Serviceの使いどころ？

放置状態になってたブログを再開、、、してみます。

Serviceについて、ちょっと考えていることを。

AndroidのServiceは、UI Threadを固めないように、時間のかかる処理を別のスレッドに分けるものです。
なのですが、深く考えずに「時間かかりそうだしな」とアプリのモジュールにServiceを使うと、よろしくないようで、、、痛い目見ました。

「アプリケーションの終了が、Serviceの終了ではない＝常駐させたい」場合以外は、使わないほうが良さそうです。

理由、というか、実際にハマったところですが

1． 競合制御
所詮スレッドであるため、Serviceのインスタンスに対して、通常のメソッド呼び出し、データ読み書きが出来ちゃう。
当然、Serviceの他に、Activityなど別スレッドもいるため、それぞれからのアクセスに対して競合制御が必要になる。

2． パフォーマンス
1．を回避するために手っ取り早いのはHandlerやAIDLを使うこと。
本来はこれが正しい使い方だと思うけど、Serviceへのアクセスがシリアライズしちゃう。
パフォーマンス的に懸念があるシチュエーションがある。

3． AIDLでも
AIDLなら、シリアライズを多少回避できるけど(oneway option)、競合制御の設計をしなきゃいけないのは1と同じ。

4． Serviceのライフサイクル管理
値読みたいだけなのにいちいちServiceへのBindとかめんどくさい^^;
Bindすることで、ライフサイクルを気を付けないと、勝手にDestroyしたり、しなかったりするし。

UI Threadを固めないようにするなら、ThreadやAsync Threadの方が手軽で、「スレッド化したい機能」を
Classとして独立させされるので、その方がいいのかなーと思ってます。ライフサイクル管理も簡単。

ということで、作成中のアプリで見事に↑で困ったので、SingletonなClass + Threadで、再設計中。
別のアプリでも、Serviceなしで新規設計してみてます。

まぁ、「ちゃんと設計しろよ」というだけかもしれないですが、、、