RxJava2背压-Flowable

最新推荐文章于 2024-08-26 09:30:00 发布
最新推荐文章于 2024-08-26 09:30:00 发布
阅读量1.3k 收藏 7
点赞数
分类专栏： 函数式编程
本文深入探讨了RxJava2中Flowable的概念及其在解决背压问题中的应用。Flowable作为Observable的升级版，通过引入背压策略和响应式拉取方式，有效避免了数据流过载问题，确保了上下游数据处理的平衡。
摘要由CSDN通过智能技术生成

转载自冯丰枫的博客

Flowable介绍

既然在函数响应式编程中会产生背压（backpressure）问题，那么在函数响应式编程中就应该有解决方案。
Rxjava2相对于Rxjava1最大的更新就是把对背压问题的处理逻辑从Observable中抽取出来产生了新的可观察对象Flowable。
在Rxjava2中，Flowable可以看做是为了解决背压问题，在Observable的基础上优化后的产物，与Observable不处在同一组观察者模式下，Observable是ObservableSource/Observer这一组观察者模式中ObservableSource的典型实现，而Flowable是Publisher与Subscriber这一组观察者模式中Publisher的典型实现。
所以在使用Flowable的时候，可观察对象不再是Observable,而是Flowable;观察者不再是Observer，而是Subscriber。Flowable与Subscriber之间依然通过subscribe()进行关联。
虽然在Rxjava2中，Flowable是在Observable的基础上优化后的产物，Observable能解决的问题Flowable也都能解决，但是并不代表Flowable可以完全取代Observable,在使用的过程中，并不能抛弃Observable而只用Flowable。
由于基于Flowable发射的数据流，以及对数据加工处理的各操作符都添加了背压支持，附加了额外的逻辑，其运行效率要比Observable慢得多。
只有在需要处理背压问题时，才需要使用Flowable。

Flowabel使用

类似于Observable,在使用Flowable时，也可以通过create操作符创建发射数据流，代码如下：

public void demo2() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        System.out.println("发射----> 1");
                        e.onNext(1);
                        System.out.println("发射----> 2");
                        e.onNext(2);
                        System.out.println("发射----> 3");
                        e.onNext(3);
                        System.out.println("发射----> 完成");
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER) //create方法中多了一个BackpressureStrategy类型的参数
                .subscribeOn(Schedulers.newThread())//为上下游分别指定各自的线程
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {   //onSubscribe回调的参数不是Disposable而是Subscription
                        s.request(Long.MAX_VALUE);            //注意此处，暂时先这么设置
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println("接收----> " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                    }

                    @Override
                    public void onComplete() {
                        System.out.println("接收----> 完成");
                    }
                });
    }

运行结果如下：

System.out: 发射----> 1
System.out: 发射----> 2
System.out: 发射----> 3
System.out: 发射----> 完成
System.out: 接收----> 1
System.out: 接收----> 2
System.out: 接收----> 3
System.out: 接收----> 完成

发射与处理数据流在形式上与Observable大同小异，发射器中均有onNext，onError，onComplete方法，订阅器中也均有onSubscribe，onNext，onError，onComplete方法。

但是在细节方面还是有三点不同

  1. create方法中多了一个BackpressureStrategy类型的参数。

  2. 订阅器Subscriber中，方法onSubscribe回调的参数不是Disposable而是Subscription，多了行代码：s.request(Long.MAX_VALUE);

  3. Flowable发射数据时，使用特有的发射器FlowableEmitter，不同于Observable的ObservableEmitter

正是这三点不同赋予了Flowable不同于Observable的特性。

BackpressureStrategy背压策略

在通过create操作符创建Flowable时，多了一个BackpressureStrategy类型的参数，BackpressureStrategy是个枚举，源码如下：

package io.reactivex;

/**
 * Represents the options for applying backpressure to a source sequence.
 */
public enum BackpressureStrategy {
    /**
     * OnNext events are written without any buffering or dropping.
     * Downstream has to deal with any overflow.
     * <p>Useful when one applies one of the custom-parameter onBackpressureXXX operators.
     */
    MISSING,
    /**
     * Signals a MissingBackpressureException in case the downstream can't keep up.
     */
    ERROR,
    /**
     * Buffers <em>all</em> onNext values until the downstream consumes it.
     */
    BUFFER,
    /**
     * Drops the most recent onNext value if the downstream can't keep up.
     */
    DROP,
    /**
     * Keeps only the latest onNext value, overwriting any previous value if the
     * downstream can't keep up.
     */
    LATEST
}

onBackpressureXXX背压操作符

Flowable除了通过create创建的时候指定背压策略，也可以在通过其它创建操作符just，fromArray等创建后通过背压操作符指定背压策略。

  • onBackpressureBuffer()对应BackpressureStrategy.BUFFER
  • onBackpressureDrop()对应BackpressureStrategy.DROP
  • onBackpressureLatest()对应BackpressureStrategy.LATEST
    例如代码
    public void demo7() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        for (int i = 0; i < 500; i++) {
                            e.onNext(i);
                        }
                        e.onComplete();
                    }
                }, BackpressureStrategy.DROP)
                .observeOn(Schedulers.newThread())
                .subscribeOn(Schedulers.newThread())
                .subscribe(new Consumer<Integer>() {
                    @Override
                    public void accept(@NonNull Integer integer) throws Exception {
                        System.out.println(integer);
                    }
                });
    }

等同于，代码：

    public void demo8() {
        Flowable.range(0, 500)
                .onBackpressureDrop()
                .subscribeOn(Schedulers.newThread())
                .observeOn(Schedulers.newThread())
                .subscribe(new Consumer<Integer>() {
                    @Override
                    public void accept(@NonNull Integer integer) throws Exception {
                        System.out.println(integer);
                    }
                });
    }

Subscription

Subscription与Disposable均是观察者与可观察对象建立订阅状态后回调回来的参数，如同通过Disposable的dispose()方法可以取消Observer与Oberverable的订阅关系一样，通过Subscription的cancel()方法也可以取消Subscriber与Flowable的订阅关系。

不同的是接口Subscription中多了一个方法request(long n)，如上面代码中的：
s.request(Long.MAX_VALUE);

此方法的作用是什么呢，去掉这个方法会有什么影响呢？
运行如下代码：

public void demo9() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        System.out.println("发射----> 1");
                        e.onNext(1);
                        System.out.println("发射----> 2");
                        e.onNext(2);
                        System.out.println("发射----> 3");
                        e.onNext(3);
                        System.out.println("发射----> 完成");
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER) //create方法中多了一个BackpressureStrategy类型的参数
                .subscribeOn(Schedulers.newThread())//为上下游分别指定各自的线程
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        //去掉代码s.request(Long.MAX_VALUE);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println("接收----> " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                    }

                    @Override
                    public void onComplete() {
                        System.out.println("接收----> 完成");
                    }
                });
    }

运行结果如下：
System.out: 发射----> 1
System.out: 发射----> 2
System.out: 发射----> 3
System.out: 发射----> 完成

我们发现Flowable照常发送数据，而Subsriber不再接收数据。
这是因为Flowable在设计的时候，采用了一种新的思路——响应式拉取方式，来设置下游对数据的请求数量，上游可以根据下游的需求量，按需发送数据。
如果不显示调用request则默认下游的需求量为零，所以运行上面的代码后，上游Flowable发射的数据不会交给下游Subscriber处理。
运行如下代码：

public void demo10() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        System.out.println("发射----> 1");
                        e.onNext(1);
                        System.out.println("发射----> 2");
                        e.onNext(2);
                        System.out.println("发射----> 3");
                        e.onNext(3);
                        System.out.println("发射----> 完成");
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER) //create方法中多了一个BackpressureStrategy类型的参数
                .subscribeOn(Schedulers.newThread())//为上下游分别指定各自的线程
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        s.request(2);//设置Subscriber的消费能力为2
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println("接收----> " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                    }

                    @Override
                    public void onComplete() {
                        System.out.println("接收----> 完成");
                    }
                });
    }

运行结果如下：
System.out: 发射----> 1
System.out: 发射----> 2
System.out: 发射----> 3
System.out: 发射----> 完成
System.out: 接收----> 1
System.out: 接收----> 2

我们发现通过s.request(2);设置Subscriber的数据请求量为2条，超出其请求范围之外的数据则没有接收。

多次调用request会产生怎样的结果呢？
运行如下代码：

public void demo11() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        String threadName = Thread.currentThread().getName();
                        for (int i = 1; i <= 10; i++) {
                            System.out.println(threadName + "发射---->" + i);
                            e.onNext(i);
                        }
                        System.out.println(threadName + "发射数据结束" + System.currentTimeMillis());
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER)
                .subscribeOn(Schedulers.newThread())
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        s.request(3);//调用两次request
                        s.request(4);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println(Thread.currentThread().getName() + "接收---------->" + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        t.printStackTrace();
                    }

                    @Override
                    public void onComplete() {
                        System.out.println(Thread.currentThread().getName() + "接收----> 完成");
                    }
                });
    }

通过Flowable发射10条数据，在onSubscribe(Subscription s) 方法中调用两次request，运行结果如下：
在这里插入图片描述
我们发现Subscriber总共接收了7条数据，是两次需求累加后的数量。
通过日志我们发现，上游并没有根据下游的实际需求，发送数据，而是能发送多少，就发送多少，不管下游是否需要。
而且超出下游需求之外的数据，仍然放到了异步缓存池中。这点我们可以通过以下代码来验证：

public void demo12() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        for (int i = 1; i < 130; i++) {
                            System.out.println("发射---->" + i);
                            e.onNext(i);
                        }
                        e.onComplete();
                    }
                }, BackpressureStrategy.ERROR)
                .subscribeOn(Schedulers.newThread())
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        s.request(1);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println("接收------>" + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        t.printStackTrace();
                    }

                    @Override
                    public void onComplete() {
                        System.out.println("接收------>完成");
                    }
                });
    }

通过Flowable发射130条数据，通过s.request(1)设置下游的数据请求量为1条，设置缓存策略为BackpressureStrategy.ERROR，如果异步缓存池超限，会导致MissingBackpressureException异常。
运行之后，日志如下：
在这里插入图片描述
久违的异常出现了，所以超出下游需求之外的数据，仍然放到了异步缓存池中，并导致缓存池溢出。
那么上游如何才能按照下游的请求数量发送数据呢，
虽然通过request可以设置下游的请求数量，但是上游并没有获取到这个数量，如何获取呢？
这便需要用到Flowable与Observable的第三点区别，Flowable特有的发射器

FlowableEmitter

flowable的发射器FlowableEmitter与observable的发射器ObservableEmitter均继承自Emitter（Emitter在教程二中已经说过了）
比较两者源码可以发现；

public interface ObservableEmitter<T> extends Emitter<T> {

    void setDisposable(Disposable d);

    void setCancellable(Cancellable c);

    boolean isDisposed();
  
    ObservableEmitter<T> serialize();
}

与

public interface FlowableEmitter<T> extends Emitter<T> {

    void setDisposable(Disposable s);

    void setCancellable(Cancellable c);

    long requested();

    boolean isCancelled();

    FlowableEmitter<T> serialize();
}

接口FlowableEmitter中多了一个方法

long requested();

我们可以通过这个方法来获取当前未完成的请求数量，
运行下面的代码，这次我们要先丧失一下原则，虽然我们之前说过同步状态下不使用Flowable，但是这次我们需要先看一下同步状态下情况。

public void demo13() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        String threadName = Thread.currentThread().getName();
                        for (int i = 1; i <= 5; i++) {
                            System.out.println("当前未完成的请求数量-->" + e.requested());
                            System.out.println(threadName + "发射---->" + i);
                            e.onNext(i);
                        }
                        System.out.println(threadName + "发射数据结束" + System.currentTimeMillis());
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER)//上下游运行在同一线程中
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        s.request(3);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println(Thread.currentThread().getName() + "接收---------->" + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        t.printStackTrace();
                    }

                    @Override
                    public void onComplete() {
                        System.out.println(Thread.currentThread().getName() + "接收----> 完成");
                    }
                });
    }

打印日志如下：
在这里插入图片描述
通过日志我们发现， 通过e.requested()获取到的是一个动态的值，会随着下游已经接收的数据的数量而递减。
在上面的代码中，我们没有指定上下游的线程，上下游运行在同一线程中。
这与我们之前提到的，同步状态下不使用Flowable相违背。那是因为异步情况下e.requested()的值太复杂，必须通过同步情况过渡一下才能说得明白。
我们在上面代码的基础上，给上下游指定独立的线程，代码如下

public void demo14() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        String threadName = Thread.currentThread().getName();
                        for (int i = 1; i <= 5; i++) {
                            System.out.println("当前未完成的请求数量-->" + e.requested());
                            System.out.println(threadName + "发射---->" + i);
                            e.onNext(i);
                        }
                        System.out.println(threadName + "发射数据结束" + System.currentTimeMillis());
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER)
                .subscribeOn(Schedulers.newThread())//添加两行代码，为上下游分配独立的线程
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        s.request(3);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println(Thread.currentThread().getName() + "接收---------->" + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        t.printStackTrace();
                    }

                    @Override
                    public void onComplete() {
                        System.out.println(Thread.currentThread().getName() + "接收----> 完成");
                    }
                });
    }

运行后日志如下：
在这里插入图片描述
虽然我们指定了下游的数据请求量为3，但是我们在上游获取未完成请求数量的时候，并不是3，而是128。难道上游有个最小未完成请求数量？只要下游设置的数据请求量小于128，上游获取到的都是128？
带着这个疑问，我们试一下当下游的数据请求量为500，大于128时的情况。

public void demo15() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        String threadName = Thread.currentThread().getName();
                        for (int i = 1; i <= 5; i++) {
                            System.out.println("当前未完成的请求数量-->" + e.requested());
                            System.out.println(threadName + "发射---->" + i);
                            e.onNext(i);
                        }
                        System.out.println(threadName + "发射数据结束" + System.currentTimeMillis());
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER)
                .subscribeOn(Schedulers.newThread())//添加两行代码，为上下游分配独立的线程
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        s.request(500);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println(Thread.currentThread().getName() + "接收---------->" + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        t.printStackTrace();
                    }

                    @Override
                    public void onComplete() {
                        System.out.println(Thread.currentThread().getName() + "接收----> 完成");
                    }
                });
    }

运行日志如下;
在这里插入图片描述
结果还是128.
其实不论下游通过s.request();设置多少请求量，我们在上游获取到的初始未完成请求数量都是128。
这是为啥呢？
还记得之前我们说过，Flowable有一个异步缓存池，上游发射的数据，先放到异步缓存池中，再由异步缓存池交给下游。所以上游在发射数据时，首先需要考虑的不是下游的数据请求量，而是缓存池中能不能放得下，否则在缓存池满的情况下依然会导致数据遗失或者背压异常。如果缓存池可以放得下，那就发送，至于是否超出了下游的数据需求量，可以在缓存池向下游传递数据时，再作判断，如果未超出，则将缓存池中的数据传递给下游，如果超出了，则不传递。
如果下游对数据的需求量超过缓存池的大小，而上游能获取到的最大需求量是128，上游对超出128的需求量是怎么获取到的呢？
带着这个疑问，我们运行一下，下面的代码，上游发送150个数据，下游也需要150个数据。

public void demo16() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> e) throws Exception {
                        String threadName = Thread.currentThread().getName();
                        for (int i = 1; i <= 150; i++) {
                            System.out.println("当前未完成的请求数量-->" + e.requested());
                            System.out.println(threadName + "发射---->" + i);
                            e.onNext(i);
                        }
                        System.out.println(threadName + "发射数据结束" + System.currentTimeMillis());
                        e.onComplete();
                    }
                }, BackpressureStrategy.BUFFER)
                .subscribeOn(Schedulers.newThread())
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<Integer>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        s.request(150);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        System.out.println(Thread.currentThread().getName() + "接收---------->" + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        t.printStackTrace();
                    }

                    @Override
                    public void onComplete() {
                        System.out.println(Thread.currentThread().getName() + "接收----> 完成");
                    }
                });
    }

截取部分日志如下：
在这里插入图片描述
我们发现通过e.requested()获取到的上游当前未完成请求数量并不是一直递减的，在递减到33时，又回升到了128.而回升的时机正好是在下游接收了96条数据之后。我们之前说过，异步缓存池中的数据并不是向下游发射一条便清理一条，而是每等累积到95条时，清理一次。通过e.requested()获取到的值，正是在异步缓存池清理数据时，回升的。也就是，异步缓存池每次清理后，有剩余的空间时，都会导致上游未完成请求数量的回升，这样既不会引发背压异常，也不会导致数据遗失。
上游在发送数据的时候并不需要考虑下游需不需要，而只需要考虑异步缓存池中是否放得下，放得下便发，放不下便暂停。所以，通过e.requested()获取到的值，并不是下游真正的数据请求数量，而是异步缓存池中可放入数据的数量。数据放入缓存池中后，再由缓存池按照下游的数据请求量向下传递，待到传递完的数据累积到95条之后，将其清除，腾出空间存放新的数据。如果下游处理数据缓慢，则缓存池向下游传递数据的速度也相应变慢，进而没有传递完的数据可清除，也就没有足够的空间存放新的数据，上游通过e.requested()获取的值也就变成了0，如果此时，再发送数据的话，则会根据BackpressureStrategy背压策略的不同，抛出MissingBackpressureException异常，或者丢掉这条数据。
所以上游只需要在e.requested()等于0时，暂停发射数据，便可解决背压问题。

tinysakurac
关注
专栏目录
android创建flowable工具类,【Android】Rxjava2 Flowable详解与背压那些事
weixin_35865261的博客
05-26 750
1.Rxjava1中的背压Rxjava2中有这么一个被观察者Flowable，同样作为被观察者，它和Observable有什么区别呢，在Rxjava2中，Observable不再支持背压，而新增的Flowable支持背压，何为背压，就是上游发送事件的速度大于下游处理事件的速度所产生的现象。我们来看个例子，先把rxjava切换到rxjava1.0:implementation 'io.reactiv...
RxJava2 系列-2：背压和 Flowable
你好，开发者
11-04 1117
背压(Back Pressure)的概念最初并不是在响应式编程中提出的，它最初用在流体力学中，指的是后端的压力， 通常用于描述系统排出的流体在出口处或二次侧受到的与流动方向相反的压力。 在响应式编程中，我们可以将产生信息的部分叫做上游或者叫生产者，处理产生的信息的部分叫做下游或者消费者。 试想如果在异步的环境中，生产者的生产速度大于消费者的消费速度的时候，明显会出现生产过剩的情景，这时候就需要消费...
rxjava2-http:通过无阻塞背压通过HTTP传输RxJava2 Flowable
05-06
rxjava2-http 通过http传输RxJava2 Flowable（具有非阻塞背压）。 状态： pre-alpha （开发中）。 计划于2018年7月发布第一版。 特征 将无阻塞背压应用于网络上的流 使用所需的任何序列化库（内核支持Flowable<ByteBuffer> ） 支持普通的HTTP / HTTPS服务（WebSockets没有防火墙问题） 使用Servlet 3.1+异步处理（默认情况下） 入门 Maven依赖 < dependency> < groupId>com.github.davidmoten</ groupId> < artifactId>rxjava2-http</ artifactId> < version>VERSION_HERE</ version> </ dependency> 创建servlet 下面
Rxjava2的介绍与使用(一：详解)
最新发布
08-26 840
就是观察者到订阅者，观察者可以指定线程的模式，订阅者也可以指定线程的模式。观察者将观察执行操作时，会将状态同步给订阅者。订阅者正常有四个回调，会根据不同的操作符，做对应的操作。Kotlin 流flow、ShareFlow、StateFlow、Channel的解释与使用-CSDN博客通过以上的订阅，我们知道了如何去创建和订阅以及观察，以及常用的合并以及操作符等，有了这些简单的，我们就可以很好的在项目中进行很好的运用。
rxjava背压_RxJava2实战--第八章 RxJava的背压
weixin_39820177的博客
12-18 215
RxJava2实战--第八章 RxJava的背压1 背压在RxJava中，会遇到被观察者发送消息太快以至于它的操作符或者订阅者不能及时处理相关的消息，这就是典型的背压(Back Pressure)场景。BackPressure经常被翻译为背压，背压的字面意思比较晦涩，难以理解。它是指在异步场景下，被观察者发送事件速度远快于观察者处理的速度，从而导致下游的buffer溢出，这种现象叫做背压。产生条件...
RxJava2.0-Flowable类
fengluoye2012的博客
02-09 4892
简介 RxJava2.0提供了5中操作符的基类，分别为Observable，Flowable，Single，Completable，Maybe；前面几篇文章都是以Observable介绍相关的操作符，Observable是非背压，可选的多值基类，提供工厂方法，操作符和处理同步或者异步数据流的能力；Observable的操作符默认提供缓存空间大小128，但是大多数操作符实现类允许显示的设置缓存区大...
rxjava背压(1)，4年小Android的心路历程
m0_66264673的博客
01-29 519
这样来看，我的内存就稳定，老铁稳。 那么，试试第二种方法，下游少接收点事件 //定时取样 Observable.create(new ObservableOnSubscribe() { @Override public void subscribe(ObservableEmitter emitter) throws Exception { for (int i = 0; ; i++) { //无限循环发事件 emitter.onNext(i); } } }).sample(1, TimeUnit.SEC
Flowable背压支持——几乎可以说是对Flowable最全面而详细的讲解
{丸の子}
12-04 5032
背压（backpressure） 数据流发射，处理，响应可能在各自的线程中独立进行，上游在发射数据的时候，不知道下游是否处理完，也不会等下游处理完之后再发射。 这样，如果上游发射的很快而下游处理的很慢，会怎样呢？ 将会产生很多下游没来得及处理的数据，这些数据既不会丢失，也不会被垃圾回收机制回收，而是存放在一个异步缓存池中，如果缓存池中的数据一直得不到处理，越积越多，最后就会造成内存溢出，...
RxJava-2-0还没熟悉，RxJava-3-0说来就来了！，面试阿里巴巴
m0_61417997的博客
09-02 318
作为尝鲜，赶紧品尝吧。 主要变化 主要特点 单一依赖：Reactive-Streams 继续支持Java 6+和Android 2.3+ 修复了API错误和RxJava 2的许多限制 旨在替代RxJava 2，具有相对较少的二进制不兼容更改 提供Java 8 lambda友好的API 关于并发源的不同意见 异步或同步执行 参数化并发的虚拟时间和调度程序 为测试schedulers，consumers和plugin hooks提供测试和诊断支持 与RxJava 2的主要区别是： 将eagerTrunc
Android-Rxjava-：最简单&全面背压讲解-(Flowable)，android插件化
m0_61068088的博客
03-20 742
][外链图片转存中…(img-lRCVJaWS-1710917083741)]
Rxjava2_Flowable_Sqlite_Android数据库访问实例
08-28
首先，RxJava2的Flowable是用于处理背压的Observable类型，适用于数据产生速度快于消费速度的场景。它提供了BackpressureStrategy，能够处理生产者与消费者之间数据流的速度不匹配问题，避免数据丢失或内存溢出。 1...
rxjava背压_RxJava2｜Flowable以及背压
weixin_39959236的博客
12-18 130
RxJava2 Flowable以及背压前述java-1.8maven-3rxjava-2.2.3背压背压是指在异步场景中，被观察者发送事件速度远快于观察者的处理速度的情况下，一种告诉上游的被观察者降低发送速度的策略。Flowable的官方介绍:io.reactivex.Flowable: 0..N flows, supporting Reactive-Streams and backpressu...
java flowable_RxJava流控机制之Flowable
weixin_42561623的博客
03-04 648
背景对于生产者和消费者模型，存在一个问题就是当生产者生产的速度大于消费者消费速度，并且生产过程不会停止，生产者和消费者位于不同的线程中，这是要如何对待多余出来的生产内容？是丢掉，是缓冲？在强大的异步处理框架中，RxJava又是怎么处理的呢？如果在工作中万一发生丢包事件怎么办？使用环境与本文目的RxJava版本：2.1.0默认条件：观察者和被观察者位于main线程中，且使用了默认的事件发射器。目的：...
九、RxJava背压模式Flowable
sunweihao2019的博客
11-30 425
1.项目地址 在MainActivity10 2.讲解：背压的由来，在异步线程中，上游不停的发射，而下游又被堵住了，这样上游会越来越多，最终导致OOM。 3.
Android-Rxjava-：最简单&全面背压讲解-(Flowable)
2401_84010836的博客
03-30 826
上图可以很清楚看出二者的区别，其实Flowable出来以上的区别之外，它其他所有使用与Observable完全一样。Flowable的create例子@Overridej
RxJava 2.X 中的背压
神经大条蕾弟的博客
04-08 2011
RxJava 2.X 中的背压 简介: 本文章介绍的是 RxJava 2.X 中的压背. 目录: 1.什么是背压 2.背压的策略 1.什么是背压 定义:   在 RxJava 中, 会遇到 被观察者 发送消息太快以至于它的操作符或者 订阅者 不能及时处理相关的消息, 这就是典型的 背压(Back Pressure) Back Pressure 经常被翻译为 背压. 是指在异步场景下, 被观察...
Rxjava2入门教程五：Flowable背压支持——对Flowable最全面而详细的讲解
zhaoweixing1989的专栏
11-07 667
如需下载源码，请访问https://github.com/fengchuanfang/Rxjava2Tutorial文章原创，转载请注明出处：Rxjava2入门教程五：Flowable背压支持——对Flowable最全面而详细的讲解 背压（backpressure） 当上下游在不同的线程中，通过Observable发射，处理，响应数据流时，如果上游发射数据的速度快于下游接收处理数据的速度，这样...
RxJava背压
川峰的博客
05-29 1335
RxJava背压主要用来解决异步订阅关系中，被观察者发送事件的速度与观察者接收事件的速度不匹配的问题。大多数情况下，由于被观察者发送事件速度太快，而观察者来不及响应处理所有事件，从而导致事件丢失、OOM等异常。 RxJava 2.0中对背压的支持 主要是通过Flowable类来实现的，Flowable其实就是被观察者（Observable）的一种新实现，用来解决RxJava 1.0中无法解决的背压...
RxJava2 Flowable与SQLite在Android中的数据库操作实战
这里，`Flowable`是RxJava2的一个类型，用于处理背压问题，适合于可能会产生大量数据的场景。如果数据产生速度不快，可以选择使用`Observable`以减少不必要的复杂性。 实现这些接口的方法时，通常会结合...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值