RxJava - 为什么我的switchMap()切换速度很慢？

Question

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

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

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

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

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

unSubscribe()在switchMap()那个昂贵的范围内打电话？

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)
    }