Shulou(Shulou.com)06/01 Report--

This article introduces you how to analyze the design principle of reactive programming RxJava, the content is very detailed, interested friends can refer to, hope to be helpful to you.

1. ReactiveX and RxJava

The full name of ReactiveX is Reactive Extension, which is generally abbreviated as Rx, which is what we usually call reactive programming. Its design principle mainly uses the observer pattern, distinguishes the data producer and the consumer, carries on the data asynchronous processing through the event flow way.

RxJava is an implementation of the ReactiveX Java language, and its programming experience is very similar to functional programming and Stream in Java8. After mastering the relevant knowledge of Java8, you can easily get started with RxJava.

This article mainly focuses on the understanding of several main design patterns in RxJava. By combing the relevant class diagrams of Observable and explaining the relationship between these classes, we can more clearly understand the working principle of event-driven in RxJava.

II. Concepts in RxJava

First, we write a simple RxJava program that sends the elements in the array as events, which are finally printed on the console by the consumer:

From the picture, we can see:

Observable implements the ObservableSource interface, which can be understood literally. This is an interface that provides observation ability, so one of the capabilities of Observable is for observers to subscribe to events, and the method implementation of event subscription is to call the subscribe () method of Observable.

Observable is an abstract class that provides subscribeActual template methods for subclass implementations. It can be seen from the source code that Observable's subscribe () method will eventually delegate the subclass's subscribeActual () method implementation, which will establish an association between producers and consumers.

In addition, Observable is also a factory class, which provides static methods fromArray (), create (), etc. to create specific observable objects, as well as operation methods such as flatMap (), concatMap (), etc., to wrap observable objects.

The existence of Observable makes producers and consumers completely decouple, producers only need to pay attention to what kind of Observable objects they generate, and consumers only need to pay attention to what kind of Observable they are observing.

In practical applications, Rxjava has provided a variety of operators for us to use. Producers only need to call the corresponding methods in Observable to generate the required observable objects for consumers to subscribe to events. Consumers only need to call the subscribe () method of observable objects to establish observation relationship with producers, which is extremely convenient.

IV. True observation

Observer pattern is the core idea of RxJava design, in which there are always observed objects and observed objects. From the above analysis, we can see that Observable is more of a controller than the source of real events. So in RxJava, what is the real producer and what is the real consumer?

Let's analyze the following three common Observable:

Let's briefly introduce the role of these Observable. The role of fromArray is to send elements in the array as onNext events, the role of create is to send custom events, and the role of just is to send a single event.

The previous section mentioned that the actual subscription behavior is implemented by the subscribeActual () method in each Observable class, so let's take a look at the subscribeActual () method of these three classes.

Apart from the details, all three methods can be divided into the following three steps

Create the observed object and input the observer observer to establish the relationship between the two

The onSubscribe event is triggered and the observer responds to the event

To pull events, we can go inside d.run (), source.subscribe (parent), sd.run () and see that these methods are sending events such as onNext (), onError (), onComplete (), and so on.

The following figure shows the relevant class diagrams in the entire process. The sender of the actual event is an object such as FromArrayDisposable, while the actual observer is an entity class that implements the Observer interface. If we pass in a lambda expression when we subscribe, it will then be wrapped as a default LambdaObserver object for event consumption.

V. the necessity of packaging

RxJava provides a wealth of operators, such as flatMap,concatMap to convert events, and subscribeOn,observableOn to control the threads of production and consumption. These operators actually call the wrapper method in Observable to wrap the original observable object, returning an enhanced observable object.

There are many kinds of operators, so instead of giving examples here, let's take flatMap as an example to analyze how these operators work.

First, the flatMap operation returns an ObservableFlatMap object that, when created, passes in the original Observable object as an argument to the constructor.

Check out its core method subscribeActual

You can see that the subscribeActual method for this type of object is quite different from the method in the previous section, which does not actually create an observation relationship, but does two things:

Enhance the observer by wrapping it as a MergeObserver object that responds to the generated time.

Then call the subscribe method of source, where source is the Observable object passed in the previous constructor, which establishes the observation relationship.

The following is a class diagram related to the decorator pattern in RxJava: all wrapper classes inherit the AbstractObservableWithUpstream class, which has a member function of type ObservableSource that holds the decorated object.

Observable supports chained operations, and just like Stream in Java 8, let's consider this line of code.

When we analyze the above code, it will be very messy, and when we look at the source code, we will see the front and forget the back, but if we know enough about the packaging process of RxJava, we can easily analyze the above code.

The encapsulation of RxJava is powerful enough for us to use and expand easily, but it also makes it difficult for us to understand its real working principle. If we have little knowledge of the whole event handling process, then we can not easily orchestrate the service asynchronously, and it is difficult to find the root cause of the problem in the actual development process.

On how to analyze reactive programming RxJava design principles to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.