2017-01-26 5 views
1

ここでは簡単な観察可能な例を示しますRXJava - ホット観測 - 安全なCPUリソース

observable 
      .filter(...) 
      .buffer(50, TimeUnit.MILLISECONDS) 
      .doOnNext(/* this is executed all the time... */) 
      .filter(data -> data.size() > 0) 
      .doOnNext(/* this is not executed because of the filter above... */) 
      .flatMap(data -> Observable.from(data).distinctUntilChanged()) 
      .subscribeOn(Schedulers.io()) 
      .observeOn(AndroidSchedulers.mainThread()) 
      .subscribe(); 

問題/質問

私はbuffer(...)機能から取得することを観察できるが、ほとんど空、結果の後に結果を放出していますもの。

このようなオブザーバブルでこの問題を処理する正しい方法をフィルタリングしていますか?そのようなサブスクリプションの多くを同時にコストパフォーマンスにするのだろうか?あるいは、これは異なって扱われるべきですか?

答えて

1

一般的に、はい、あなたがダウンストリームを必要としないものを除外します。

同時に多くのサブスクリプションを使用するとコストパフォーマンスが向上しますか?

技術的には:はい。タイマーが多く、計算スレッド上でよりアクティブなシーケンス。ただし、シーケンスのオーバーヘッドは、実行するビジネスロジックよりもはるかに小さい場合があります。いくつかのオーバーヘッドを節約するため

、私はflatMapIterable使用したい:

observable 
    .filter(...) 
    .buffer(50, TimeUnit.MILLISECONDS) 
    .doOnNext(/* this is executed all the time... */) 
    .filter(data -> data.size() > 0) 
    .doOnNext(/* this is not executed because of the filter above... */) 
    .flatMapIterable(data -> data)    // <----------------------------- 
    .distinctUntilChanged() 
    .subscribeOn(Schedulers.io()) 
    .observeOn(AndroidSchedulers.mainThread()) 
    .subscribe(); 
+0

おかげで、それは私が知りたいと思ったものです。私は今この設定が 'distinctUntilChanged'のネストされた呼び出しをもはや必要としない理由をチェックしなければなりません、それは私の例と同じ方法で動作します... – prom85

+0

データは' Observable'ではなく 'List' Javaの 'distinctUntilChanged'です。 – akarnokd

+0

私はすでにそれを理解して、何か間違って最初に考えていた...ありがとう – prom85

関連する問題