BroadcastReceiver 和 IntentService 的职责重叠
Overlap in the responsibilities of BroadcastReceiver and IntentService
BroadcastReceiver 和 IntentService 的职责有一些重叠是否正确？也就是说，我的意思是设置一个 BroadcastReceiver 来触发一个 IntentService 来执行一些需要完成的任务是多余的。由于两者都响应意图，因此仅让 IntentService 直接响应意图而无需 BroadcastReceiver 作为中介会更简单。
这个解释正确吗？它总是正确的吗？如果不是，请举例说明何时不正确。
非常感谢！
I mean that it would be redundant to set up a BroadcastReceiver that triggers an IntentService that performs some task that needs to be done
这不仅不一定是多余的，而且是一种非常常见的模式。
Is this interpretation correct?
没有
please give an examples of when it's incorrect.
Intent 与 sendBroadcast() 或 startService() 一起使用。如果 Intent 与 sendBroadcast() 一起使用，则服务无法直接响应它。类似地，如果 Intent 与 startService() 一起使用，则接收者不可能直接响应它。因此，在其他人编写代码以使用 Intent 的情况下，您必须与他们的使用方式相匹配。您不能单方面 "change the channel" 使用 Intent。
除此之外，BroadcastReceiver 的 onReceive() 始终在主应用程序线程上调用。你不想在这里花费任何有意义的时间，因为如果你的 UI 恰好在前台，它会冻结你的 UI。并且，一旦 onReceive() returns，一个 manifest-registered 接收者的实例被丢弃，您的进程可能会在此后不久终止。因此，BroadcastReceiver 派生其自己的后台线程是不安全的，因为 Android 将忽略该线程并终止您的进程。响应 system-sent 广播的常见模式是使用 BroadcastReceiver，然后将工作委托给 IntentService。一举解决两个问题：
IntentService 在 onHandleIntent() 中完成繁重的工作，在后台线程上调用 - 因为它是一个
Service，所以在执行该工作时使用它 运行 将向 OS 发出信号，让您的进程多活一会儿
现在，如果您是创建 Intent 的人并且您是调度 Intent 的人并且您是消费 Intent 的人，并且您希望拥有自己的代码直接使用 startService() 来调用一个 IntentService，完全没问题。
BroadcastReceiver 和 IntentService 的职责有一些重叠是否正确？也就是说，我的意思是设置一个 BroadcastReceiver 来触发一个 IntentService 来执行一些需要完成的任务是多余的。由于两者都响应意图，因此仅让 IntentService 直接响应意图而无需 BroadcastReceiver 作为中介会更简单。
这个解释正确吗？它总是正确的吗？如果不是，请举例说明何时不正确。
非常感谢！
I mean that it would be redundant to set up a BroadcastReceiver that triggers an IntentService that performs some task that needs to be done
这不仅不一定是多余的，而且是一种非常常见的模式。
Is this interpretation correct?
没有
please give an examples of when it's incorrect.
Intent 与 sendBroadcast() 或 startService() 一起使用。如果 Intent 与 sendBroadcast() 一起使用，则服务无法直接响应它。类似地，如果 Intent 与 startService() 一起使用，则接收者不可能直接响应它。因此，在其他人编写代码以使用 Intent 的情况下，您必须与他们的使用方式相匹配。您不能单方面 "change the channel" 使用 Intent。
除此之外，BroadcastReceiver 的 onReceive() 始终在主应用程序线程上调用。你不想在这里花费任何有意义的时间，因为如果你的 UI 恰好在前台，它会冻结你的 UI。并且，一旦 onReceive() returns，一个 manifest-registered 接收者的实例被丢弃，您的进程可能会在此后不久终止。因此，BroadcastReceiver 派生其自己的后台线程是不安全的，因为 Android 将忽略该线程并终止您的进程。响应 system-sent 广播的常见模式是使用 BroadcastReceiver，然后将工作委托给 IntentService。一举解决两个问题：
IntentService在onHandleIntent()中完成繁重的工作，在后台线程上调用- 因为它是一个
Service，所以在执行该工作时使用它 运行 将向 OS 发出信号，让您的进程多活一会儿
现在，如果您是创建 Intent 的人并且您是调度 Intent 的人并且您是消费 Intent 的人，并且您希望拥有自己的代码直接使用 startService() 来调用一个 IntentService，完全没问题。