Собеседование Android-разработчика крутится вокруг идиом Kotlin, корутин и жизненного цикла платформы — большинство senior-вопросов на самом деле проверяют, понимаете ли вы, что процесс могут убить в любой момент. Ниже — вопросы, которые задают чаще всего, каждый с эталонным ответом.
К каждому вопросу — эталонный ответ, с которым можно сравнить свой.
Kotlin делит каждый тип на nullable (String?) и non-nullable (String), и компилятор не даёт обратиться к nullable-значению без проверки, поэтому NullPointerException в основном исчезает. Platform types появляются на границе с Java: Kotlin не знает, может ли Java-метод вернуть null, и доверяет вам. Именно оттуда NPE и приходят — аннотируйте Java-API или считайте их результат nullable в месте вызова.
Data class генерирует equals, hashCode, toString, copy и деструктуризацию по первичному конструктору, поэтому это правильный инструмент для значений, которые сравнивают и копируют, — модели API, состояние UI. Sealed class ограничивает набор наследников известным списком, поэтому when по нему исчерпывающий и компилятор укажет на забытую ветку. Вместе они чисто моделируют состояние экрана: sealed-интерфейс Loading, Content, Error, а данные несут data class.
Структурная конкурентность означает, что каждая корутина принадлежит скоупу и родительской задаче, поэтому отмена родителя отменяет всех детей, а родитель не завершится, пока не завершатся они. Именно это спасает от утёкшей фоновой работы, характерной для голых потоков. В Android viewModelScope отменяется при очистке ViewModel, а lifecycleScope — при завершении жизненного цикла, так что работа останавливается, когда её результат уже некуда применить.
Dispatchers.Main работает на UI-потоке, там трогают вью. Dispatchers.IO — большой эластичный пул для блокирующей работы: диск, сеть, база, — потому что такие потоки в основном ждут. Dispatchers.Default размером с число ядер и предназначен для настоящих вычислений вроде парсинга или сортировки. Блокирующий вызов на Default выедает пул — это самая частая ошибка с диспетчерами.
Flow — холодный асинхронный поток: он начинает производить значения при подписке, и у каждого подписчика своё выполнение. StateFlow горячий и всегда хранит ровно одно текущее значение, что делает его естественным для состояния UI — новый подписчик сразу получает актуальное состояние. LiveData — более старый lifecycle-aware держатель; StateFlow вместе с repeatOnLifecycle закрывает ту же задачу остальным инструментарием корутин, поэтому новый код обычно выбирает его.
Поворот, тёмная тема, смена языка и размера окна уничтожают и пересоздают Activity, чтобы она подгрузила ресурсы под новую конфигурацию. Состояние, которое должно выжить, живёт во ViewModel — она переживает пересоздание. Состояние, которое должно пережить ещё и смерть процесса, идёт в SavedStateHandle, потому что систему никто не обязывает держать ваш процесс в фоне. Проверка этого пути через «Не сохранять активности» отличает надёжное приложение от того, что теряет введённые пользователем данные.
Compose перезапускает composable, когда меняется прочитанный им State, и пропускает те, у кого параметры равны и стабильны. Тормоза идут от нестабильных параметров — обычный List или лямбда, захватившая меняющееся значение, — они ломают пропуск и перезапускают большие поддеревья. Лечится подъёмом состояния к ближайшему общему владельцу, неизменяемыми коллекциями или аннотацией @Immutable, а также отложенным чтением через лямбды, чтобы перезапускалась только фаза layout или draw.
DI избавляет класс от знания о том, как собрать свои зависимости, что делает его тестируемым и держит проводку в одном месте вместо разбросанных синглтонов. Hilt генерирует граф Dagger и привязывает время жизни компонентов к андроидным: @Singleton живёт с приложением, @ViewModelScoped — с ViewModel. Практическая выгода — подменить настоящий репозиторий фейком в тестах, не трогая продакшен-код.
Слой UI держит Compose или View плюс ViewModel, которая отдаёт неизменяемое состояние и принимает события. Слой домена держит юзкейсы и чистые бизнес-правила без импортов Android — именно поэтому он тестируется обычным JUnit. Слой данных держит репозитории, которые выбирают между Room и Retrofit и мапят DTO в доменные модели. Важно тут направление зависимостей: домен ничего не знает ни о данных, ни об UI.
ANR срабатывает, когда главный поток заблокирован примерно на пять секунд на вводе, а для бродкастов и сервисов лимиты жёстче. Типичные причины — обращение к базе или сети на главном потоке, огромный синхронный разбор JSON, конкуренция за блокировку с фоновым потоком. После релиза отчёты ANR в Play Console вместе со снятым стеком главного потока указывают на блокирующий кадр; StrictMode в debug-сборках ловит большую часть этого задолго до релиза.
Повторяющаяся причина — что-то долгоживущее держит Activity или View: статическая ссылка, неотписанный слушатель, внутренний класс с неявной ссылкой на внешний, корутина на GlobalScope. Защита — привязывать работу к lifecycle-aware скоупу, обнулять ссылку на binding в onDestroyView у фрагментов и использовать Context приложения там, где не нужен Context активности. Остальное ловит LeakCanary в debug-сборке, показывая цепочку удержания.
let принимает получателя аргументом и возвращает результат лямбды — подходит для проверки на null и преобразования. run делает то же, но через this, удобен для блока вызовов, возвращающего значение. apply возвращает самого получателя и нужен для настройки объекта. also тоже возвращает получателя, но передаёт его как it, поэтому годится для побочных эффектов вроде логирования. with — не расширение и просто группирует вызовы. Выбор по возвращаемому значению и форме получателя как раз и держит их читаемыми, а не хитрыми.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Android (Kotlin) →