Observable vs Flowable rxJava2

Ich habe mir das neue RX Java 2 angesehen und bin mir nicht ganz sicher, ob ich die Idee von verstehe backpressure mehr ...

Mir ist bewusst, dass wir Observabledas nicht backpressureunterstützen und habenFlowable das hat es.

Nehmen wir also anhand eines Beispiels an, ich habe flowablemit 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
                }
            });

Dies wird nach ungefähr 128 Werten abstürzen, und das ist ziemlich offensichtlich, dass ich langsamer konsumiere als Gegenstände zu bekommen.

Aber dann haben wir das gleiche mit 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
                }
            });

Dies wird überhaupt nicht abstürzen, selbst wenn ich den Verbrauch etwas verzögere, funktioniert es immer noch. Um die FlowableArbeit kann sagen , Ich habe onBackpressureDropBediener, crash ist weg , aber nicht alle Werte sind entweder emittiert.

Die Grundfrage, die ich derzeit nicht in meinem Kopf beantworten kann, ist, warum ich mich darum kümmern sollte, backpressurewenn ich einfach verwenden kann und Observabletrotzdem alle Werte erhalte, ohne die zu verwalten buffer. Oder vielleicht von der anderen Seite, welche Vorteile bieten backpressuremir für die Verwaltung und den Umgang mit dem Konsum?

Was sich in der Praxis im Gegendruck manifestiert, sind begrenzte Puffer Flowable.observeOnmit einem Puffer von 128 Elementen, der so schnell entleert wird, wie es der Dowstream aufnehmen kann. Sie können diese Puffergröße einzeln erhöhen, um die Bursty-Quelle zu verarbeiten, und alle Verfahren zur Verwaltung des Gegendrucks gelten weiterhin ab 1.x.Observable.observeOnverfügt über einen unbegrenzten Puffer, der die Elemente ständig sammelt, und Ihre App verfügt möglicherweise nicht über genügend Speicher.

Sie können Observablezum Beispiel verwenden:

• Behandlung von GUI-Ereignissen
• Arbeiten mit kurzen Sequenzen (insgesamt weniger als 1000 Elemente)

Sie können Flowablezum Beispiel verwenden:

• kalte und nicht zeitgesteuerte Quellen
• Generator wie Quellen
• Netzwerk- und Datenbankzugriffe

Gegendruck tritt auf, wenn Ihr Observable (Publisher) mehr Ereignisse erstellt, als Ihr Abonnent verarbeiten kann. So können Abonnenten Ereignisse verpassen oder eine große Warteschlange von Ereignissen erhalten, die letztendlich zu Speichermangel führen. Flowableberücksichtigt den Gegendruck. Observablenicht. Das ist es.

es erinnert mich an einen Trichter, der überläuft, wenn zu viel Flüssigkeit überläuft. Flowable kann helfen, dies nicht zu erreichen:

mit enormem Gegendruck:

Bei Verwendung von fließfähigem Material ist der Gegendruck jedoch viel geringer:

Rxjava2 verfügt über einige Gegendruckstrategien, die Sie je nach Anwendungsfall anwenden können. Mit Strategie meine ich, dass Rxjava2 eine Möglichkeit bietet, mit Objekten umzugehen, die aufgrund des Überlaufs (Gegendruck) nicht verarbeitet werden können.

Hier sind die Strategien. Ich werde nicht alle durchgehen, aber wenn Sie sich zum Beispiel keine Sorgen über die überfüllten Elemente machen möchten, können Sie eine Drop-Strategie wie die folgende verwenden:

Observable.toFlowable (BackpressureStrategy.DROP)

Soweit ich weiß, sollte es ein Limit von 128 Elementen in der Warteschlange geben, danach kann es zu einem Überlauf (Gegendruck) kommen. Auch wenn es nicht 128 ist, ist es nahe an dieser Zahl. Hoffe das hilft jemandem.

Wenn Sie die Puffergröße von 128 ändern müssen, sieht es so aus (aber beachten Sie alle Speicherbeschränkungen:

myObservable.toFlowable(BackpressureStrategy.MISSING).buffer(256); //but using MISSING might be slower.  

Bei der Softwareentwicklung bedeutet eine Gegendruckstrategie normalerweise, dass Sie den Emitter anweisen, etwas langsamer zu werden, da der Verbraucher die Geschwindigkeit Ihrer emittierenden Ereignisse nicht bewältigen kann.

Die Tatsache, dass Sie Flowablenach der Ausgabe von 128 Werten ohne Gegendruckbehandlung abgestürzt sind, bedeutet nicht, dass es immer nach genau 128 Werten abstürzt: Manchmal stürzt es nach 10 ab, manchmal stürzt es überhaupt nicht ab. Ich glaube, dies ist passiert, als Sie das Beispiel ausprobiert haben Observable- es gab zufällig keinen Gegendruck, sodass Ihr Code normal funktionierte, beim nächsten Mal möglicherweise nicht. Der Unterschied in RxJava 2 besteht darin, dass es in Observables kein Konzept für Gegendruck mehr gibt und keine Möglichkeit, damit umzugehen . Wenn Sie eine reaktive Sequenz entwerfen, die wahrscheinlich eine explizite Behandlung des Gegendrucks erfordert, Flowableist dies die beste Wahl.