StateFlow и SharedFlow — когда что использовать Оба горячие, оба из coroutines и оба собираются из UI. Но путаница между ними стоит багов. StateFlow — это состояние. У него всегда есть текущее значение, и новый подписчик получает его сразу при подписке. Хорошо для UI state: экран подписался — получил актуальные данные, не ждёт следующего emit. private val _uiState = MutableStateFlow<UiState>(UiState.Loading) val uiState: StateFlow<UiState> = _uiState.asStateFlow() SharedFlow — это события. Он ничего не хранит по умолчанию и не гарантирует значение при подписке. Подходит для одноразовых сигналов: навигация, snackbar, ошибка. private val _events = MutableSharedFlow<Event>() val events: SharedFlow<Event> = _events.asSharedFlow() viewModelScope.launch { _events.emit(Event.NavigateTo(Screen.Home)) } Часто можно увидеть ошибку использования StateFlow для событий. Экран пересоздался, подписался и сразу получил последнее значение — навигация срабатывает повторно или snackbar показывается второй раз. С SharedFlow этого не происходит. Обратная ошибка — использовать SharedFlow для UI state. При пересоздании экрана он не получит текущее состояние, только следующий emit. Экран остаётся пустым. Простое правило: если нужно хранить и отдавать текущее состояние, то используем StateFlow. А если нужно отправить сигнал, который обрабатывается один раз, подойдет SharedFlow. #mobilevk #android #kotlin