我想更好地理解NotificationListenerService。我创建了一个NotificationListenerService，用于监听通知（到目前为止效果很好）。
我的理解是，该服务将绑定到系统服务，并且基本上它将一直在后台运行，当然，仅在通知发生更改时才调用其方法。 所以我以为我会很“聪明”，并且由于我们不能再在清单文件中使用隐式意图过滤器了，所以我将在这里注册过滤器，例如：
static PlayBackQue playbackQue=new PlayBackQue();
.................................................
IntentFilter filter = new IntentFilter ();
filter.addAction ("android.app.action.ENTER_CAR_MODE");
filter.addAction ("android.app.action.EXIT_CAR_MODE");
registerReceiver(playbackQue,filter);
但是，我确实发现NotificationListenerService实际上确实调用了onDestory方法，并且日志抱怨泄漏（因为我实际上并未注销注册侦听器）。
我的接收器继续正常工作，但是我有信心这不好。
我很难完全理解NotificationListenerService的确切生命周期。
如果系统服务对扩展了NotificationListenerService的类的引用，也可以安全地假定它也对静态变量进行引用，在这种情况下，我的广播接收器将被记住？
我知道我可以（也许应该）创建前台服务，但是我的应用仍然需要访问通知，因此我想避免运行另一个前馈服务，仅实现2个intentfilters。遗憾的是，Google已从隐式过滤器列表中删除了CAR模式过滤器，并且目前尚没有真正的方法来检测手机何时处于汽车模式。 Job Scheduler不是一个真正的选择，因为它不能保证立即运行，也没有适当的时间表可以使用。...
答案 0 :(得分：0)
NotificationListenerService生命周期以onListenerConnected（）开始，以onListenerDisconnected（）结束。连接后注册接收机，断开连接后注销，应该是安全的。我对PlayBackQue接收器了解不多，但是使用静态变量通常不是一个好主意。最好使其成为服务的实例变量。连接服务后，您可以假定系统将保留对它的引用。断开连接后，您将无法对此进行任何假设，也就不需要任何静态变量。除非您需要该接收器坚持下去，否则在这种情况下它可能不属于NotificationListenerService。
答案 1 :(得分：-1)
最安全的做法是 -在通知侦听器服务的onCreate（）函数中调用registerReceiver（） -在noticationListenerService的onDestroy（）函数中调用unregisterReceived（）。
我过去曾经这样做过，该应用程序正常运行，没有任何泄漏。