Middle Android (Kotlin) — Вопросы на собеседовании Android разработчика

Что дают data class и sealed class?

Data class генерирует equals, hashCode, toString, copy и деструктуризацию по первичному конструктору, поэтому это правильный инструмент для значений, которые сравнивают и копируют, — модели API, состояние UI. Sealed class ограничивает набор наследников известным списком, поэтому when по нему исчерпывающий и компилятор укажет на забытую ветку. Вместе они чисто моделируют состояние экрана: sealed-интерфейс Loading, Content, Error, а данные несут data class.

Что такое структурная конкурентность в корутинах и зачем нужен scope?

Структурная конкурентность означает, что каждая корутина принадлежит скоупу и родительской задаче, поэтому отмена родителя отменяет всех детей, а родитель не завершится, пока не завершатся они. Именно это спасает от утёкшей фоновой работы, характерной для голых потоков. В Android viewModelScope отменяется при очистке ViewModel, а lifecycleScope — при завершении жизненного цикла, так что работа останавливается, когда её результат уже некуда применить.

Объясните диспетчеры и что для чего используется.

Dispatchers.Main работает на UI-потоке, там трогают вью. Dispatchers.IO — большой эластичный пул для блокирующей работы: диск, сеть, база, — потому что такие потоки в основном ждут. Dispatchers.Default размером с число ядер и предназначен для настоящих вычислений вроде парсинга или сортировки. Блокирующий вызов на Default выедает пул — это самая частая ошибка с диспетчерами.

В чём разница между Flow, StateFlow и LiveData?

Flow — холодный асинхронный поток: он начинает производить значения при подписке, и у каждого подписчика своё выполнение. StateFlow горячий и всегда хранит ровно одно текущее значение, что делает его естественным для состояния UI — новый подписчик сразу получает актуальное состояние. LiveData — более старый lifecycle-aware держатель; StateFlow вместе с repeatOnLifecycle закрывает ту же задачу остальным инструментарием корутин, поэтому новый код обычно выбирает его.

Почему смена конфигурации пересоздаёт Activity и как это пережить?

Поворот, тёмная тема, смена языка и размера окна уничтожают и пересоздают Activity, чтобы она подгрузила ресурсы под новую конфигурацию. Состояние, которое должно выжить, живёт во ViewModel — она переживает пересоздание. Состояние, которое должно пережить ещё и смерть процесса, идёт в SavedStateHandle, потому что систему никто не обязывает держать ваш процесс в фоне. Проверка этого пути через «Не сохранять активности» отличает надёжное приложение от того, что теряет введённые пользователем данные.

Что вызывает рекомпозицию в Jetpack Compose и из-за чего она тормозит?

Compose перезапускает composable, когда меняется прочитанный им State, и пропускает те, у кого параметры равны и стабильны. Тормоза идут от нестабильных параметров — обычный List или лямбда, захватившая меняющееся значение, — они ломают пропуск и перезапускают большие поддеревья. Лечится подъёмом состояния к ближайшему общему владельцу, неизменяемыми коллекциями или аннотацией @Immutable, а также отложенным чтением через лямбды, чтобы перезапускалась только фаза layout или draw.

Зачем внедрение зависимостей через Hilt вместо прямого создания объектов?

DI избавляет класс от знания о том, как собрать свои зависимости, что делает его тестируемым и держит проводку в одном месте вместо разбросанных синглтонов. Hilt генерирует граф Dagger и привязывает время жизни компонентов к андроидным: @Singleton живёт с приложением, @ViewModelScoped — с ViewModel. Практическая выгода — подменить настоящий репозиторий фейком в тестах, не трогая продакшен-код.

Как устроен экран с точки зрения чистой архитектуры?

Слой UI держит Compose или View плюс ViewModel, которая отдаёт неизменяемое состояние и принимает события. Слой домена держит юзкейсы и чистые бизнес-правила без импортов Android — именно поэтому он тестируется обычным JUnit. Слой данных держит репозитории, которые выбирают между Room и Retrofit и мапят DTO в доменные модели. Важно тут направление зависимостей: домен ничего не знает ни о данных, ни об UI.

Из-за чего возникает ANR и как найти его уже после релиза?

ANR срабатывает, когда главный поток заблокирован примерно на пять секунд на вводе, а для бродкастов и сервисов лимиты жёстче. Типичные причины — обращение к базе или сети на главном потоке, огромный синхронный разбор JSON, конкуренция за блокировку с фоновым потоком. После релиза отчёты ANR в Play Console вместе со снятым стеком главного потока указывают на блокирующий кадр; StrictMode в debug-сборках ловит большую часть этого задолго до релиза.

Как избегать утечек памяти в Android?

Повторяющаяся причина — что-то долгоживущее держит Activity или View: статическая ссылка, неотписанный слушатель, внутренний класс с неявной ссылкой на внешний, корутина на GlobalScope. Защита — привязывать работу к lifecycle-aware скоупу, обнулять ссылку на binding в onDestroyView у фрагментов и использовать Context приложения там, где не нужен Context активности. Остальное ловит LeakCanary в debug-сборке, показывая цепочку удержания.