Sharing Subscription
구독 공유를 통해서 불필요한 중복 작업 피하는 방법
- 가령, 서버에 접속할 때 3개의 구독이 존재한다면, 한 번만 요청해 받은 리소스를 구독 모두가 공유하지 못한다면 3번 네트워크 요청 시퀀스를 실행해야하는 불필요한 리소스 손해가 발생. 이를 해결 가능
 
구독 공유를 하지 않은 경우

구독 공유를 한 경우

- 공유할 구독이 있기 때문에 새 시퀀스 실행 X
 
multicast
- 유니캐스트 방식으로 동작하는 옵저버블을 멀티캐스트로 바꿔주는 연산자
 
- 이 자체를 사용하기 보다는 해당 연산자를 사용하는 다른 연산자를 호출하는 방식으로 사용
 
- 이벤트가 구독자에게 바로 전달되지 않고, 파라미터로 받은 subject로 전달된다. 그리고 이 subject가 등록된 이벤트를 구독자들에게 전달
 
Connectable Observable을 리턴한다.
- 일반 옵저버블과 달리, 구독자가 추가되어도 시퀀스 시작 X
 
- connect 메소드를 호출하는 시점에 시퀀스 실행
- connect의 리턴형은 disposable로, 원하는 시점에 중지 가능
 
 
 

- 모든 구독자가 하나의 시퀀스를 공유하므로, 구독이 지연된 3초 동안 방출된 이벤트는 두번째 구독자에게 전달되지 않음
 
publish
- PublishSubject를 활용해서 구독을 공유
 
- 내부적으로 PublishSubject를 자동 사용하므로 별도 선언 필요 없음
 
- 그 외엔 
multicast와 동일 
사용X

사용O

replay
Connectable Observable에 버퍼를 추가하고 새로운 구독자에게 최근 이벤트를 전달하는 방법 
PublishSubject는 별도의 버퍼를 가지고 있지 않아 불가능 
ReplaySubject 사용

연산자 사용
replayAll은 구현에 따라 메모리 사용량이 급등하므로 특별한 일이 없다면 사용 비추천 

refCount
- 구독자가 없을 때 옵저버블 시퀀스의 실행을 중단하고, 구독자가 처음 생길 때 시퀀스를 자동으로 시작해주는 연산자
 
- ObservableType 익스텐션에 구현된 다른 연산자들과 달리 
ConnectableObservableType 에 구현됨 
- connect를 직접 할 필요 없음
 
RefCount Observable
- 내부에 Connectable Observable을 유지하면서 새로운 구독자가 추가되는 시점에 자동으로 connect 메소드 호출
 
- 구독자가 구독을 중지하고 더 이상 다른 구독자가 없다면 Connectable Observable에서 시퀀스를 중지
 
- 새로운 구독자가 추가되면 다시 connect 메소드 호출
 

share
- 구독을 공유하는 연산자
 
refCount 옵저버블을 리턴함에 유의하자

 
첫번째 파라미터: 버퍼의 크기
- 생략시 구독자는 구독 이후의 이벤트만 전달받음
 
 
두번째 파라미터: subject의 수명을 결정

whileConnected: 각 connection마다 별도의 subject 사용 
forever: 각 connection은 하나의 동일한 subject 공유 
 

- 파랑, 빨강은 dispose 되기 전에 구독했기때문에 하나의 subject 공유 -> 빨강이 3부터 시작함
 
- 검정은 이미 파랑, 빨강이 공유하는 subject가 dispose되어 없기 때문에 새로운 subject가 생성되어 사용됨 -> 0부터 시작
 

- replay 파라미터를 설정한 경우(여기선 replay: 5)
 

- scope를 forever로 설정한 경우
- 하나의 subject를 공유하므로 이전의 이벤트까지 전부 전달받는다.
 
 
- 검정이 5가 아닌 0부터 시작하는 이유: 시퀀스가 중지된 다음 새로운 구독자가 추가되면 새로운 시퀀스가 시작되기 때문
 
- 앞에 next(0)~next(4) 이벤트는 버퍼에 저장되어있어, 함께 전달됨