학습‐Channel, SharedFlow, StateFlow

저희 프로젝트는 이벤트를 처리하는데 SharedFlow를 사용하지 않고 Channel을 사용했습니다. 이 글에서 Flow, SharedFlow, Channel의 특징을 가지고 있는지 정리해보고 이벤트 처리에 왜 Channel을 사용했는지에 대한 것을 정리해보겠습니다.

Flow

Flow는 콜드 스트림으로 데이터를 소비하는 collect가 호출될 때 데이터를 발행하는 특성을 가지고 있습니다. 특징

• 콜드 스트림: 구독할 때 데이터를 생성합니다.
• 구독자가 존재하지 않으면 데이터는 생성되지 않습니다.
• 저희 프로젝트에서는 UseCase나 Repository 데이터를 발행할 때 사용합니다.

SharedFlow

SharedFlow는 HotStream입니다. 그래서 구독자가 없더라도 데이터를 발행합니다. 특징

• 핫 스트림: 구독자가 없어도 데이터가 발행됩니다.
• replay 설정 가능: 발행된 데이터를 일정 개수만큼 보관하여 새로운 구독자에게 전달할 수 있습니다.
• StateFlow와의 차이점
  • replay를 1로 설정하면 stateFlow와 유사하나 초기값을 갖지 않아도 된다는 점이 다릅니다.

문제점 SharedFlow는 기본적으로 핫 스트림이기 때문에 구독자가 없는 시점에서 발행된 이벤트는 유실될 수 있습니다. 예를 들어, 화면 전환이나 홈 화면 이동 중에 이벤트가 발생할 경우 구독이 해제되었기 때문에 해당 이벤트가 소비되지 않고 사라질 수 있습니다.

ex) 사용자가 커뮤니티 화면에서 저장 버튼을 눌렀으나 곧바로 홈 화면으로 이동한 경우 이벤트는 발생했으나 홈 화면에서는 이벤트를 구독하지 않으므로 유실됩니다.

Channel

Channel은 1:1 통신을 기반으로 하는

특징

• 구독자가 없으면 이벤트를 버퍼에 저장하여 대기합니다(0일 때는 제외)
• 소비자(Collector)가 준비되면 발행된 데이터를 처리합니다.
• 기본적으로 1:1 통신 모델을 지원하며 한 번 처리된 이벤트는 다른 소비자가 받을 수 없습니다.

이벤트 처리에 Channel을 선택한 이유

1. SharedFlow의 이벤트 유실 문제 해결 SharedFlow는 구독자가 없을 경우 이벤트가 유실될 수 있지만, Channel은 소비자가 준비되지 않은 경우에도 이벤트를 버퍼에 저장해 대기하므로 이벤트 유실 문제가 발생하지 않습니다.

2. 1:1 통신 모델로 충분한 상황 저희 프로젝트에서는 하나의 ViewModel에서 이벤트를 발행하고, 해당 ViewModel의 소비자가 이벤트를 수집하기 때문에 1:1 통신 모델인 Channel이 적합했습니다.

3. Lifecycle과 무관한 이벤트 처리 SharedFlow는 구독이 Lifecycle에 종속적이므로, 화면이 전환되거나 백그라운드로 이동하면 이벤트가 수집되지 않을 수 있습니다. 반면, Channel은 이벤트가 대기 상태로 유지되므로, Lifecycle과 관계없이 안전하게 이벤트를 처리할 수 있습니다.