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

Question

Rx简介的Scheduling and Threading部分表示

  

只能由最终订阅者

调用SubscribeOn和ObserveOn

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

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

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

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

Answer 1

1. 表示层本身并不关心observable来自何处，但它确实关心它是否可能锁定UI线程。因此表示层必须采取预防措施以防止这种情况发生。这是一个幸福的无知与一层安全的情况。

2. 表示层无关紧要。它只是想确保它本身没有被阻止。

3. 如果流来自用户界面和，则需要花费很长时间才能处理，然后流的所有者应该认真对待这一点，并确保它在非UI调度程序上处理。然后UI必须确保它返回到UI线程，如果它需要在那里消费。如果处理速度很快则无关紧要。

Answer 2

很高兴看到你读过这本书，并且花时间挑战那里的一些指导。

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

1. 并发很难，并且有一个简单的规则可以帮助团队生成更好的代码
2. 并发很难，并且只需一个地方来定位并发问题就可以为堆栈/分层提供更好的心智模型，并且应该简化测试。
表示在应用程序中引入并发性的层越多
3. 阻止UI线程不是好消息。尽可能早地离开UI-Thread，然后尽可能延迟在UI上延迟任何数据处理。这种模式旨在实现这一目标。

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

遗憾的是，很难将这些项目的案例研究放在一起，因为大多数项目受到新发展区的保护。

我希望看到它对您有用或如何应用替代模式。