Androidでのサービスの実装START_STICKY
との違いは何START_NOT_STICKY
ですか?誰かがいくつかの標準的な例を指摘できますか?
Androidでのサービスの実装START_STICKY
との違いは何START_NOT_STICKY
ですか?誰かがいくつかの標準的な例を指摘できますか?
回答:
どちらのコードも、電話がメモリ不足になり、実行が完了する前にサービスを強制終了した場合にのみ関係します。 START_STICKY
十分なメモリを確保してからサービスを再作成onStartCommand()
し、nullインテントで再度呼び出すようにOSに指示します。START_NOT_STICKY
サービスを再作成する手間を省くようにOSに指示します。START_REDELIVER_INTENT
OSにサービスを再作成し、同じインテントをに再配信するように指示する3番目のコードもありonStartCommand()
ます。
Dianne Hackbornによるこの記事は、公式文書よりもはるかに優れた背景を説明しています。
ソース:http : //android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html
ここで重要な部分は、関数によって返される新しい結果コードであり、サービスの実行中にプロセスが強制終了された場合にサービスで何を実行する必要があるかをシステムに通知します。
START_STICKYは基本的に以前の動作と同じです。サービスは「開始」されたままで、後でシステムによって再起動されます。以前のバージョンのプラットフォームとの唯一の違いは、プロセスが強制終了されたために再起動された場合、サービスが呼び出されずに、サービスの次のインスタンスでonStartCommand()がnullインテントで呼び出されることです。このモードを使用するサービスは、常にこのケースをチェックして適切に処理する必要があります。
START_NOT_STICKYは、onStartCreated()から戻った後、配信する開始コマンドが残っていない状態でプロセスが強制終了された場合、サービスは再起動されずに停止されることを示しています。これは、送信されたコマンドの実行中にのみ実行することを目的としたサービスにとって、はるかに意味があります。たとえば、ネットワーク状態をポーリングするために、アラームから15分ごとにサービスが開始される場合があります。その作業中にそれが殺された場合は、それを停止させ、次にアラームが発生したときに開始するのが最善です。
START_REDELIVER_INTENTはSTART_NOT_STICKYに似ていますが、サービスのプロセスが特定のインテントに対してstopSelf()を呼び出す前に強制終了された場合を除き、そのインテントは完了するまで再配信されます。その時点でシステムはあきらめます)。これは、実行する作業のコマンドを受信し、送信された各コマンドの作業を最終的に完了することを確認したいサービスに役立ちます。
START_NOT_STICKY
ですか?
START_REDELIVER_INTENT
のようなものですSTART_NOT_STICKY
。代わりにSTART_STICKY
差:
システムは強制終了された後、サービスを再作成しようとします
システムは強制終了された後、サービスを再作成しようとしません
標準的な例:
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
return START_STICKY;
}
START_REDELIVER_INTENT
。START_STICKY
最近のアプリでテストし、アプリを強制終了しました。その後、サービスをリコールします。しかし、START_REDELIVER_INTENT
二度と呼ばれることはありません。どうして?
ドキュメントSTART_STICKY
とはSTART_NOT_STICKY
非常に簡単です。
このサービスのプロセスが開始中に強制終了された場合(から戻った後
onStartCommand(Intent, int, int))
、開始された状態のままにしておきますが、この配信されたインテントは保持しません。後でシステムがサービスを再作成しようとします。開始された状態であるため、onStartCommand(Intent, int, int)
新しいサービスインスタンスの作成後に呼び出されることが保証されます。サービスに配信される保留中の開始コマンドがない場合は、nullインテントオブジェクトで呼び出されるため、これを確認する必要があります。このモードは、バックグラウンドミュージックの再生を実行するサービスなど、明示的に開始および停止して任意の期間実行するものに適しています。
このサービスのプロセスが
onStartCommand(Intent, int, int))
開始中に強制終了された場合(から戻った後、サービスに配信する新しい開始インテントがない場合)、サービスを開始状態から解除し、将来の明示的な呼び出しまで再作成しませんContext.startService(Intent)
。サービスとのonStartCommand(Intent, int, int)
電話を受けませんnull
配信する保留中のインテントがない場合インテントは再起動されないためインテント。このモードは、開始された結果としていくつかの作業を実行したい場合に意味がありますが、メモリの負荷がかかっているときに停止でき、後で明示的に開始してさらに作業を行います。このようなサービスの例としては、サーバーからのデータをポーリングするサービスがあります。アラームに
N
サービスを開始させることにより、毎分ポーリングするようにアラームをスケジュールできます。そのをするときonStartCommand(Intent, int, int)
、それは新しい後でN分のアラーム、およびスポーンそのネットワーキングを行うには、スレッドのスケジュール、アラームから呼び出されます。そのチェック中にプロセスが強制終了された場合、アラームが鳴るまでサービスは再開されません。