Вопросы на собеседовании: Android-разработчик

Структурированная конкурентность связывает время жизни корутин с явным scope и его иерархией Job.

• Родитель не завершается, пока не завершатся все его дочерние корутины.
• Отмена scope распространяется на дочерние корутины, поэтому работа не переживает своего владельца.
• Необработанная ошибка дочерней корутины обычно отменяет родителя и соседние дочерние корутины.
• Билдеры вроде coroutineScope сохраняют эту структуру, не блокируя текущий поток.

CoroutineScope предоставляет CoroutineContext для запуска корутин, а Job представляет их жизненный цикл.

• CoroutineContext состоит из элементов, таких как Job, диспетчер, имя и обработчик исключений.
• Билдер наследует контекст scope и добавляет или заменяет элементы, переданные этому билдеру.
• Новая корутина обычно создаёт дочерний Job, связанный с Job из унаследованного контекста.
• Отмена Job у scope отменяет дерево корутин с корнем в этом scope.

Используйте супервизию, когда соседние дочерние корутины должны падать независимо, оставаясь под управлением одного родителя.

• С обычным Job необработанная ошибка дочерней корутины отменяет родителя и остальных его детей.
• С SupervisorJob ошибка одного ребёнка не отменяет автоматически соседние корутины или супервизор.
• Каждая дочерняя корутина под супервизией должна явно отдать или обработать свою ошибку, потому что супервизор не превращает её в успех.
• supervisorScope даёт такую же изоляцию ошибок внутри ограниченного suspend-блока.

Выбирайте диспетчер по типу работы, а не создавайте потоки вручную.

• Dispatchers.Main выполняет UI-работу в главном потоке Android, а Main.immediate может выполниться сразу, если вызов уже сделан из него.
• Dispatchers.IO предназначен для блокирующего ввода-вывода и может расширяться сильнее пула для CPU-задач.
• Dispatchers.Default рассчитан на CPU-нагрузку, например парсинг или вычисления.
• Хорошо спроектированная suspend-функция сама использует withContext, когда ей нужно перенести блокирующую или тяжёлую вычислительную работу.

Отмена корутин кооперативна, потому что корутина останавливается только после того, как заметит отмену своего Job.

• Стандартные suspend-функции проверяют отмену и выбрасывают CancellationException.
• CPU-циклы без точек приостановки должны периодически вызывать ensureActive или yield.
• CancellationException обычно следует пробрасывать дальше, а не превращать в доменную ошибку.
• Очистку, которая обязана приостанавливаться, можно выполнить в finally, используя NonCancellable только для этого ограниченного участка.

launch сообщает о необработанном исключении сразу, а async хранит его до ожидания результата Deferred.

• Корневой launch может передать исключение в CoroutineExceptionHandler после применения обычных правил распространения.
• await повторно выбрасывает исключение, сохранённое async, в ожидающем коде.
• Ошибка дочерней корутины всё равно участвует в отмене родителя, даже если её Deferred никто не ожидает.
• try и catch следует располагать вокруг suspend-вызова или точки await, где восстановление действительно имеет смысл.

Suspend-функция может приостановиться, не занимая текущий поток, а блокирующая функция удерживает поток до завершения.

• Модификатор suspend разрешает точки приостановки, но сам по себе не переносит работу с диспетчера вызывающего кода.
• Suspend-функция всё ещё может блокировать, если напрямую вызывает блокирующий API.
• Блокирующий ввод-вывод следует изолировать через withContext с подходящим диспетчером.
• Приостановка сохраняет локальный поток управления с помощью continuation вместо обязательных колбэков.

withContext создаёт производный контекст для suspend-блока, а после него возобновляет вызывающий код в исходном контексте.

• Переданные элементы заменяют элементы с теми же ключами из текущего CoroutineContext, например диспетчер.
• Вызов приостанавливается до завершения блока и напрямую возвращает его результат.
• Он сохраняет структурированную конкурентность, потому что вызывающий код ждёт блок и его дочерние корутины.
• Отмена остаётся связанной с вызывающей корутиной, если Job не заменён намеренно, что требуется редко.

Обычный Flow холодный, потому что его producer-блок запускается отдельно для каждого коллектора.

• Создание Flow не выполняет его upstream-код.
• Каждая подписка повторяет upstream-работу, если Flow явно не разделён через stateIn или shareIn.
• Каждый коллектор получает значения от собственного выполнения flow builder.
• Сбор приостанавливается до завершения Flow или отмены собирающей корутины.

StateFlow моделирует наблюдаемое состояние, а SharedFlow представляет настраиваемый горячий поток для рассылки.

• У StateFlow всегда есть текущее значение, которое новый коллектор получает сразу.
• StateFlow подавляет обновления, равные предыдущему значению по проверке equality.
• SharedFlow настраивает replay, дополнительную ёмкость буфера и поведение при переполнении без обязательного начального значения.
• Оба потока не завершаются только из-за исчезновения коллекторов, поэтому временем их жизни управляет владеющий scope.

flowOn меняет контекст корутины для upstream-операторов, расположенных перед ним.

• Downstream-сбор продолжается в контексте коллектора, сохраняя безопасность контекста.
• При смене диспетчера flowOn создаёт границу из корутины и канала между upstream и downstream.
• Несколько вызовов flowOn действуют на соответствующие upstream-сегменты, а не глобально на всю цепочку.
• Внутри flow builder не следует вручную переключать контекст для emit, потому что Flow обеспечивает сохранение контекста.

Выбирайте оператор по тому, должен ли новый ввод отменять, заменять или дополнять предыдущую работу.

• mapLatest отменяет текущее преобразование, когда приходит новое upstream-значение.
• flatMapLatest переключается на новый внутренний Flow и отменяет сбор предыдущего.
• flatMapMerge параллельно собирает несколько внутренних Flow в пределах ограничения конкурентности.
• Обычного map достаточно, когда каждое значение преобразуется в один результат, не являющийся Flow, и все преобразования должны завершиться.

Эти операторы меняют взаимодействие медленного коллектора с более быстрым upstream-производителем.

• buffer позволяет upstream-производству и downstream-обработке перекрываться через канал.
• conflate сохраняет только последнее ожидающее значение, пока коллектор занят.
• collectLatest отменяет текущий блок коллектора при поступлении нового значения.
• Conflation подходит, только если промежуточные значения можно заменить и они не являются обязательными событиями.

Собирайте UI-потоки только пока соответствующий Lifecycle находится в активном состоянии.

• repeatOnLifecycle запускает блок сбора в выбранном состоянии и отменяет его, когда lifecycle опускается ниже этого состояния.
• При повторном входе lifecycle в состояние создаётся новый блок, поэтому upstream должен допускать повторный сбор.
• Несколько Flow для параллельного сбора следует запускать отдельными дочерними корутинами внутри repeat-блока.
• В Compose адаптер collectAsStateWithLifecycle обеспечивает соответствующий lifecycle-aware сбор в State.

Используйте callbackFlow, чтобы преобразовать API на колбэках в холодный Flow с безопасной конкурентной отправкой.

• trySend передаёт значения колбэка в канал Flow, не требуя приостановки колбэка.
• awaitClose сохраняет producer активным и снимает регистрацию колбэка при завершении сбора.
• Ошибка регистрации должна закрывать канал с причиной, а не отправлять поддельное значение данных.
• Адаптер запускается для каждого коллектора отдельно, если результирующий Flow явно не разделён.

ViewModel должен владеть состоянием экрана и presentation-логикой, не завися от конкретного экземпляра View.

• Он переживает изменения конфигурации, пока его Activity, Fragment или navigation entry остаётся логически живым.
• Он отдаёт неизменяемое наблюдаемое состояние и принимает действия пользователя через явные методы или intents.
• Он делегирует доступ к данным и доменные правила репозиториям или use case, а не превращается в service locator.
• Он не должен хранить ссылки на Activity, Fragment, View или другой короткоживущий Context.

viewModelScope является CoroutineScope, привязанным к жизненному циклу и отменяемым при очистке ViewModel.

• Его SupervisorJob позволяет соседним корутинам падать независимо.
• Главный диспетчер подходит для запуска presentation-работы, а нижние слои отвечают за main-safe выполнение.
• Корутины переживают изменения конфигурации, потому что сохраняется тот же экземпляр ViewModel.
• Scope не переживает смерть процесса, поэтому для долговечного или восстанавливаемого состояния нужен другой механизм.

Предпочитайте StateFlow для состояния на корутинах, а LiveData остаётся полезной для существующих API и кодовых баз, построенных вокруг Lifecycle.

• StateFlow имеет явное текущее значение и поддерживает полный набор операторов Flow.
• LiveData автоматически ограничивает вызовы наблюдателя согласно состоянию LifecycleOwner.
• Для StateFlow нужен lifecycle-aware адаптер, такой как repeatOnLifecycle или collectAsStateWithLifecycle.
• Лучше преобразовать тип на границе UI, чем независимо поддерживать одно состояние сразу в обоих типах.

ViewModel должен изменять приватное состояние и отдавать потребителям только read-only StateFlow.

• MutableStateFlow сохраняет операции записи внутри компонента, владеющего переходами состояния.
• asStateFlow запрещает вызывающему коду присваивать произвольные значения без создания второго потока.
• Атомарная функция update предотвращает потерю изменений, когда преобразования могут выполняться конкурентно.
• Единая неизменяемая модель состояния делает отрисовку и тесты переходов детерминированными.

Постоянные условия относятся к состоянию, а для неповторяемых эффектов нужна явная модель доставки.

• StateFlow подходит для отображаемых фактов, таких как контент, выбор и статус загрузки.
• Повтор navigation-события или snackbar после пересоздания может ещё раз выполнить уже завершённое действие.
• Channel с receiveAsFlow даёт очередь с доставкой одному потребителю, а настроенный SharedFlow поддерживает рассылку.
• Если эффект представляет необработанный бизнес-факт, моделируйте и подтверждайте этот факт в состоянии, а не скрывайте его как временное событие.