在服务中为SCREEN_ON / SCREEN_OFF注册广播接收器

Question

有人可以确认我是否遵循了所需功能的正确设计？

当我的应用程序至少在设备上运行一次时，我需要通过广播接收器侦听两种类型的意图，这些意图无法在AndroidManifest中注册：

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

出于这个原因，我创建了一个服务，该服务在我的MainActivity启动时启动。 使用服务的方法onStartCommand我注册这些广播接收器......

接下来在这些广播接收器中，根据从SharedPreferences取得的标志做了一些事情：0（不做任何事）或1（做适当的逻辑）

我是否正确地解决了服务的生命周期，它不会被Android停止/杀死（确认它不会导致任何设备干扰和过载），即使MainActivity将从内存/堆栈中删除，意图将在听吗？

Answer 1

一些事情：

• 在服务的onCreate()中注册接收者，因为此方法仅在创建服务时调用一次。如果您多次拨打startService()，会导致对onStartCommand()的更多通话，这意味着您不断重新制作接收器。

  

请注意，对Context.startService（）的多次调用不会嵌套（但是   它们会导致对onStartCommand（）的多次相应调用，   所以无论启动多少次，服务都会停止   一旦调用了Context.stopService（）或stopSelf（）;

• 确保取消注册您的接收器。我通常在onDestroy()
中执行此操作

此外，关于你的生活问题 - 一个正常的服务不应该没有理由被杀死，应该独立于启动它的Activity运行（绑定服务与我记忆的有点不同）但它仍然在UI线程和相同的过程（除非你另有说明）。但是，如果很长时间过去而您的服务不在前台。它有可能被杀死。这就是您应该onStartCommand()返回START_STICKY的原因。如果系统确实终止服务，则可以重启服务。如果你的服务在前台，你的服务也可能会被杀死，但这是最后的杀戮。如果您的服务容易出错，START_STICKY可能会很糟糕。例如，我的服务一直在崩溃。 START_STICKY稍后重启，然后再次崩溃，循环重复。

在正常情况下，您唯一能够安全地免受服务的是：

  

如果服务当前正在其onCreate（）中执行代码，   onStartCommand（）或onDestroy（）方法，然后是托管进程   将是一个前台进程，以确保此代码可以不执行   被杀了。