RxJava2_2：流程及关键对象的理解

RxJava2：流程及关键对象的理解

参考：

http://blog.youkuaiyun.com/column/details/rxjava.html?&page=2     （这个是rxjava1的）

https://juejin.im/post/5848d96761ff4b0058c9d3dc

http://www.jianshu.com/p/404a4d9b415a

 

流程：

rxjava采用的是观察者模式，所以这个模式在理解这里很重要。其次rxjava采用的是流式处理。

管道上游和管道下游就分别对应着RxJava中的Observable和Observer，它们之间的连接就对应着subscribe()；

注意: 只有当上游和下游建立连接之后, 上游才会开始发送事件. 也就是调用了subscribe() 方法之后才开始发送事件。

在emitter.onNext发出数据流之后doNext是将emitter发出的数据留作副本并行地进行处理，处理后的数据并不影响传递的observable中数据流中的数据。最后emmiter.onNext发出的数据是在观察者的onNext中得到对应的处理。

对象：

Rxjava为响应式编程，采用的是观察这模式，对其的理解都是按照观察者模式那套来理解的。

Observable为被观察者，observer为观察者。

Observable：被观察者

 

Observer：观察者

 

Flowable:是一个被观察者

 

 

Subscriber:也是一种观察者

在2.0中它与Observer没什么实质的区别，不同的是Subscriber要与Flowable(也是一种被观察者)联合使用，该部分内容是2.0新增的,Obsesrver用于订阅Observable，而Subscriber用于订阅Flowable。

 

Comsumer：观察者

如果把rxjava的观察者当做事件发生者，而comsumer就是事件消费者。在rxjava2中仍然保留了这种简化订阅方法。

 

ObservableEmitter：被观察者事件发送对象

用来发出事件的，它可以发出三种类型的事件，通过调用emitter的onNext(T value)、onComplete()和onError(Throwable error)就可以分别发出next事件、complete事件和error事件

发送事件需要满足的规则：

l   上游可以发送无限个onNext, 下游也可以接收无限个onNext.

l   当上游发送了一个onComplete后, 上游onComplete之后的事件将会继续发送, 而下游收到onComplete事件之后将不再继续接收事件.

l   当上游发送了一个onError后, 上游onError之后的事件将继续发送, 而下游收到onError事件之后将不再继续接收事件.

l   上游可以不发送onComplete或onError.

l   最为关键的是onComplete和onError必须唯一并且互斥, 即不能发多个onComplete, 也不能发多个onError, 也不能先发一个onComplete,然后再发一个onError, 反之亦然

 

Disposable：切断监测对象

可以把它理解成两根管道之间的一个机关, 当调用它的dispose()方法时, 它就会将两根管道切断, 从而导致下游收不到事件。（上游依然可以发送，只是下游不再接受）

 

Scheduler:相当于线程控制器

RxJava 通过它来指定每一段代码应该运行在什么样的线程。RxJava 已经内置了几个Scheduler ，它们已经适合大多数的使用场景,实现发送消息和接受消息在不同线程中进行的目的。

 

Flowable VS Subscriber

Observable和Observer在处理同步订阅也就是在一个线程中的时候上游发送一个事件下游接受一个事件是没有什么问题的，而当处理异步订阅也就是上游和下游不在同一个线程中时上游发送数据不需要等待下游接收, 因为两个线程并不能直接进行通信, 因此上游发送的事件并不能直接到下游里去, 上游把所有的事件发送到一个可以存储的池里面去(相当于Handler中的消息队列), 下游从队列里取出事件来处理, 因此, 当上游发事件的速度太快, 下游取事件的速度太慢, 队列就会迅速装满, 然后溢出来, 最后就OOM了.当然我们也可以通过控制上游消息的发送速度和发送数量来控制。不过Subscriber和Flowable的出现就完美的解决了OOM这个问题.

区别

1、创建Flowable的时候增加了一个参数, 这个参数是用来选择背压,也就是出现上下游流速不均衡的时候应该怎么处理的办法。

2、下游的onSubscribe方法中传给我们的不再是Disposable了, 而是Subscription。

subscription.cancel()也可以切断水管, 不同的地方在于Subscription增加了一个void request(long n)方法,。Flowable在设计的时候采用了一种新的思路也就是响应式拉取的方式来更好的解决上下游流速不均衡的问题,我们把request当做是一种能力, 当成下游处理事件的能力, 下游能处理几个就告诉上游我要几个, 这样只要上游根据下游的处理能力来决定发送多少事件, 就不会造成一窝蜂的发出一堆事件来, 从而导致OOM