java - LiveData vs Handler 和 LocalBroadcast

Question

我有旧的 Android/java 代码，其中包含两个派生自 IntentService， 并且这些服务不在单独的进程中运行。

问题是关于从这些IntentService返回结果的方式。

一个服务返回结果，使用Handler + Runnable，在主循环中运行代码:

new Handler(Looper.getMainLooper()).post(new Runnable() {
    @Override
    public void run() {
        MyApplication.get().setFoo(someThing);
    }
});

另一种是使用LocalBroadcastManager.getInstance(this).sendBroadcast(in);向Activity发送消息，Activity订阅在 onResume 中通过 BroadcastReceiver 消息，并在 onPause 中取消订阅。

我说得对吗，在这两种情况下都可以使用 LiveData 来简化事情吗？

IntentService 应该创建 LiveData 并且想要结果的人应该 观察 它， 并且当新数据到达时 IntentService 应该调用 postValue， 或者可能有一些暗礁来阻止 LiveData 在这里的使用？

Answer 1

我认为 LiveData 不会帮助您将任何数据从 Service 发送到其他组件。

从任何Service 到其他组件的通信的问题是您通常不会获得对Service 的直接引用，因此您不能直接“订阅” "通知。

理论上，如果Service运行在同一个进程中，可以绑定(bind)它，获取Service对象的引用，然后直接订阅。但是，这通常是矫枉过正，我认为这种模式并没有被广泛使用。

在您的示例中，有两种通信机制:

1. Service 静态到达 Application 对象并设置一些数据。这是通过全局状态进行的通信，通常被认为是一种反模式。
2. 通过 LocalBroadcastManager 进行通信

从上述两种机制中，我将只使用#2，不惜一切代价避免使用#1。

返回LiveData。

为了能够从 Service 中获取 LiveData 对象，您将需要对该 Service 的引用。这通常是不可能的，除非您在同一进程中绑定(bind) Service，或者使用一些涉及全局状态的丑陋 hack。

因此，LiveData 在这种情况下的用处非常有限。

顺便说一下，虽然 LocalBroadcastManager 没问题，但我觉得这个机制太复杂和限制了。因此，如果 Service 在同一进程中运行，我更喜欢使用 EventBus 以便从 Service 与其他组件(或副反之亦然)。

您可以在 SQLite benchmarking application 中看到此类通信的示例我几天前写的。在此应用中，TestService 将状态更改和测试结果作为粘性事件发布到 EventBus，TestActivity 订阅这些事件。