[解決済み] 観測可能なものと流動的なもの 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 を使用することができます。 Observable を管理することなく、すべての値を受け取ることができます。 buffer ? あるいは、反対側からの意見として backpressure 消費するものを管理し、処理することに有利になるのでしょうか？

どのように解決するのですか？

背圧が実際に顕在化するのは、バッファの束縛です。 Flowable.observeOn は128要素のバッファを持ち、下流がそれを受け入れることができるのと同じくらい速く排出されます。このバッファサイズは、バースト的なソースを扱うために個別に増やすことができ、すべてのバックプレッシャーマネジメントは1.xから適用されます。 Observable.observeOn は、要素を収集し続ける無限のバッファを持ち、アプリはメモリ不足になる可能性があります。

を使用することができます。 Observable を例にとります。

• GUIイベントの処理
• 短いシーケンス（合計1000要素以下）の処理

を使用することができます。 Flowable を例にとります。

• コールドソースとノンタイムドソース
• ジェネレーターライクソース
• ネットワークとデータベースへのアクセサー