[Android/Flow] LiveData가 아닌 Flow를 사용해야 하는 이유

예전에는,

• LiveData는 생명주기에 종속적이었고, 메인 스레드에서 실행되었기 때문에 Repository에서 사용하기엔 알맞지 않았다.
• 반면 Flow는 생명주기를 인식할 수 없었으나 데이터 스트림을 관리하는 객체로서 확장 함수가 잘 구성되어있었고, 코틀린 코루틴 라이브러리의 일부이기 때문에 Repository에서 사용하더라도 클린 아키텍처에 반하지 않았다.
  • Flow는 coroutine 라이브러리에 포함되어있기 때문에 Repository에서 사용 시 의존성을 추가하지 않아도 된다.

    import kotlinx.coroutines.flow.MutableSharedFlow
    import kotlinx.coroutines.flow.asSharedFlow

  또한,

  Flow는 Cold Stream 방식이다. 연속해서 계속 들어오는 데이터를 처리할 수 없고, collect 되었을 때만 생성되고 값을 반환한다. 만약 하나의 Flow Builder에 대해 다수의 collector가 있다면 collector 하나마다 하나씩 데이터를 호출하기 대문에 비용이 비싼 DB 접근, 서버 통신 등을 수행한다면 여러 번 리소스 요청을 하게될 수 있다.

→ LiveData는 ViewModel, Flow는 Repository에서 사용하는 상호보완적 관계였다.

• 그런데 repeatOnLifecycle 블록에서 데이터를 collect함으로써 생명주기를 인식할 수 있는 StateFlow/SharedFlow가 등장했다.
  • LiveData와 Flow는 ViewModel단에서는 상호대체 가능해졌다.
  → 하지만 Flow가 사용성이 더 높기 때문에(ViewModel과 Repository 두 영역에서 모두 사용할 수 있게 되었기 때문에) LiveData보다는 Flow를 더 선호하게 되었다.
• StateFlow

  StateFlow는 현재 상태와 새로운 상태 업데이트를 수집기에 내보내는 관찰 가능한 상태 홀더 흐름이다. value 속성을 통해서도 현재 상태 값을 읽을 수 있다. 상태를 업데이트하고 Flow에 전송하려면 MutableStateFlow 클래스의 value 속성에 새 값을 할당한다.

  StateFlow는 Hot Flow이다. Flow에서 수집해도 생산자 코드가 트리거되지 않는다.

  즉, StateFlow는 Hot 스트림 방식으로, 소비자의 collect 요청이 없어도 바로 값을 내보내고, 데이터가 업데이트 될 떄마다 데이터를 발행한다.