Flow и каналы

Flow — это холодный асинхронный поток: описание того, откуда берутся значения, а не сами значения. Билдер flow { ... } не делает ничего, пока к нему не придёт терминальный оператор collect; каждый новый коллектор запускает производителя заново, со своим независимым прогоном. Это отличает Flow от горячих потоков — StateFlow и SharedFlow, — которые живут и испускают значения независимо от наличия слушателей, и от Channel, горячей очереди для передачи значений между корутинами, где каждый элемент достаётся ровно одному получателю. Обратное давление здесь не отдельная машинерия, а прямое следствие того, что emit и collect — suspend-функции: медленный коллектор просто приостанавливает производителя.

Главный водораздел темы — холодное против горячего, и почти все ловушки живут ровно на нём. Холодный Flow не кэширует значений и не делится прогоном между коллекторами (два коллектора — два запуска). Промежуточные операторы (map, filter, catch) ленивы: они лишь строят цепочку и выполняются внутри корутины коллектора, поэтому flowOn меняет контекст только для upstream — того, что объявлено выше него, — и не может увести сам collect с вызывающего диспетчера. Горячий StateFlow всегда хранит одно текущее значение, склеивает быстрые эмиссии и отбрасывает значение, равное предыдущему (equals) — это состояние, а не события; для одноразовых событий берут SharedFlow, который ничего не дедуплицирует. А Channel нужен там, где значение обязано достаться одному потребителю, а не всем сразу. Разбор по слоям — ниже.

Карта темы

• Холодный Flow — почему производитель не запускается до collect и перезапускается заново для каждого коллектора, и чем это отличается от одного значения suspend-функции.
• Операторы Flow — промежуточные операторы строят ленивую цепочку, терминальные её запускают, а catch ловит только то, что выше по потоку.
• flowOn и сохранение контекста — почему flowOn влияет только на upstream, не трогает коллектор и заменяет запрещённый withContext внутри flow { }.
• Обратное давление — приостановка emit как встроенный механизм и как buffer, conflate и collectLatest его меняют.
• StateFlow — горячий держатель одного значения, склейка, отбрасывание дубликатов через equals и превращение холодного потока в состояние через stateIn.
• SharedFlow — настраиваемый горячий broadcast с replay и буфером, почему StateFlow — его частный случай и зачем брать именно его для событий.
• Channel — горячая очередь с приостановкой, доставка каждого элемента одному получателю и обязанность закрыть или потребить, иначе утечка.
• Flow против Channel — холодный конвейер против горячей передачи, правило «сначала Flow» и роль callbackFlow как моста.

Частые ошибки и ловушки

Значение для собеседований

Flow — это раздел, где кандидата проверяют на модель исполнения, а не на знание имён операторов. Ключевой вопрос темы — «холодный он или горячий и что это значит физически»: холодный Flow ничего не делает до collect и перезапускается на каждого коллектора, горячий StateFlow/SharedFlow живёт сам по себе. Из этого одного различия выводятся и ленивость операторов, и то, почему flowOn не трогает коллектор, и почему StateFlow теряет повтор. Интервьюер обычно ведёт от «чем Flow лучше suspend-функции» к «почему UI подвисает несмотря на flowOn» и «почему второй одинаковый toast не доходит» — три ловушки на одну и ту же модель.

Что обычно проверяют:

• Что значит «холодный»: когда запускается производитель и что видят два коллектора одного Flow.
• Когда реально выполняются промежуточные операторы и какие операторы терминальные.
• Что именно ловит catch и почему ошибку внутри collect он пропускает.
• Направление flowOn: почему он влияет только на upstream и не может увести collect.
• Как buffer, conflate и collectLatest меняют поведение при быстром производителе.
• Разницу StateFlow и SharedFlow и почему StateFlow — неверный носитель для событий.
• Как Channel доставляет элементы двум получателям и когда брать Channel вместо Flow.

Типичный неверный ответ: «холодный Flow вычисляет значения один раз и раздаёт их всем коллекторам, как кэш». Отсюда кандидат делает вывод, что два коллектора делят один прогон, что SharedFlow — это тот, кто перезапускает производителя, и что flowOn в конце цепочки покроет и collect. На деле всё наоборот: холодный Flow ничего не кэширует и запускает производителя заново для каждого коллектора; SharedFlow горячий и делит один поток эмиссий; а flowOn меняет контекст только для того, что объявлено выше него, и коллектор всегда остаётся на вызывающем диспетчере.