如何从 IntentService 与当时可能未运行的 Activity 进行通信？

Question

我的活动（称为 A）启动 IntentService（称为 IS）作为更大任务（称为 T）中的一个步骤。 IS 可能运行一个小时或更长时间；当它完成时，它必须以某种方式告诉 A，以便 A 可以在任务 T 中执行下一步。但是，当 IS 完成时，用户可能已经做了很多事情，包括完全杀死 A。然而，当用户重启它时，A必须意识到IS已经完成，这样A才能进行任务T的下一步。

关于如何从 IS 到 A 的通信有很多建议：Intent、PendingIntent、Broadcast and Receiver、ResultReceiver、Messenger 线程等。[我没有提供链接，因为简单的搜索会显示它们。]但所有假设 A在发送消息时处于活动状态。看来 IS 根本无法向死去的 A 发送消息。

或者可以吗？

SharedPreferences 可能是将消息从 IS 持久化到 A 的方式。当它完成时，IS 在 SharedPreferences 中设置标志 F。现在 F 是持久的，即使在设置 F 时 A 已死。当用户重新启动A时，它会检查F。如果设置了F，A就知道IS完成了，现在A可以进行任务T的下一步了。

此外，如果 A 有一个 SharedPreferences Listener，那么 IS 可以向 A 发出 A 是死是活的信号； IS 根本不需要其他通信方式。

事实上，SharedPreferences 侦听器似乎是沟通和协调的最佳方式，只要消息只是偶尔的和简短的。

这有意义吗？ SharedPreferences 不是为消息传递而设计的，所以我担心一些隐藏的后果。你怎么看？

Answer 1

似乎 IS 根本无法向死掉的 A 发送消息。

正确。您可以使用事件总线发布 A 可以接收的事件，如果 A 没有接收它，您可以保留详细信息以供 A 稍后查找。

我在这些示例应用中演示了基本事件总线“UI 或后备”模式，用于：

• greenrobot's EventBus 2.x
• LocalBroadcastManager
• Square's Otto

就我而言，后备行为是提出Notification，但这不是必需的。

SharedPreferences 不是为消息传递而设计的，所以我担心一些隐藏的后果

一个是性能。 SharedPreferences 总是执行磁盘 I/O。对于没有正在运行的 A 实例的情况，可以使用它作为后备。一直使用它并不理想。

还要注意，在这里使用SharedPreferences 并没有什么神奇之处。任何形式的持久性都可以工作（例如，数据库、其他类型的文件）。特别是如果可能有几条来自 IS 的消息需要排队，我会考虑使用Tape。