RxJava关于Android应用程序中的线程、CompositeDisposable和Scheduler的问题

Question

我的代码如下：

timingObservable = getCurrentModule()
                .zipWith(Observable.interval(200, TimeUnit.MILLISECONDS), (currentModule, interval) -> currentModule)
                .repeat()
                .distinctUntilChanged()
                .getModuleDataFromDb()

compositeDisposable.add(timingObservable
        .subscribeOn(Schedulers.io())
        .subscribe(next -> {
            .
            .
            .
        }));

public Observable<String> getCurrentModule() {
    return Observable.fromCallable(() -> {
        String currentModule = "";
        // doing some none database work and computation
        .
        .
        .
        return currentModule;
    }
}

它应该定期检查当前模块，并在模块发生更改时从db获取一些数据。我有几个问题：

>

我正在向我的服务/活动类的onDestory（）中的复合处置和调用处置添加订阅（）的一次性返回。当服务在没有调用onDestroy（）的情况下被杀死时，这些一次性对象会发生什么。我的意思是，由于复合处置对象已被销毁，我是否可能失去处置一次性对象的能力？我应该持有CompositeDisposable的应用程序范围实例吗？

就性能而言，这段代码推荐哪一个？订阅（Schedulers.io（））或订阅（Schedulers.computation（））因为Observable.interval默认使用计算调度程序，我们也有数据库工作。

有什么建议可以改进上述周期性任务的代码吗？

Answer 1

回答以下问题：

在RxJava的RxThreadFactory类和newThread（）方法中，我们有t.setDaemon（true）行，那么所有RxJava线程都是守护线程是真的吗？所以，只要应用程序的一个组件是活动的并且应用程序进程仍在运行，它们就是活动的，对吗？

在JavaThread::setDaemon（true）只是意味着一旦所有非守护线程都完成，那么这些“守护”线程就会被放弃并关闭JVM。作为参考，android“main”Thread不是守护线程，但有一个Looper。守护线程可以自然完成并且不会阻止进程退出。您不应该依赖这种机制来执行长时间运行的任务，并且使用前台服务和/或WorkManager，Rx线程池可以持续与其运行的进程一样长的时间，除非它们绑定的执行器显式关闭。

我正在将subscribe（）的一次性返回添加到服务/活动类的compositeDisposable中，并在onDestory（）中调用dispose。假设在一个场景中有一个服务和一个活动，compositeDisposable属于该服务。当服务在没有调用onDestroy（）的情况下被终止，并且活动保持活动状态时，这些可处置项会发生什么情况。我的意思是，既然compositeDisposable对象被破坏了，我是否有可能失去处理一次性物品的能力？我是否应该保留CompositeDisposable的应用程序范围实例？

只有在以下情况下，服务才会在没有生命周期回调的情况下被销毁：1）Android终止进程以回收资源，在这种情况下，它与清除资源无关；2）程序崩溃，并且再次不需要清理资源

在性能方面，本规范建议采用哪种性能？subscribeOn（Schedulers.io（））或subscribeOn（Schedulers.computation（））自可观察。interval默认使用计算调度器，我们也有DB工作。

Schedulers.io是一个无界的线程池，而Schedulers.computation（）是有界的（我相信是8个线程的池）。性能可能会有所不同，但在大多数情况下差异可以忽略不计。一种情况下，Schedulers.computation（）可能会变慢，如果您连续使用此线程池有很多并发，这意味着您正在等待线程空闲。相比之下，Schedulers.io（）可能需要从它使用的ThreadFactory创建新线程的前期成本。但是它会尝试使用其池中的现有线程。需要指标才能真正看到单个用例的任何性能差异。根据一般规则io（）建议，对于文件/数据库/网络等工作，应使用此Scheduler和计算工作，就像计时器/算法应该使用后者。

有什么建议可以改进上述周期性任务的代码吗？

如前所述，轮询通常不是一个好主意，而概念上的反应流作为发布/订阅观察者模式更有用。然而，您似乎对可以修改的内容有一些限制。有了提供的代码，真正给出任何具体改进的上下文太少，只有建议，最终会以“我不能那样做，因为…”结束。