☰

Observable vs Flowable rxJava2 質問する

tag-icon • tag-icon java android rx-java
Observable vs Flowable rxJava2 質問する

新しい rx java 2 を見てきましたが、もうそのアイデアがよく理解できていませんbackpressure...

Observableサポートされていないものbackpressureとサポートされているものがあることは承知していますFlowable。

したがって、例に基づいて、次flowableのような場合を考えてみましょうinterval。

        Flowable.interval(1, TimeUnit.MILLISECONDS, Schedulers.io())
            .observeOn(AndroidSchedulers.mainThread())
            .subscribe(new Consumer<Long>() {
                @Override
                public void accept(Long aLong) throws Exception {
                    // do smth
                }
            });

これは約 128 個の値を超えるとクラッシュします。これは、アイテムを取得するよりも消費が遅いことを示していることは明らかです。

しかし、同じことがObservable 

     Observable.interval(1, TimeUnit.MILLISECONDS, Schedulers.io())
            .observeOn(AndroidSchedulers.mainThread())
            .subscribe(new Consumer<Long>() {
                @Override
                public void accept(Long aLong) throws Exception {
                    // do smth
                }
            });

これはまったくクラッシュしません。消費にいくらか遅延があっても、まだ動作します。Flowable動作させるために、演算子を入れるとしますonBackpressureDrop。クラッシュはなくなりますが、すべての値が出力されるわけでもありません。

したがって、現在私の頭の中で答えが見つからない基本的な質問は、を管理せずにbackpressureプレーンを使用してすべての値を受け取ることができるのに、なぜ を気にする必要があるのか​​ということです。または、反対に、を管理および処理することにはどのような利点がありますか?Observablebufferbackpressure

ベストアンサー1

バックプレッシャーが実際に示すのは、制限付きバッファです。Flowable.observeOnには、ダウンストリームが処理できる速度で排出される 128 要素のバッファがあります。 このバッファ サイズを個別に増やしてバースト ソースを処理することができ、バックプレッシャー管理のすべてのプラクティスは 1.x から引き続き適用されます。 には、Observable.observeOn要素を収集し続ける無制限のバッファがあり、アプリのメモリが不足する可能性があります。

Observableたとえば、次のようなものを使用できます。

  • GUIイベントの処理
  • 短いシーケンス（合計 1000 要素未満）での作業

Flowableたとえば、次のようなものを使用できます。

  • コールドソースと非タイムソース
  • ジェネレータのようなソース
  • ネットワークおよびデータベース アクセサー

おすすめ記事