system.reactive - subscribeOn 和 observeOn 应该只由最终订阅者调用吗？

Question

Scheduling and Threading Intro to Rx 部分说

the use of SubscribeOn and ObserveOn should only be invoked by the final subscriber

它还表示，在 UI 应用程序中，通常是最终订阅者的表示层应该是调用这些方法的层。

我想知道这个建议是否可靠，因为我看到了一些不方便的情况:

首先，我不认为表示层应该决定应该订阅来自数据层的 Observable 的位置。在我看来，表示层应该不知道数据是来自数据库、REST API 还是内存。为此，方便数据层调用subscribeOn()在返回 Observable 之前，尽可能方便地传递 IO 调度程序或立即调度程序。

如果表示层从某个服务或用例(反过来又从数据层获取)获取 Observable 并且该服务决定它需要在某个计算调度程序中处理流，那么表示层为什么要关心这个？

一个最初来自 UI 的流呢，所以它需要在 UI 线程中订阅。然后它会被发送到一些服务做一些工作，最后回到表示层在 UI 线程中进行观察。这将要求 UI 流为 subscribeOn() UI 调度程序，然后 observeOn()其他一些调度程序，最后 observeOn() UI 调度程序。在这种情况下，能够调用 subscribeOn()和 observeOn()只有在最终订阅者中意味着流只能在 UI 线程中处理。

为什么我应该牺牲应用程序的架构并忽略 Rx 通过仅由最终订阅者调用这两种方法来轻松切换线程的能力，是否有充分的理由？

Answer 1

很高兴看到您阅读了这本书，并且正在花时间挑战其中的一些指导。

我给出这个指导的原因是因为

并发很难，有一个简单的规则可以帮助团队产生更好的代码

并发很难，有一个地方可以找到并发问题，可以更好地理解堆栈/分层，并应该简化测试。在您的应用程序中引入并发的层数越多，就越糟糕

阻塞 UI 线程不是好消息。尽快离开 UI 线程，然后尽可能晚地延迟任何数据处理返回 UI 是可取的。这种模式旨在为该目标服务。

这些显然是我的意见，但我已经看到这些简单的指南有助于清理数十个项目的代码，减少代码库，提高测试能力，提高可预测性，并在许多情况下大幅提高性能。

遗憾的是，很难将这些项目的案例研究放在一起，因为它们中的大多数都受到 NDA 的保护。

我很想知道它是如何为您工作的，或者您如何应用替代模式。