javafx - RxJava - 为什么我的 switchMap() 切换这么慢？

Question

我在工作中有一个有趣的发现，我希望 RxJava 的一位大师能解释一下。我正在使用 RxJava 1.2.4。

我正在使用 RxJavaFX从 JavaFX TableView 发出表选择事件(这些事件在 JavaFX 线程上发出)，并将它们放入 switchMap() 以启动每个事件的昂贵过程。我使用带有 subscribeOn() 的 switchMap() 不仅可以利用并发性，而且如果我快速进行多项选择，先前的请求将被取消，最新的请求将被取消接下来开始。

tableSelectionEvents.switchMap {
        runExpensiveProcess(it)
                .subscribeOn(Schedulers.io())
                .flatMap { anotherExpensiveProcess(it) }
                .toList()
    }.observeOn(JavaFxScheduler.getInstance()).subscribe {
        backingList.setAll(it)
    }

但是，我注意到在我进行选择时 JavaFX UI 非常滞后，这意味着 JavaFX 线程仍在做大量工作。这让我感到困惑，因为我认为我在 switchMap() 中使用了 Schedulers.io() 来卸载另一个线程上的工作，事实确实如此。但还有其他事情正在发生。

我有预感，然后在 switchMap() 之前放了一个 observeOn(Schedulers.io())。现在一切都完美运行，完全没有延迟。我的理论是传入线程(最初是 JavaFX 线程，现在是 IO 线程)必须做大量工作才能取消 switchMap() 中的最后一个订阅。这使得 JavaFX 线程花费大量时间执行取消，从而卡住了 UI。

在 switchMap() 中调用 unSubscribe() 是否很昂贵？

Answer 1

我在另一个论坛上得到了 Jake Wharton 的一些帮助。他强调了我已经开始怀疑的事情。有些订阅比其他订阅更昂贵。在这种情况下，我认为我对 RxJava-JDBC 的使用导致了大量需要处理的查询开销，并且 JavaFX 线程在执行此操作时被占用。

他还告诉我这就是 unsubscribeOn() 运算符的用途。它允许为取消订阅的执行指定一个调度程序。

tableSelectionEvents.switchMap {
        runExpensiveProcess(it)
                .subscribeOn(Schedulers.io())
                .flatMap { anotherExpensiveProcess(it) }
                .toList()
                .unsubscribeOn(Schedulers.io())
    }.observeOn(JavaFxScheduler.getInstance()).subscribe {
        backingList.setAll(it)
    }