Stories by hongbeom on Medium

[정리] — 코틀린 Flow 사용하기 (Android Dev Summit 2021)
Android Dev Summit 2021
https://medium.com/media/202156a9b2b37fdd052378c4cb581308/href
본 글은 Android Dev Submmit 2021 — Kotlin Flows in practice 영상을 한국어로 정리한 글입니다.
Flow에서 생산자는 데이터를 Flow에 입력하고 소비자는 Flow에서 데이터를 수집하는 역할을 가지고 있습니다.
Android에선 데이터 소스나 레포지토리가 전형적인 생산자이고, 최종적으로 화면에 데이터를 표시하는 UI가 소비자 역할을 합니다.
Creating Flows
그렇다면 우선 Flow를 생성하는 방법을 알아보겠습니다. 대부분의 경우 Flow를 직접 만들 필요는 없으며, 데이터 소스 라이브러리는 보통 Flow와 통합되어 있습니다.
DataStore, Retrofit, Room, WorkManager 등이 존재합니다. 이들은 댐 역할을 수행하며 Flow를 사용하여 데이터를 제공하고, 개발자는 구현 방법을 몰라도 파이프에 연결만 하면 데이터를 사용할 수 있습니다.
Room을 예시로 들어보겠습니다.
위 코드에서 List<Codelab> 타입의 Flow를 노출하여 데이터베이스 변경 사항을 알리고 있습니다. Room 라이브러리가 생산자 역할을 맡아 업데이트가 있을 때마다 쿼리 내용을 전달합니다.
만약 flow를 직접 만들어야 한다면, 우리는 여러 가지 방법을 사용할 수 있습니다.
그 중 하나가 Flow 빌더입니다. 수시로 앱에서 온 메시지를 확인하려는 예시를 가정으로 들어봅시다.
우리는 메시지 리스트 타입의 flow로 사용자 메시지를 노출할 수 있습니다. 이 때 flow를 만드려면 flow 빌더를 사용해야 합니다. flow 빌더는 supend 함수를 호출 할 수 있습니다. 이는 flow가 코루틴 컨텍스트에서 실행되기 때문에 가능합니다.
내부에서 while(true) 루프로 반복하게 한 후, 먼저 API에서 메시지를 가져옵니다.
그리고 emit 함수를 통해 가져온 메시지를 노출합니다. 이렇게 하면 컬렉터가 아이템을 받을 때까지 코루틴을 중단시킵니다.
마지막으로 일정 시간 코루틴을 중단합니다. 위 flow는 동일한 코루틴에서 연산을 순차적으로 진행하며 관찰자가 사라지고 아이템 수집이 중단되면 멈추게 됩니다.
flow 빌더에 전달된 suspend 블록은 생산자 블록이라고도 합니다.
Android에서 생산자와 소비자 간의 계층은 요구 사항에 맞게 데이터 스트림을 수정할 수 있으며 flow를 변환하려면 중간 연산자를 사용하면 됩니다.
latestMessages 스트림이 flow의 시작점이라고 가정한다면 map 연산자를 사용해서 데이터를 다른 타입으로 변환할 수 있습니다.
이를 통해 더 좋은 추상화를 제공할 수 있게 됩니다.
각 연산자는 기능에 따라 데이터를 전송하는 새로운 flow를 생성합니다.
filter를 사용하여 중요한 알림이 포함된 해당 메시지의 flow를 가져올 수도 있습니다.
그렇다면 스트림에서 발생하는 에러는 어떻게 처리할 수 있을까요?
catch 연산자는 업스트림 flow에서 발생할 만한 예외를 찾아냅니다.
업스트림 flow란 생산자 블록에서 생성한 flow이며 현재 연산자 전에 이들을 호출합니다.
마찬가지로 현재 연산자 이후에 발생하는 모든 것을 다운스트림 flow라고 합니다.
catch는 필요하거나 새 값을 다시 전송할 때 필요에 따라 에러를 발생시킬 수도 있습니다.
위 예시에서는 IllegalArgumentException이 발생할 경우 익셉션을 발생시키지만, 다른 예외가 발생하면 빈 리스트를 전달합니다.
Observing Flows
이제 수집하는 방법에 대해 알아보겠습니다.
일반적으로 flow 수집은 화면에 데이터를 표시하기 위해 UI 계층에서 일어납니다.
리스트에 최신 메시지를 표시한다는 가정하에 우리는 terminal 연산자를 사용해서 값을 수신하기 시작해야 합니다.
스트림의 모든 값을 전송 즉시 가져오려면 collect를 사용하면 됩니다. collect는 새로운 값이 생길 때마다 호출되는 함수를 파라미터로 받으며 suspend 연산자이기 때문에 코루틴 안에서 실행되어야 합니다.
반면, intermediate(중간) 연산자는 일련의 연산자만 설정하며 아이템을 flow로 전송했을 때 간격을 두고 연산자를 실행합니다.
위 코드에선 userMessages에서 collect를 호출할 때마다 새로운 flow가 생성되고 있습니다. 생산자 블록은 정해진 간격에 따라 API에서 메시지를 새로 고침할 것입니다.
이런 flow를 코루틴 용어로 Cold flow라고 합니다. 이는 필요에 따라 생성되고 관찰되는 중에만 데이터를 전송하기 때문입니다.
Flows in Android UI
이제 Android UI에서 최적의 방법으로 flow를 수집하는 방법을 알아보겠습니다.
고려해야 할 것은 다음과 같습니다.
앱이 백그라운드에 있을 때 리소스를 낭비하지 않는 것
구성 변경 (Configuration Change)
MessagesActivity에서 화면에 메시지 리스트를 표시해야한다고 가정해봅시다.
flow가 얼마나 오래 수집되어야 할까요? 화면에 UI가 표시되지 않을 때는 flow에서 수집을 중단해야 합니다.
여기에 여러 가지 옵션이 있는데, 모든 방식이 수명 주기를 인지합니다.
asLiveData flow 연산자는 flow를 LiveData로 변환해서 UI가 화면에 표시되는 동안에만 아이템을 관찰합니다.
UI에서는 평소처럼 LiveData를 소비하기만 하면 됩니다.
약간의 편법을 사용해 볼 수도 있습니다. UI 레이어에서 flow를 수집할 때 repeatOnLifecycle을 사용하는게 좋습니다. 이는 Lifecycle.State를 파라미터로 받는 suspend 함수입니다. 이 API는 수명 주기를 인식하며 수명 주기가 해당 상태에 도달하면 블록을 전달할 새로운 코루틴이 자동으로 시작되고, 해당 수명 주기 아래로 떨어지면 취소됩니다.
이 API는 수명 주기가 초기화 될 때 (onCreate) 호출하는 것이 좋습니다. 또한 수명 주기가 파괴될 때까지(onDestroy) 실행을 다시 시작하지 않습니다.
여러 flow를 수집해야 할 경우, repeatOnLifecycle 블록에서 launch를 사용하여 여러 코루틴을 생성해야 합니다.
또한 flowWithLifecycle 연산자는 수집할 flow가 하나뿐일 경우 repeatOnLifecycle 대신 사용할 수 있습니다.
이제 시각적으로 작동 원리를 확인해보겠습니다. 사용자가 홈 버튼을 눌렀을 때 백그라운드로 전송되고 액티비티에서 onStop이 호출된 다음, onStart가 호출되었을 때 다시 앱이 열립니다.
이 때 STARTED 상태로 repeatOnLifecycle을 호출하면 UI가 화면에 표시되는 동안 flow 전송을 처리하고 앱이 백그라운드로 이동하면 수집이 취소됩니다.
repeatOnLifecycle과 flowWithLifecycle API는 lifecycle-runtime-ktx:2.4.0 라이브러리에 추가된 API입니다.
이는 신규 API이므로 다른 방식으로 UI에서 flow를 수집할 수도 있습니다.
예를 들어 lifecycleScope에서 시작한 코루틴에서 바로 수집할 수도 있습니다. 이 방식의 flow 수집은 위험할 수 있습니다. 이는 백그라운드에 앱이 위치해도 flow에서 수집을 중단하지 않습니다.
사실 위 방식 뿐만 아니라 LifecycleCoroutineScope.launchWhenX API에서도 비슷한 문제가 있습니다.
lifecycleScope.launch에서 flow를 수집하는 경우 액티비티가 백그라운드에 있을 때도 계속 flow가 업데이트 됩니다. 이는 낭비일 뿐 아니라 위험하기도 합니다. 앱이 백그라운드일 때 다이얼로그를 표시하면 크래시를 일으킬 것입니다.
이 문제를 해결하려면 onStart에서 수동으로 수집을 시작하고 onStop에서 수집을 중단해야 합니다. 하지만 repeatOnLifecycle을 사용하면 이 같은 보일러플레이트 코드를 제거할 수 있습니다.
launchWhenStarted를 대안으로 고려할 경우엔 lifecycleScope.launch보단 나은 편입니다. 왜냐면 앱이 백그라운드에 있을 때 flow 수집을 중단하기 때문입니다. 하지만 이 방식은 flow 생산자를 계속 활성화시켜서 화면에 표시되지 않을 아이템으로 메모리를 채울 수 있는 아이템으로 백그라운드에서 계속 전달할 수 도 있습니다.
UI에서 flow 생산자의 구현 방법을 알 수 없으므로 repeatOnLifecycle이나 flowWithLifecycle을 안전하게 사용하는 것을 권장합니다.
이제 앱에서 구성 변경이 일어날 경우의 몇 가지 요령을 알아봅시다.
flow를 뷰에 노출하면 수명 주기가 서로 다른 두 요소 사이에 데이터를 전달해야 한다는 걸 고려해야 합니다. 특히 프래그먼트에서 까다로울 수 있습니다.
기기가 회전되었거나 Configuration Change 이벤트를 수신하면 모든 액티비티를 다시 시작하지만 ViewModel은 그렇지 않습니다.
그래서 ViewModel에서 모든 flow를 노출하는 것은 아닙니다. 예를 들어 위와 같은 cold flow가 있다고 가정해봅시다. cold flow는 처음으로 수집될 때마다 다시 시작하기 때문에 레포지토리는 한 번 회전 후 다시 호출될 것입니다.
때문에 우리에겐 일종의 버퍼가 필요해집니다. 데이터를 보관하고 있다가 여러 컬렉터 사이에 공유하면 됩니다. 재생성 횟수와는 상관없이 말입니다.
StateFlow는 바로 이런 목적으로 만들어졌습니다.
StateFlow는 물로 비유하면 물탱크에 가깝습니다. 컬렉터가 없더라도 데이터를 보관하고 있습니다. 일회용 수집이 아닐 수 있으므로 액티비티나 프래그먼트와 함께 사용하는게 안전합니다.
위의 예시에서 StateFlow의 여러 버전을 사용하며 필요할 때마다 값을 업데이트 할 수 있는 것을 볼 수 있습니다. 하지만 이것이 반응형이라고 보긴 어려울 것입니다.
우리는 flow를 StateFlow로 변환하여 이를 개선할 수 있습니다. 이렇게 하면 StateFlow가 업스트림 flow에서 모든 업데이트를 받아서 최신 값을 저장하게 됩니다. 콜렉터가 많거나 없을 수 있으므로 ViewModel에서 사용하기에 적당합니다.
여러 타입의 flow가 있지만 StateFlow를 매우 정확하게 최적화할 수 있으므로 이 방법을 권장드립니다.
flow를 StateFlow로 변환할 때, stateIn 연산자를 함께 사용할 수 있습니다. initialValue는 값이 항상 들어있어야 하기 때문에 사용할 수 있으며 scope는 코루틴 공유가 시작되는 시점을 제어하는데 viewModelScope를 사용할 수 있습니다.
started는 흥미로운 파라미터입니다. WhileSubscribed(5000)의 의미를 알아보기 위해 먼저 두 가지 케이스를 살펴보겠습니다.
첫 번째 예시는 flow의 컬렉터인 액티비티가 일정 시간 파괴되었다가 다시 생성되는 화면 회전입니다.
두 번째 예시는 홈으로 이동해서 앱을 백그라운드로 보내는 것입니다.
회전 시나리오에서는 최대한 빠르게 전환하기 위해 flow를 다시 시작해서는 안됩니다. 하지만 두 번째 시나리오에서는 배터리와 다른 리소스를 아끼기 위해 모든 flow를 중단해야 합니다. 그렇다면 어떤 시나리오인지 어떻게 감지할 수 있을 까요?
바로 시간 초과입니다.
StateFlow의 수집이 중단되었을 때 모든 업스트림 flow를 중단하진 않습니다. 오히려 가령 약 5초 정도 잠시 기다립니다. 시간 초과 전에 flow를 수집하면 업스트림 flow가 취소되지 않습니다.
WhileSubscribed(5000)은 바로 그런 일을 하는 파라미터입니다.
위 그림에서 앱이 백그라운드에 갔을 때 반응을 시각적으로 확인해볼 수 있습니다. 홈 버튼을 누르기 전에 뷰가 업데이트를 수신하고 StateFlow는 정상적으로 업데이트 flow를 생성합니다.
이제 뷰가 중단되면 수집이 즉시 종료됩니다. 그러나 StateFlow는 우리가 설정한 옵션으로 인해 업스트림 flow를 중단하는데 5초가 걸립니다. 그리고, 제한 시간이 지나 업스트림 flow가 취소됩니다.
사용자가 앱을 다시 열 경우 업스트림 flow가 자동으로 다시 시작됩니다.
하지만 회전 시나리오에서 뷰는 잠시 중단됩니다. 따라서 StateFlow는 절대 복원되지 않고 모든 업스트림 flow를 활성상태로 유지하며 아무 일도 없었던 것처럼 사용자에게 회전 인스턴스를 보냅니다.
즉 StateFlow를 사용하여 ViewModel에서 flow를 노출하거나 asLiveData를 사용하여 이와 동일한 작업을 수행하는 것이 좋습니다.
Testing Flows
flow 테스트는 데이터 스트림이라 까다로울 수 있기에 몇 가지 요령에 대해 살펴보겠습니다. 먼저 두 가지 시나리오를 살펴봅시다.
첫 번째는 테스트 대상이 무엇이든 UnitUnderTest가 flow를 받는 경우입니다.
이 경우엔 종속성을 가짜 생산자로 교체하여 테스트하는 것이 편리합니다. 예를 들어 위 그림처럼 가짜 레포지토리를 만들어서 각 테스트 사례에 필요한 것을 전송할 수 있을 것입니다.
간단하게 cold flow의 예시를 살펴보겠습니다. 테스트 자체는 테스트 결과에 대한 assertion을 만듭니다. 이는 flow 혹은 다른 것이 될 수 도 있을 것입니다.
두 번째는 UnitUnderTest가 flow를 노출하고 이 값이나 값 스트림을 인증하고 싶다면 여러 가지 방법으로 수집할 수 있습니다.
flow에서 first() 메소드를 호출하면 첫 아이템을 수신하고 수집을 중단할 때까지 계속 수집합니다.
또한 take(5) 같은 연산자로 toList 터미널 연산자를 호출하여 메시지를 5개만 수집할 수도 있습니다.
Resources
더 많은 내용을 살펴보고 싶다면 위 링크를 참조해주세요.
읽어주셔서 감사합니다🙌
[정리] — 코틀린 Flow 사용하기 (Android Dev Summit 2021) was originally published in hongbeomi dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

[정리] — 코틀린 Flow 사용하기 (Android Dev Summit 2021)

댓글