使用Kotlin Coroutines代替LocalBroadcastManager进行Firebase消息传递

Question

在Android上使用Firebase Cloud Messaging时，通常希望将Activity传入的推送通知通知当前。推荐的一种方法是使用LocalBroadcastManager来将实现Intent从FirebaseMessagingService实现发送到Activity（StackOverflow示例答案）。

但是，从1.1.0-alpha01（2018-12-17）版本开始，LocalBroadcastManager不推荐使用：

LocalBroadcastManager是应用程序范围的事件总线，在您的应用程序中包含违反层的行为：任何组件都可以侦听其他任何事件。您可以LocalBroadcastManager用其他可观察模式的实现方式代替的用法，具体取决于您的用例，这些选项可能是LiveData或响应流。

尽管此类很可能会保留更长的时间，但我还是想开始清理我们的应用程序，因此我想迁移到更好的方法，然后Google真正删除旧方法。

目前，这些本地广播在我们的应用程序中具有两个主要角色：

1. 使用来自推送通知的新数据更新UI。这种工作方式是，每个Activity关心传入推送数据的人都有一个广播接收器，该接收器侦听适当的消息并更新其自己的视图数据。
2. 如果服务器发送结束会话的通知，则强制用户注销。这适用于每个活动都有广播接收器实例的实例，该实例侦听注销事件，结束该活动，然后启动“登录”活动。

如我所见，这些用例在两个建议的替代方案上都有问题：

• LiveData最容易用于Activity或Fragment作为的一部分ViewModel。但是，ViewModel只能用于直接处理UI的那些类。从架构ViewModel内部访问FirebaseMessagingService会带来丑陋的结果，从架构的角度来看，这确实是一个坏主意。另外，不同的活动和片段具有不同的ViewModel对象，我不希望该服务需要访问它们全部。
• 我可以创建object具有一系列LiveData属性的Kotlin （又称Singleton），从传入消息中FirebaseMessagingService更新这些LiveData对象，并Activity观察这些更改并将其复制到其自己ViewModel的LiveData属性中。问题是双重的：首先，它要求我LiveData为每个数据块拥有两个相同的对象，一个在中ViewModel，一个在中object；第二，它对处理“注销事件”没有帮助，因为LiveData它是用来处理变化的数据，而不是侦听事件流。（我也许可以使用“ LiveData事件包装器”处理第二个问题，但是对于那些本来无法正常工作的东西来说，这仍然感觉很糟糕。）
• 尽管响应流（例如RxJava）可能会满足我的需要，但我已经迫使我的团队在过去的几个月中学习Kotlin，Android Databinding，Android ViewModel以及许多其他新东西，但我认为它们并不可能需要更多。RxJava只是为此用途而增加的一件大事，并且我们没有计划重写整个应用程序以利用它来证明其增加的合理性。

我发现的一个建议是将Kotlin Coroutines与Channels或Flows一起使用。它们可以与响应流非常相似地使用，但是（与RxJava不同）旨在与Kotlin一起使用，并受益于Kotlin对Java的改进。由于Google宣布他们将重点放在Kotlin而不是Java上，因此该选项特别具有吸引力。

虽然在我看来这是最好的选择，但是我还没有从其他人那里获得任何反馈，有关它是否有效以及这种实现是否有副作用和/或陷阱。我发现的唯一问题是，在kotlinx.coroutines存储库中有一个开放的问题，即需要提供这样的应用程序示例。虽然我想贡献这样一个例子，但我认为我对它的了解还不足以创建一个很好的例子，并且我不希望我的生产应用程序成为豚鼠。我也不知道是否更好（或专有）使用显式couroutines用Channel或使用suspend与Flow这种情况。

综上所述：

• 是科特林协同程序及其相关并发结构的好办法到Android之间的手柄通信Service和Activity？
• 如果是的话，这科特林类型更有意义的使用，Channel或Flow？

Answer 1

协程并不能真正帮助将数据从一个软件组件移交到另一个软件组件。它们使用看似同步的语法帮助处理多个异步工作单元。这是协程的底线。它们类似于 JavaScript 中的 async/await 语法。虽然您可以使用协程从异步源访问数据，但它不会为您提供任何将数据代理到其他组件的原语。

LiveData 可能可以很好地满足您想要做的事情。不要将 ViewModel 与 LiveData 混为一谈——它们解决不同的问题。虽然您认为 ViewModel 只能由处理 UI 的代码访问是正确的，但该指南不会扩展到 LiveData。公开一个反映来自 FirebaseMessagingService 的当前数据的 LiveData 是完全合理的，该数据随后由 ViewModel 获取、转换并传递到视图。此 LiveData 可以是单例，也可以通过您选择的任何依赖项注入基础设施获得。

请记住，LiveData 实际上只应该用于管理状态更改。它不是您的应用程序可以监听的数据“流”。您需要确保您的基础设施是基于状态的，才能顺利进行。FCM 本身不是基于状态的，但如果您希望视图响应来自 FCM 的消息，则需要在每条消息之间保留足够的上下文，以确保您的 UI 一致地响应新消息（或完全缺少消息） 。