在服務中註冊SCREEN_ON/SCREEN_OFF的廣播接收器

Question

有人可以確認我是否遵循了所需功能的正確設計？

我需要通過廣播接收機聽兩種意圖的時候，我的應用程序是至少一次的設備，不能在AndroidManifest登記上運行：

• android.intent.action.SCREEN_ON
• android.intent.action.SCREEN_OFF

因爲這個原因，我創建了一個服務，當我的MainActivity啓動時啓動。 Withing服務的方法onStartCommand我註冊這些廣播接收器...

這些廣播接收機有做基於從SharedPreferences 0（什麼都不做）或1邁出了標誌的一些東西中下（做正確的邏輯）

我是否正確地拒絕服務的生命週期，即使MainActivity將不會被停止/殺死（認定它不會導致任何設備干擾和重載），即使MainActivity也會從內存/堆棧中移除並且意圖會聽取？

Answer 1

有幾件事情：

• 註冊接收器在服務的onCreate()替代，因爲在創建服務的這種方法只調用一次。如果多次撥打startService()，則會導致更多撥打onStartCommand()，這意味着您不斷重新制作接收器。

注意，要Context.startService多次調用（）不窩（雖然 它們導致對onStartCommand（）多次調用對應的），所以 無論多少次啓動的服務會一旦調用了Context.stopService（）或stopSelf（），就會停止 ;

• 確保取消註冊Receivers。我通常做這onDestroy()

此外，關於你的生命週期的問題 - 提供正常的服務應該不是沒有理由被打死，應該啓動它的活動獨立運行（綁定服務是有點從我還記得什麼不同）但它仍然在UI線程和相同的進程中運行（除非另有說明）。但是，如果很長一段時間過去了，您的服務不在前臺。它有可能被殺死。這就是爲什麼你應該讓onStartCommand()返回START_STICKY。如果系統確實終止了服務，那麼它會重新啓動服務。如果你的服務處於前臺，你的服務也可能會被殺死，但這是最後一招。如果你的服務很容易出錯，START_STICKY可能會很糟糕。例如，我的服務不斷崩潰。 START_STICKY使它在一段時間後重新啓動，然後再次墜毀，循環重複。

唯一的時間爲您服務是在正常情況下被殺害的安全是這些：

如果該服務目前正在執行其的onCreate（）， onStartCommand（），或的onDestroy（）方法的代碼，那麼主機進程 將成爲前臺進程，以確保該代碼可以在不被 殺死的情況下執行。