总是创建一个服务的每个广播接收器？

Question

我观察到的一个模式，所有BroadcastReceiver不得不随之创建一个Service。我同意，长时间运行过程中需要service。

有没有在所有service创建BroadcastReceiver任何好处和使用BroadcastReceiver只是接收广播将它传递给service？

它是好的运行在BroadcastReceiver本身不复杂的操作/任务？任何缺点或任何反模式？

Answer 1

当使用BroadcastReceivers，这真的取决于真实需要做的工作量。

如果工作是足够的光线，可以在10秒内完成，则这是正常的，从的onReceive（）方法直接运行它。对于轻体力劳动，如这些，它意义不大启动服务只是为了轻松地完成这项工作。

这里只有3做广播接收器的内部工作真正的危险：

• 在后台线程做的工作可能会导致所有工作完成之前被杀害的广播接收器。一旦达到onReceive()结束时，广播接收器的过程中会被认为是一个低优先级的进程，所以如果系统需要它它可能被杀死。因此，在后台做的工作可能会导致工作无法正常完成这是相当危险的，如果你将数据插入到数据库中。
• 在主线程执行工作，以避免达到onReceive()结束。我见过开发商这样做是为了打击之前的问题，这会导致由于潜在的做在主线程的工作太多了性能问题。我敢肯定，你知道为什么这是一件坏事。
• 做太多的工作，超过10秒钟即可将导致系统考虑您的应用程序不响应的。

当然，你其实可以请求延长后台工作有点通过goAsync()方法的限制，但是这不是你应该使用的，而不是服务的方法。

因此，与我提到的那些3分的危险，这是有道理的，为什么做更多的工作流行的解决方案是将工作传递给适当的服务或的jobscheduler。

所以，这真的取决于你来决定哪些是最适合你的使用情况。

1. 如果工作真的很轻，有与从事的工作在广播接收器没有问题。
2. 如果工作很轻，但数据是非常重要的，不能冒险，然后再考虑在服务这样做。
3. 如果工作繁重，绝对做到这一点通过服务或安排其作为的jobscheduler工作。

但说实话，我一般建议是谨慎地使用BroadcastReceivers。只有当它是必要的，因为有太多的注册BroadcastReceivers服务会影响您的应用程序的性能使用。