独自のプロセスでサービスを実行しています。夕方には問題ないように見えますが、寝た後は、Androidが斧を持っていると思います.
onDestroy()
Android がサービスを強制終了したときに呼び出されないと考えるのは正しいですか? そうでない場合、キルが登録されている他の場所はありますか?
を研究する必要があると思いますAlarmManager
。
独自のプロセスでサービスを実行しています。夕方には問題ないように見えますが、寝た後は、Androidが斧を持っていると思います.
onDestroy()
Android がサービスを強制終了したときに呼び出されないと考えるのは正しいですか? そうでない場合、キルが登録されている他の場所はありますか?
を研究する必要があると思いますAlarmManager
。
独自のプロセスでサービスを実行しています。
なぜそれは独自のプロセスにあるのですか?
Android がサービスを強制終了したときに onDestroy() が呼び出されないと考えるのは正しいですか?
そうかもしれないし、そうじゃないかもしれない。
そうでない場合、キルが登録されている他の場所はありますか?
いいえ。
AlarmManager を調査する必要があると思います。
ユーザーは永遠に存続するサービスを嫌います。そのため、タスク キラーが人気があります。彼らは独自のプロセスで実行されるサービスをさらに嫌います。通常は正当な理由もなく余分な RAM、CPU、およびバッテリーを消費するからです。
あなたの目的が定期的に何かをすることである場合は、使用してくださいAlarmManager
- それがそこにある理由です。
開発者ドキュメントのサービス ライフサイクルに従って、サービスonDestroy()
が強制終了または停止されると、メソッドが呼び出されます。
また、アプリがバックグラウンドで実行されているサービス (つまり、バックグラウンドで再生されている音楽プレーヤー) を持っている場合、システムはアプリがアクティブであると見なし、極端な条件を除いてそのプロセスを強制終了しません (私はそれが起こるとは思わない練習)。
ドキュメントには次のように記載されています。
Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service. An important consequence of this is that if you implement onStartCommand() to schedule work to be done asynchronously or in another thread, then you may want to use START_FLAG_REDELIVERY to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it.
ここで私が考えているのは、サービスが os によって強制終了された場合、os は後でサービスを再起動しようとするということです。しかし、この場合、onDestroy() メソッドが呼び出されますか?よくわかりません。誰かがこれについてテストしましたか?