Собеседование Android-разработчика крутится вокруг идиом Kotlin, корутин и жизненного цикла платформы — большинство senior-вопросов на самом деле проверяют, понимаете ли вы, что процесс могут убить в любой момент. Ниже — вопросы, которые задают чаще всего, каждый с эталонным ответом. Middle: более глубокое понимание, оптимизацию и реальные рабочие ситуации.
Корутина — приостанавливаемое вычисление, которое планирует рантайм Kotlin; поток планирует ОС. Приостановка освобождает поток, а не блокирует его, поэтому тысячи корутин делят небольшой пул. Отсюда следствие: блокирующий вызов внутри корутины полностью обесценивает затею — он держит тот самый поток, который должен был освободиться.
Что каждая корутина, запущенная в области, становится её потомком: отмена области отменяет всех, а сама область не завершится, пока они не закончатся. На практике это viewModelScope — работа прекращается, когда ViewModel очищается. Запуск в GlobalScope от этого отказывается, и так работа переживает экран, который её начал.
Flow холодный: он производит значения при сборе, отдельно для каждого сборщика. StateFlow горячий, всегда держит текущее значение и отдаёт его каждому новому сборщику — именно это нужно состоянию UI. SharedFlow горячий без текущего значения и подходит событиям, которые не должны повторяться: команде навигации или снекбару.
Compose перезапускает те composable, у которых изменились входы. Слишком часто это происходит, когда лямбда или нестабильный тип пересоздаётся на каждой перерисовке родителя, или когда целый экран читает одно часто меняющееся значение. Лечится remember, поднятием состояния так, чтобы его читала только нуждающаяся часть, и стабильными типами, а счётчики рекомпозиций в Layout Inspector показывают, где именно.
Потому что контекст Activity привязан к экрану, и всё долгоживущее, что его держит, удерживает в памяти весь этот экран. Обычные случаи — синглтон, инициализированный Activity, статическая ссылка, слушатель, которого не отписали. Для всего, что переживает экран, нужен контекст приложения — но он не умеет надувать вью с темой, из-за чего ошибку и совершают.
Сначала измерить: adb shell am start -W даёт время холодного, тёплого и горячего запуска, а системный трейс показывает, что выполняется до первого кадра. Обычные причины — работа в Application.onCreate, особенно инициализация SDK, синхронное чтение с диска или из сети и то, что делается на главном потоке, хотя могло подождать до первого кадра.
launch запускает работу и возвращает Job без результата; async возвращает Deferred, который ждут через await. async берут, только когда нужно значение, и запускают обе задачи до того, как ждать любую, если нужна параллельность. async, результат которого не дождались, проглатывает своё исключение — тихий способ потерять падение.
Parcelable — андроидный: вы описываете, как объект пишется и читается, поэтому рефлексии нет и передача данных между компонентами измеримо быстрее. Serializable — маркерный интерфейс из Java: писать почти ничего не нужно, работает медленно и много аллоцирует. В Kotlin спор почти исчезает, потому что @Parcelize генерирует шаблонный код и снимает единственную реальную причину выбирать Serializable.
Doze и App Standby — это система откладывает вашу фоновую работу, когда устройство простаивает или приложением не пользуются, и именно поэтому будильник или сетевой вызов просто не происходят тогда, когда вы ждали. WorkManager — для откладываемой работы, которая обязана рано или поздно выполниться и пережить смерть процесса и перезагрузку: синхронизация, загрузка, уборка. Foreground service — для работы, о которой пользователь знает прямо сейчас, вроде воспроизведения или навигации, и он обязан показывать уведомление. Обычный фоновый сервис вместо этого — способ добиться, чтобы работа тихо перестала выполняться на современном Android.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Middle Android (Kotlin) →