Android 4.0の「サービス」の深淵へ
いまから約3年前、本連載の第7回「常駐アプリが作成できるAndroidの“サービス”とは」で、Androidの「サービス」を取り上げました。あれから月日も経過してAndroidのバージョンも上がり、一部のメソッドが非推奨になるなどの変更もあったので、今回あらためて「サービス」を取り上げることにします。
第7回では、「Android Interface Definition Language（AIDL）」を必要としない「ローカルサービス」にのみ着目しましたが、今回はAIDLを使用するプロセス間通信に焦点を当ててサービスを解説します。
今回のサンプルは以下よりダウンロード可能です。
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」が使えます。
また、キッチンタイマーのようなサービスで、セットされた時刻をストレージなどに保持しているのであれば「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について解説します。
Copyright © ITmedia, Inc. All Rights Reserved.