理解できない
- START_STICKY、
- START_NOT_STICKY と
- START_REDELIVER_INTENT
誰でも例を挙げて明確に説明できますか。
このリンクをたどりましたが、はっきりと理解できませんでした。
理解できない
誰でも例を挙げて明確に説明できますか。
このリンクをたどりましたが、はっきりと理解できませんでした。
これらはサービスに関連しています。サービスがバックグラウンドで実行され続け、実行のためにメモリも消費することは誰もが知っています。
そのため、より多くのアプリケーションが Android デバイスで実行されると、デバイスのメモリが少なくなり続け、デバイスのメモリが非常に少なくなると、Android システムはプロセスの終了を開始し、プロセスによって占有されているメモリを解放します。 .
ただし、サービスを使用していくつかの重要なタスクを実行している可能性があり、サービスが停止すると終了する可能性もあります。したがって、これらの概念は、デバイスのメモリが安定し、サービスを再起動する準備ができたときに実行するアクションを Android システムに伝えることです。
これらの最も簡単な説明は、
START_STICKY-
メモリ不足から回復した後、十分なメモリが利用可能になったときに、サービスの新しいコピーを作成するようにシステムに指示します。ここでは、以前に計算された可能性のある結果が失われます。
START_NOT_STICKY-
十分なメモリがある場合でも、サービスを再起動しないようにシステムに指示します。
START_REDELIVER_INTENT-
クラッシュ後にサービスを再起動し、クラッシュ時に存在していたインテントを再配信するようにシステムに指示します。
さて、私はあなたのリンクのスレッドを読みました、そしてそれはそれをすべて言います.
メモリ不足のためにサービスが Android によって強制終了され、Android が一部のメモリをクリアすると、...
onStartCommand()
ます。これもフラグのためです。両方のコードは、電話がメモリ不足になり、実行が完了する前にサービスを強制終了した場合にのみ関連します。START_STICKY は、十分なメモリが確保された後にサービスを再作成し、null インテントで onStartCommand() を再度呼び出すよう OS に指示します。START_NOT_STICKY は、サービスを再作成する手間を省くよう OS に指示します。また、OS にサービスを再作成し、onStartCommand() に同じインテントを再配信するように指示する 3 つ目のコード START_REDELIVER_INTENT もあります。
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() を呼び出す前にサービスのプロセスが強制終了された場合、そのインテントは完了するまで再配信されます (さらに何回か試行しても完了できない場合を除き、その時点でシステムはあきらめます)。これは、実行する作業のコマンドを受信し、送信された各コマンドの作業を最終的に完了することを確認したいサービスに役立ちます。