Osservabile vs Flowable rxJava2

Ho guardato il nuovo rx java 2 e non sono abbastanza sicuro di aver capito più l'idea di backpressure...

Sono consapevole che abbiamo Observableche non ha backpressuresupporto e Flowableche ce l' ha.

Quindi, sulla base di un esempio, diciamo che ho flowablecon 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
                }
            });

Questo andrà in crash dopo circa 128 valori, ed è abbastanza ovvio che sto consumando più lentamente che ottenere oggetti.

Ma poi abbiamo lo stesso con 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
                }
            });

Questo non si bloccherà affatto, anche quando metto un po 'di ritardo nel consumo, funziona ancora. Per far Flowablefunzionare, diciamo che metto onBackpressureDropoperator, crash è sparito ma non tutti i valori vengono emessi.

Quindi la domanda di base che non riesco a trovare risposta attualmente nella mia testa è perché dovrei preoccuparmi di backpressurequando posso usare plain Observableancora ricevere tutti i valori senza gestire il buffer? O forse dall'altro lato, quali vantaggi mi backpressuredanno a favore della gestione e della gestione del consumo?

Ciò che la contropressione si manifesta in pratica sono i buffer limitati, Flowable.observeOnha un buffer di 128 elementi che viene drenato alla velocità con cui il flusso d'aria può sopportarlo. È possibile aumentare questa dimensione del buffer individualmente per gestire la sorgente bursty e tutte le pratiche di gestione della contropressione si applicano ancora da 1.x. Observable.observeOnha un buffer illimitato che continua a raccogliere gli elementi e la tua app potrebbe esaurire la memoria.

Puoi usare Observablead esempio:

• gestione degli eventi della GUI
• lavorare con sequenze brevi (meno di 1000 elementi in totale)

Puoi usare Flowablead esempio:

• sorgenti fredde e non temporizzate
• generatore come sorgenti
• accessori di rete e database

La contropressione si verifica quando il tuo osservabile (editore) crea più eventi di quanti il ​​tuo abbonato possa gestire. In questo modo puoi far sì che gli abbonati perdano eventi o puoi ottenere un'enorme coda di eventi che alla fine porta alla mancanza di memoria. Flowableprende in considerazione la contropressione. Observablenon. Questo è tutto.

mi ricorda un imbuto che quando ha troppo liquido trabocca. Flowable può aiutare a non farlo accadere:

con un'enorme contropressione:

ma con l'utilizzo di flowable, c'è molta meno contropressione:

Rxjava2 ha alcune strategie di contropressione che puoi utilizzare a seconda del tuo caso d'uso. per strategia intendo che Rxjava2 fornisce un modo per gestire gli oggetti che non possono essere elaborati a causa dell'overflow (contropressione).

ecco le strategie. Non li esaminerò tutti, ma ad esempio, se non vuoi preoccuparti degli elementi traboccati, puoi utilizzare una strategia di rilascio come questa:

observable.toFlowable (BackpressureStrategy.DROP)

Per quanto ne so dovrebbe esserci un limite di 128 elementi sulla coda, dopodiché potrebbe esserci un overflow (contropressione). Anche se non è 128, è vicino a quel numero. Spero che questo aiuti qualcuno.

se hai bisogno di cambiare la dimensione del buffer da 128 sembra che possa essere fatto in questo modo (ma fai attenzione ai vincoli di memoria:

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

nello sviluppo del software di solito la strategia di contropressione significa che stai dicendo all'emettitore di rallentare un po 'poiché il consumatore non può gestire la velocità dei tuoi eventi di emissione.

Il fatto che si sia verificato un Flowablearresto anomalo dopo aver emesso 128 valori senza la gestione della contropressione non significa che si bloccherà sempre dopo esattamente 128 valori: a volte si arresta in modo anomalo dopo 10, ea volte non si arresta affatto. Credo che questo sia quello che è successo quando hai provato l'esempio con Observable: non c'era contropressione, quindi il tuo codice ha funzionato normalmente, la prossima volta potrebbe non esserci. La differenza in RxJava 2 è che non esiste più il concetto di contropressione in Observables e non c'è modo di gestirlo. Se stai progettando una sequenza reattiva che probabilmente richiederà una gestione esplicita della contropressione, questa Flowableè la scelta migliore.