Android 4.0のサービス／プロセス間通信の基本：Androidで動く携帯Javaアプリ作成入門（31）（1/3 ページ）

[緒方聡，株式会社イーフロー]

Android 4.0の「サービス」の深淵へ

　いまから約3年前、本連載の第7回「常駐アプリが作成できるAndroidの“サービス”とは」で、Androidの「サービス」を取り上げました。あれから月日も経過してAndroidのバージョンも上がり、一部のメソッドが非推奨になるなどの変更もあったので、今回あらためて「サービス」を取り上げることにします。

　第7回では、「Android Interface Definition Language（AIDL）」を必要としない「ローカルサービス」にのみ着目しましたが、今回はAIDLを使用するプロセス間通信に焦点を当ててサービスを解説します。

　今回のサンプルは以下よりダウンロード可能です。

• CalculatorService.zip

Android 4.0のサービスの2つのライフサイクル

　API Level 15（Android 4.0.3）時点で、サービスのライフサイクルは以下のようになっています。

図　サービスのライフサイクル

　上図のとおり、単にサービスを起動する「Context#startService(Intent)」と、サービスにバインドして「プロセス間通信」（IPC：Inter Process Communication）によるリモートメソッドコールを行う「Context#bindService(Inetnt, ServiceConnection, int)」では、ライフサイクルに関するコールバックメソッドが若干異なります。

　それぞれのライフサイクルに関して説明していきます。

startService()によるサービス生成時のライフサイクル

　　サービスはActivityとは異なり、同一のサービスが複数起動することはありません。起動していない状態から「startService()」を呼び出すと、「onCreate()」が呼び出されます。もし、対象のサービスがすでに起動している場合は、onCreate()は呼び出されません。

注意！ 起動処理「onStart()」はAPI Level 5から非推奨なので「onStartCommand()」を

　続いて「onStart()」または「onStartCommand()」が呼び出されます。onStart()はAPI Level 5から非推奨になり、onStartCommand()を使用するように推奨されています。

　もし、onStart()がオーバーライドされていてonStartCommand()がオーバーライドされていない場合は、onStart()が呼び出されますが、onStart()とonStartCommand()の両方がオーバーライドされている場合は、onStartCommand()のみが呼び出されます。

　ここは特殊な動作なので、古いサービスをメンテナンスする際には気を付けてください。API Level 5以降を対象に新しくサービスを実装する場合はonStartCommand()をオーバーライドするようにしましょう。

onStartCommand()の戻り値

　onStartCommand()はonStart()とは異なり戻り値を返します。以下のいずれかを返すことでサービスの挙動を決められます。

戻り値	説明
START_NOT_STICKY	サービスが強制終了した場合、サービスは再起動しない
START_STICKY	サービスが強制終了した場合、サービスは再起動するonStartCommand()が再度呼び出され、Intentにnullが渡される
START_REDELIVER_INTENT	サービスが強制終了した場合、サービスは再起動するonStartCommand()が再度呼び出され、Intentに直前のものが渡される

　いずれのケースでも、サービスに渡されるべきInetntがまだ渡されていない状態で残っている場合でサービスが強制終了された場合は、初回起動と同様にサービスが起動します。

　どのようなケースでどの戻り値を使用するのが適切であるか、というのは一概にはいえませんが、サービスのクライアントがstartService()でのみサービスに指示を出します。

　例えば、以下のようにToastを表示するサービスの場合は「START_NOT_STICKY」が使えます。

Androidアプリ作成の基本“Activity”とは何か？ (2/2) - ＠IT via kwout

　また、キッチンタイマーのようなサービスで、セットされた時刻をストレージなどに保持しているのであれば「START_STICKY」が使えます。キッチンタイマーで、呼び出し元からタイマー時間ではなくセットされた時刻が渡されるのであれば「START_REDELIVER_INTENT」を使うといいでしょう。

　サービスの性質によって、どの戻り値を使用するべきであるかはよく検討してください。

コラム　IntentServiceクラスとは

内部にワーカースレッドを持ち、「startService()」で渡されたIntentを1つずつ処理することを容易にする「IntentService」というクラスもあります。

このクラスを使う際は、「onStartCommand()」はオーバーライドしてはならず、代わりに「onHandleIntent(Intent)」を実装します。IntentServiceについては、次回詳しく解説します。

終了処理

　サービスは基本的にバックグラウンドでずっと動作し続けます。サービスを終了するには、「Context#stopService(Intent)」「Service#stopSelf()」「Service#stopSelf(int)」「Service#stopSelfResult(int)」のいずれかを呼び出します。

　stopService()はstartService()に渡したIntentと同じものを指定します。stopSelf(int)とstopSelfResult(int)は、onStart()またはonStartCommand()で渡された「startId」を指定します。

　もしstopSelf()でstartIdを指定せずにサービスを終了しようとして、同じタイミングでstartService()を呼び出してしまったら、startService()が処理できなくなってしまいます。そうした事態を避けるためにstopSelf()に最新のstartIdを渡すことで、同時にstartService()が呼び出された場合にそのstartIdを比較して、サービスの終了処理を行わないようにします。また、同時に呼び出されたstartService()を処理できます。stopSelfResult()は、サービスを終了できたかどうかの戻り値を受け取れます。

　サービスを終了することが大事なのか、サービスを終了するようなタイミングで呼び出されたstartService()を処理することが大事なのかで、サービス自身の停止方法が変わってきます。

　サービスが停止する前に、onDestroy()が呼び出されます。onCreate()でリソースを確保したなら、onDestroy()でリソースを解放します。

　bindService()のライフサイクルの説明に入る前に、次ページでは、AIDLおよびParcelについて解説します。