[TIL] 2022 / 10 / 25 - Rx

Disposable

 

 

리소스를 정리

 

subscribe중인 Stream을 원하는 시기에 처리할 수 있도록 도와줌

 

항상 마지막에 dispose가 붙는 것을 알 수 있음

-> Observable은 모두 Disposable을 리턴하기 때문임

-> 이를 통해 Stream을 종료하고 실행되던걸 종료함.

 

Observable의 next 이벤트 emit이 끝나면 disposed로 인해 자동으로 종료(리소스 해제)됨

-> 근데 인터벌의 경우를 생각하면 화면이 dismiss되더라도 disposed되지않음

-> 이때 deinit이 정상적으로 되면 disposed도 정상적으로 동작함

-> 순환참조 신경 잘 쓰기

 

만약 루트뷰컨트롤러인 경우에는 메모리에서 해제되지 않음

 

위의 두 경우는 직접 관리를 해줘야함.

-> disposed 메서드를 직접 호출해서 리소스 정리

 

근데 개수가 너무 많다면 하나하나 직접 dispose 실행하기는 어려움

-> DisposeBag의 인스턴스를 초기화하면 한 번에 정리가능

 

 

 

Subject

 

옵저버블은 이벤트를 생성하고 전달하는 역할만 함

 

즉, 새로운 값을 옵저버블에 추가할 수 없음

 

이벤트를 전달할 수도 있고, 처리할 수도 있는 것이 Subject

 

Subject는 subscribe를 여러 번하더라도 실행이 내부적으로 공유

-> 옵저버블은 여러 번 subscribe해도 독립적인 실행

 

즉, 옵저버블에서 구독을 하면 이벤트로 전달되는 것은 항상 새로운 것이라고함

 

 

PublishSubject

 

 

초기값이 없는 빈상태 

 

subscribe 이전 / error / complete 이후의 이벤트는 모두 무시

 

 

BehaviorSubject

 

 

PublishSubject와 달리 초기값이 반드시 필요함

-> Subscribe이전에 emit한 이벤트가 있다면, 가장 마지막으로 전달된 이벤트를 전달받기때문

-> 그래서 이전에 emit한 이벤트가 없다면 설정한 초기값을 전달하는 것.

 

뷰를 미리 채우는 용도 등으로 사용할 수 있음

 

 

 

ReplaySubject

 

 

위의 두 가지와 달리 bufferSize라는 파라미터를 받음

 

이 버퍼사이즈에 작성된 수만큼 메모리에 이벤트를 가지고 있다가 subscribe가 되면 한 번에 이벤트 전달함

 

오류가 발생하게되어도 보유한 이벤트 emit하고 에러 표시

 

근데 너무 많은 양의 버퍼를 갖고 있으면 메모리 부하 발생하므로 적당하게

 

 

AsyncSubject

 

 

completed 이벤트가 전달되기 전까지는 어떠한 이벤트도 전달하지 않음

 

completed 이벤트가 전달되었을때, 가장 마지막에 전달된 next 이벤트를 함께 전달

 

잘 안쓰는듯