Beachten Sie, dass es in der neuen Version keine globalen Änderungen gibt, die Unterstützung für Java 8 jedoch erschienen ist und die Verwendung der Bibliothek komfortabler geworden ist.
Haftungsausschluss: Dieser Artikel basiert auf dem GitHub-Test . Außerdem teilen wir die Eindrücke unserer mobilen Entwickler von RxJava 3, geben jedoch nicht vor, eine erschöpfende Studie zu sein - da die neue Version kürzlich veröffentlicht wurde und noch nicht viel praktische Erfahrung vorliegt. Wenn Sie Ergänzungen haben, schreiben Sie in die Kommentare, wir werden gerne diskutieren)
Wichtige Änderungen in RxJava 3
Was wir also in RxJava 3 sehen :
- Die Java-Basisversion wurde jetzt auf 8 * erhöht.
- Es gibt Unterstützung für Sprachfunktionen wie:
- Streams
- Stream Collectors
- Optional
- CompletableFeature
* Um die Java8-API verwenden zu können, müssen Sie minSDK auf Version 24 erhöhen.
Im Gegenzug haben die Entwickler die Unterstützung für folgende Funktionen entfernt:
- java.time.Duration - erzeugt viele Überladungen, kann immer durch time + unit ersetzt werden;
- java.util.function - Ausnahmen können nicht ausgelöst werden, und Überladungen können zu unnötiger "Mehrdeutigkeit" führen.
Die Paketstruktur hat sich ebenfalls geändert:
Die vorgestellten Änderungen können in zwei Gruppen unterteilt werden:
- Verhaltensänderungen
- API-Änderungen
Verhaltensänderungen
- Alle Fehler werden verarbeitet
Bisher bestand eines der Probleme mit RxJava 2 darin, dass in einigen Fällen Fehler verloren gehen und nicht behandelt werden konnten. Wenn Sie sich in RxJava 3 von einer Quelle abmelden, die möglicherweise einen Fehler auslöst, wird dieser Fehler über RxJavaPlugins.onError () in den allgemeinen Fehlerbehandler geworfen.
- Connectable.reset ()
In RxJava 2 gab es ein Problem mit heißen Quellen: Beim Empfang eines ConnectableObservable-Terminalereignisses ignorierten neue Verbindungen alle Elemente und erhielten nur das Beendigungsereignis.
RxJava 3 führt eine Funktion zum Zurücksetzen des ConnectableObservable-Status mithilfe der Funktion reset () ein, damit neu verbundene Teilnehmer Daten verarbeiten können.
- Möglichkeit, Flowable.publish anzuhalten
In RxJava 3 wird die Flowable.publish angehalten, nachdem eine bestimmte Anzahl von Werten empfangen wurde, und die verbleibenden Elemente stehen nachfolgenden Abonnenten zur Verfügung.
- Processor.offer () Nullparameter
Wenn Sie versuchen, PublishProcessor.offer (), BehaviourProcessor.offer () oder MulticastProcessor.offer () aufzurufen und null zu übergeben, wird eine NullPointerException ausgelöst, anstatt einen Fehler an den onError-Handler zu übergeben, und ein Terminalstatus wird ausgelöst.
- CompositeException.getCause ()
Früher in RxJava 2 war die Methode getCause () manchmal eine erhebliche Speicherlast, da die Methode initCause für jede Ausnahme aufgerufen wurde, instabil war und nicht immer eine Kette von Ausnahmen auslöste.
In der neuen Version wurde diese Methode von innen geändert und generiert nun eine Fehlerkette in Form einer Stapelverfolgung - durch einfaches Formatieren von Zeichenfolgen.
- Ausnahmen für die Parameterüberprüfung geändert
Wenn der Parameter ungültig ist, wird einige Betreiber jetzt werfen Illegal statt IndexOutOfBoundsException:
- überspringen
- skipLast
- takeLast
- takeLastTimed
- Quellen für fromX () vorab schließen
Die Bibliotheken fromAction () und fromRunnable () sind mit den übrigen fromX () -Aufrufen konsistent geworden. Die Rückrufe fromRunnable () und fromAction () werden jetzt sofort geschlossen, wenn sie entsprechend aufgerufen werden. In RxJava 2 wurden diese Operatoren nach dem Ende der Ausführung des an die Parameter übergebenen Lambda-Körpers geschlossen.
- Reihenfolge der Ressourcenbereinigung bei Verwendung von ()
Die using () -Anweisung enthält einen Parameter, der dafür verantwortlich ist, wann die verwendete Ressource bereinigt wird (true - vor Abschluss, false - after). In der frühen Version der Bibliothek wurde dieser Parameter ignoriert und die Ressource wurde immer bereinigt, bevor der Terminalstatus abgerufen wurde. In RxJava 3 funktioniert jedoch alles ordnungsgemäß.
API-Änderungen
- Die Ausnahmebehandlung von Funktionsschnittstellen der neuen Version der Bibliothek wurde von Ausnahme auf Throwable erweitert
- Neue Typen: Lieferant
In RxJava 3 wurde aufgrund der Erweiterung der Ausnahmen für funktionale Schnittstellen von Exception zu Throwable ein neuer Supplier-Typ eingeführt - ein Analogon zu Callable, jedoch mit Throwable-Throws
- In RxJava 3 wurden die Operatoren zum Konvertieren einer Datenquelle in eine andere in bestimmte Konverter geändert
- Verschobene Komponenten
Aufgrund der Tatsache, dass RxJava3 die Java8-API unterstützt, wurde eine neue Lösung eingeführt, die einzelne Factory-Klassen ersetzt: Die Methoden dieser Fabriken sind zu statischen Methoden der Disposable-Schnittstelle selbst geworden.
Wie vorher:
Jetzt:
- Um Warnungen zu reduzieren, wird die DisposableContainer-Klasse, die in CompositeDisposable verwendet wurde, Teil der öffentlichen API
- Einige der Operatoren in RxJava 2 befanden sich im experimentellen Stadium, und in der dritten Version wurden sie zu Standardoperatoren:
Flowable promotions
dematerialize(Function)
Observable promotions
dematerialize(Function)
Maybe promotions
doOnTerminate(Action)
materialize()
Single promotions
dematerialize(Function)
materialize()
Complectable promotions
delaySubscription(long, TimeUnit)
delaySubscription(long, TimeUnit, Scheduler)
materialize()
- concatMap() Scheduler’
- blockingSubscribe() Maybe, Single Completable
- onErrorComplete()
- onErrorResumeWith() Completable
- retryUntil() Single Completable
- switchOnNext() switchOnNextDelayError() Maybe, Single Completable
- dematerialize() Maybe
- fromX()-
- timeInterval() Maybe Single
- toFuture() Maybe Completable
- ofType() Maybe Single
- doOnLifecycle() Maybe, Single Completable
- concatMapX() (X – ) Maybe Single
- concatDelayError() Maybe, Single Completable
- mergeArray() Single
Flowable
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Observable
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Maybe
startWith(Publisher)
startWith(ObservableSource)
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Single
startWith(Publisher)
startWith(ObservableSource)
startWith(MaybeSource)
startWith(SingleSource)
startWith(ComplectableSource)
Complectable
startWith(MaybeSource)
startWith(SingleSource)
- onErrorReturn() Completable
- safeSubscribe() Maybe, Single Completable
- flatMap() Single
- concatEager() concatEagerDelayError() Flowable, Observable, Maybe Single
- fromSupplier()
Java8
Neuer Operator fromOptional () für Flowable, Observable und Maybe
hinzugefügt Neuer Operator fromStream () für Flowable und Observable
hinzugefügt Neuer Operator fromCompletionStage () für alle fünf Datenquellentypen
hinzugefügt Neuer Operator mapOptional () für Flowable, Observable, Maybe und Single hinzugefügt. Es können nur nicht leere Werte übergeben werden.
Neuer Operator blockingStream () für Flowable und Observable hinzugefügt. Der Operator stellt den Datenstrom als Stream dar. Es wird empfohlen, den Stream nach Abschluss der Arbeiten zu schließen, um alle Arten von Lecks zu vermeiden.
Neue Operatoren flatMapStream () und hinzugefügtconcatMapStream () für Flowable und Observable - Ermöglicht die Konvertierung jedes Elements in einen separaten Stream.
Neue Operatoren hinzugefügt flattenStreamAsFlowable () und flattenStreamAsObservable () für Maybe und einfach äquivalente flatMapStream () -Operatoren für Observable und Flowable
Was ist umbenannt
- Anstelle von startWith () - startWithArray () , startWithIterable () , startWithItem ()
- Anstelle von onErrorResumeNext () - onErrorResumeWith ()
- Anstelle von zipIterable () - zip ()
- Anstelle von kombinierenLatest () (mit einem Array-Argument) - kombinierenLatestArray () , kombinierenLatestArrayDelayError ()
- Anstelle von Single.equals () - sequenceEqual (SingleSource, SingleSource)
- Maybe.flatMapSingleElement() – Maybe.flatMapSingle()
- Callable – Supplier ( )
API
Maybe.toSingle (), Ersetzung - Maybe.defaultIfEmpty ()
subscribe (..., ..., ...,), Ersetzung - doOnSubscribe ()
Single.toCompletable (), Ersetzung - Single.ignoreElement ()
Completable.blockingGet (), Ersetzung - Completable .blockingAwait () wiedergeben
(Scheduler), ersetzen - beobachtenOn (Scheduler)
dematerialisieren (), ersetzen - deserialisieren (Funktion)
onExceptionResumeNext (), ersetzen - onErrorResumeNext (Funktion)
kombinierenLatest () (mit vararg-Parameter), ersetzen - kombinierenLatestArray ()
fromFuture () (mit Scheduler-Parameter), Ersetzung - subscribeOn ()
concatMapIterable () (mit Pufferparameter), Ersetzung - concatMapIterable (Funktion)
Außerdem wurden die folgenden Methoden aus TestSubscriber und TestObserver entfernt:
So migrieren Sie
Viele Entwickler stellen fest, dass die Migration von RxJava 2 zu RxJava 3 ein ziemlich mühsamer Prozess ist. Es gibt zwei Möglichkeiten für den Übergang:
- Haben Sie beide Versionen der Bibliothek in Ihrem Projekt.
- Führen Sie eine vollständige Migration zu RxJava 3 durch, während Sie eine spezielle Bibliothek verwenden können .
So migrieren Sie:
- Um die Arbeit mit der API zu aktualisieren, verwenden Sie Analoga der RxJava 2-Methoden, die Änderungen unterliegen.
- Es ist wichtig zu berücksichtigen, dass einige Bibliotheken von Drittanbietern immer noch auf RxJava 2 "sitzen". Um den Übergang zu vereinfachen, können Sie RxJavaBridge verwenden , das den größten Teil der Migration unter der Haube verbirgt.
- Retrofit RxJava3CallAdapterFactory .
Wir haben überprüft, was in RxJava 3 neu ist. Und jetzt versuchen wir, die Hauptfrage zu beantworten: Lohnt es sich überhaupt zu migrieren?
RxJava 3 ist praktisch eine API-Verbesserung. Aufgrund der Tatsache, dass keine grundlegenden Änderungen vorgenommen wurden, besteht derzeit im Allgemeinen keine Notwendigkeit, auf die neueste Version zu migrieren. Der Übergang selbst erfordert Aufwand, während viele Bibliotheken von Drittanbietern noch mit RxJava 2 verknüpft sind. Um mit Java8 zu arbeiten, müssen Sie minSDK zusätzlich auf Version 24 erhöhen. Einige Teams bieten auch alternative Lösungen an, z. B. die Verwendung von Kotlin Coroutines.
Es ist jedoch erwähnenswert, dass RxJava 2 jetzt in den Wartungsmodus wechselt, was bedeutet, dass es nur Fehlerbehebungen durch die Updates gibt. Die Unterstützung für die zweite Version wird voraussichtlich am 28. Februar 2021 enden.
! , .