Question

我在工作中发现了一个有趣的发现，我希望其中一位RxJava大师可以解释它。我正在使用RxJava 1.2.4。

我正在使用RxJavaFX从JavaFX TableView发出表选择事件（这些事件在JavaFX线程上发出），并将它们放在switchMap()中以启动一个昂贵的进程每一个。我使用内置switchMap()的{{1}}不仅可以利用并发性，而且如果我快速进行多项选择，先前的请求将被取消，最新的请求将在下一次开始。

subscribeOn()

但是，我注意到JavaFX UI在选择时非常滞后，这意味着JavaFX线程仍在进行大量的工作。这让我感到困惑，因为我以为我使用tableSelectionEvents.switchMap { runExpensiveProcess(it) .subscribeOn(Schedulers.io()) .flatMap { anotherExpensiveProcess(it) } .toList() }.observeOn(JavaFxScheduler.getInstance()).subscribe { backingList.setAll(it) }中的Schedulers.io()来卸载另一个线程上的工作，事实确实如此。但其他事情正在发生。

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

在switchMap()内拨打unSubscribe()是否贵？

Answer 1

我在另一个论坛上得到了杰克沃顿的帮助。他强调了我已经开始怀疑的事情。有些订阅比取消订阅更昂贵。在这种情况下，我认为我对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)
    }

RxJava - 为什么我的switchMap（）切换速度很慢？

1 个答案: