12

Intro to Rx的调度和线程部分说

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

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

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

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

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

4

2 回答 2

3

  1. 表示层并不关心 observable 本身来自哪里，但它确实关心它是否会锁定 UI 线程。所以表示层必须采取预防措施来防止这种情况发生。这是一个幸福的无知案例，带有一层安全感。

  2. 表示层不在乎。它只想确保它本身没有被阻塞。

  3. 如果流来自 UI并且需要很长时间来处理，那么流的所有者应该认真对待这一点，并确保它是在非 UI 调度程序上处理的。然后 UI 必须确保它返回到 UI 线程，如果它需要在那里使用。如果处理速度很快，那没关系。

于 2016-01-09T08:53:39.650 回答
3

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

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

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

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

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

我很想看看它如何为您工作或您如何应用替代模式。

于 2016-01-09T21:38:51.877 回答