본문 바로가기

IT/RxJava, RxAndroid, RxKotlin

[RxJava] flowable

728x90
SMALL



Flowable과 Observable의 차이?

공식문서에서는 해당링크의 상황에서 맞춰 Observable과 Flowable을 구분해서 사용하라고 합니다.
여기서 가장 중점적으로 봐야할것은 데이터의 처리 갯수 뿐아니라 데이터의 발행속도가 구독자가 처리하는 속도보다 현저하게 빠른경우
즉 공급이 수요보다 현저히 빠른경우 OOME(out of memory Exeception) 과 같은 에러가 발생할 수 있는데 
BackPreesure라는 배압에 대한 이슈를 Buffer를 이용하여 대응하는 기능을 제공합니다. 해당 내용은 아래의 링크를 통해 확인가능합니다.



Which type to use?

When architecting dataflows (as an end-consumer of RxJava) or deciding upon what type your 2.x compatible library should take and return, you can consider a few factors that should help you avoid problems down the line such as MissingBackpressureException or OutOfMemoryError.

When to use Observable

  • You have a flow of no more than 1000 elements at its longest: i.e., you have so few elements over time that there is practically no chance for OOME in your application.
  • You deal with GUI events such as mouse moves or touch events: these can rarely be backpressured reasonably and aren't that frequent. You may be able to handle an element frequency of 1000 Hz or less with Observable but consider using sampling/debouncing anyway.
  • Your flow is essentially synchronous but your platform doesn't support Java Streams or you miss features from it. Using Observable has lower overhead in general than Flowable. (You could also consider IxJava which is optimized for Iterable flows supporting Java 6+).

When to use Flowable

  • Dealing with 10k+ of elements that are generated in some fashion somewhere and thus the chain can tell the source to limit the amount it generates.
  • Reading (parsing) files from disk is inherently blocking and pull-based which works well with backpressure as you control, for example, how many lines you read from this for a specified request amount).
  • Reading from a database through JDBC is also blocking and pull-based and is controlled by you by calling ResultSet.next() for likely each downstream request.
  • Network (Streaming) IO where either the network helps or the protocol used supports requesting some logical amount.
  • Many blocking and/or pull-based data sources which may eventually get a non-blocking reactive API/driver in the future.


위의 내용에서 보통 사용하는 경우를 정리해보면 

옵저버블 : 1000개 이하의 요소를 처리할때, GUI 관련 이벤트를 처리할때,

flowable : 1000개 이상의 요소를 처리할때,

발행하는 속도가 구독하는 속도보다 현저히 빨라서 데이터가 배압(Pressure)상태에 빠질때




Flowable pressure (배압상태) 대응함수


Flowable 에서 제공하는 배압 문제에 대응하는 함수 3가지


- onBackPressureBuffer()

배압 문제 발생 시 별도의 버퍼에 저장, Flowable은 기본적으로 128개의

버퍼가 있음.

- onBackPressureDrop()

배압 문제 발생 시 해당 데이터 무시.

- onBackPressureLatest()

처리할 수 없어서 쌓이는 데이터를 무시하면서 최신 데이터만 유지



728x90
LIST