検索
連載

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

PC用表示 関連情報
Share
Tweet
LINE
Hatena

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

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

 第7回では、「Android Interface Definition LanguageAIDL)」を必要としない「ローカルサービス」にのみ着目しましたが、今回は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.

ページトップに戻る