subscribeOn和observeOn只能由最终订阅者调用吗？

Question

Intro to Rx的调度和线程部分说明了这一点

SubscribeOn和ObserveOn的使用只能由最终订阅者调用

它还说,在UI应用程序中,表示层(通常是最终订阅者)应该是调用这些方法的表示层.

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

1. 对于初学者,我不认为表示层应该决定应该订阅来自数据层的Observable的位置.在我看来,如果数据来自数据库,REST API或内存,表示层应该不知道.因此,subscribeOn()在返回Observable之前调用数据层很方便,方便地传递IO Scheduler或直接调度程序.
2. 如果表示层从某个服务或用例(从数据层获取它)获得Observable,并且该服务决定它需要在某个计算Scheduler中处理流,那么表示层为什么要关心这个呢？
3. 那个最初来自UI的流怎么样,所以需要在UI线程中订阅.然后它将被发送到一些服务来做一些工作,最后回到表示层,以便在UI线程中观察.这将要求UI流是subscribeOn()UI调度程序,然后是observeOn()其他调度程序,最后observeOn()是UI调度程序.在这种情况下,只能在最终订阅者中调用subscribeOn(),observeOn()这意味着只能在UI线程中处理该流.

我有理由牺牲应用程序的体系结构并忽略Rx通过最终订阅者调用这两种方法来轻松切换线程的能力吗？

Answer 1

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

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

1. 并发很难，有一个简单的规则可以帮助团队编写更好的代码
2. 并发很难，并且有一个地方来定位并发问题可以为您的堆栈/分层提供更好的思维模型，并且应该简化测试。在应用程序中引入并发的层越多，情况就越糟糕
3. 阻塞 UI 线程可不是什么好消息。最好尽快脱离 UI 线程，然后尽可能晚地延迟 UI 上的任何数据处理。该模式旨在服务于该目标。

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

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

我很想知道它对您有何作用，或者您如何应用替代模式。