관찰 가능한 rxJava2와 플로우 가능한 rxJava2

관찰 가능한 rxJava2와 플로우 가능한 rxJava2

저는 새로운 rx java 2를 보고 있는데, 그 아이디어를 잘 이해하지 못하고 있습니다.backpressure더 이상...

우리가 가진 건 알아Observable는 가지고 있지 않다.backpressure지원 및Flowable그게 다야.

예를 들어 다음과 같이 합시다.flowable와 함께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
                }
            });

이 값은 128개 정도 지나면 크래시 됩니다.그리고 제가 아이템을 얻는 것보다 소비하는 속도가 느리다는 것은 분명합니다.

하지만 우리는 같은 것을 가지고 있다.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
                }
            });

소비 지연을 해도 전혀 크래시 되지 않습니다.만들기 위해서Flowable일 예를 들어, 내가onBackpressureDrop오퍼레이터, 크래시는 사라졌지만 모든 값이 내보내지는 않습니다.

그래서 현재 내 머릿속에서 답을 찾을 수 없는 기본적인 질문은 왜 내가 신경써야 하는가이다.backpressure내가 플레인(plain)을 사용할 수 있을 때Observable모든 값을 계속 수신하고 있습니다.buffer아니면 다른 쪽에서는 어떤 장점이 있을까요?backpressure소비자를 관리하고 처리하는 데 찬성할 수 있게 해주십시오.

실제로 나타나는 배압은 경계가 있는 버퍼입니다.Flowable.observeOn128개의 요소를 가진 버퍼를 가지고 있습니다.이 버퍼는 다운스트림에서 얻을 수 있는 한 빠르게 배출됩니다.버스트 소스를 처리하기 위해 이 버퍼 크기를 개별적으로 늘릴 수 있으며, 1.x부터 모든 백압력 관리 방법이 적용됩니다.Observable.observeOn에는 요소를 계속 수집하는 무제한 버퍼가 있어 앱의 메모리가 부족할 수 있습니다.

사용할 수 있습니다.Observable예를 들어 다음과 같습니다.

• 처리, GUI 이벤트
• 짧은 시퀀스 사용(전체 요소 1000개 미만)

사용할 수 있습니다.Flowable예를 들어 다음과 같습니다.

• 냉·비냉매원
• 발전기 유사 소스
• 네트워크 및 데이터베이스 액세스 장치

백프레셔란 관찰 가능한(퍼블리셔)이 서브스크라이버가 처리할 수 있는 것보다 더 많은 이벤트를 생성하는 경우입니다.따라서 사용자가 이벤트를 찾을 수 없거나 대량의 이벤트큐를 얻을 수 있기 때문에 결국 메모리 부족으로 이어집니다.는 역압력을 고려합니다. Observable하지 않다.바로 그거야.

액체가 넘치면 깔때기가 생각나요.플로우 가능은 이를 실현하지 않는 데 도움이 됩니다.

엄청난 배압을 가하고 있습니다.

그러나 플로우블을 사용하면 배압이 훨씬 줄어듭니다.

Rxjava2에는 사용 사례에 따라 사용할 수 있는 몇 가지 배압 전략이 있습니다.스트래티지 즉, Rxjava2는 오버플로(배압) 때문에 처리할 수 없는 오브젝트를 처리하는 방법을 제공합니다.

다음은 전략입니다.모두 검토하지는 않겠습니다만, 예를 들어, 넘쳐나는 아이템에 대해 걱정하지 않으신다면, 다음과 같은 드롭 전략을 사용할 수 있습니다.

observable.toFlowable(배압전략).드롭)

큐에 128개의 아이템 제한이 있는 것으로 알고 있으며, 그 이후에는 오버플로(배압)가 발생할 수 있습니다.128이 아니더라도 그 숫자에 가깝다.이게 도움이 됐으면 좋겠네요.

버퍼 사이즈를 128에서 변경할 필요가 있는 경우는, 다음과 같이 할 수 있습니다(단, 메모리의 제약에 주의해 주세요).

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

소프트웨어 개발에서 보통 배압 전략은 소비자가 방출 이벤트를 처리할 수 없기 때문에 방출자에게 속도를 약간 낮추라고 지시하는 것을 의미합니다.

그 사실은Flowablecrashed는 128개의 값을 백압력으로 처리하지 않고 내보낸 후 항상 128개의 값을 실행한 후에 크래시 되는 것은 아닙니다.때로는 10개 이후에 크래시 되는 경우도 있고 전혀 크래시 되지 않는 경우도 있습니다.저는 당신이 이 예시를 시도했을 때 이런 일이 일어났다고 생각합니다.Observable- 배압이 없었기 때문에, 당신의 코드는 정상적으로 동작하고 있었습니다만, 다음 번에는 동작하지 않을지도 모릅니다.RxJava 2의 차이점은 back pressure의 개념이 없다는 것입니다.Observable더 이상 대처할 방법이 없습니다.명시적인 배압 처리가 필요할 수 있는 반응 시퀀스를 설계할 경우Flowable최선의 선택입니다.

언급URL : https://stackoverflow.com/questions/40323307/observable-vs-flowable-rxjava2