Питання на співбесіді Android-розробника

У Kotlin типи за замовчуванням не можуть бути null: String і String? — різні типи. Для nullable-значень використовують безпечний виклик user?.name, оператор Елвіса name ?: "Гість" і let.

Оператор !! вимикає захист і кидає виняток при null — у продакшн-коді його варто уникати. NPE все ще можливий на межі з Java-кодом, де типи не анотовані.

Основні колбеки: onCreate (ініціалізація), onStart (стає видимою), onResume (отримує фокус), onPause, onStop, onDestroy.

При повороті екрана Activity за замовчуванням перестворюється, тому стан, який має пережити зміну конфігурації, тримають у ViewModel, а невеликі дані для відновлення після вбивства процесу — у SavedStateHandle. Підписки на дані прив'язують до життєвого циклу через repeatOnLifecycle.

data class автоматично генерує equals, hashCode, toString і copy — зручно для моделей даних і стану UI.

sealed class / sealed interface описує обмежений набір варіантів, наприклад стан екрана: Loading, Success(data), Error(message). У when компілятор перевіряє, що оброблено всі варіанти.

Compose будує UI з функцій, які перевикликаються, коли змінюється стан, що вони читають. Це і є рекомпозиція: Compose оновлює лише ті частини, які залежать від зміненого стану.

Стан зберігають через remember { mutableStateOf(...) }, а щоб він пережив поворот екрана — rememberSaveable або ViewModel. Функції Composable мають бути швидкими й без побічних ефектів.

Main — головний потік для роботи з UI. IO — оптимізований для блокуючих операцій вводу-виводу: мережа, файли, БД. Default — для CPU-обчислень, кількість потоків дорівнює кількості ядер.

Перемикаються через withContext(Dispatchers.IO) { ... }. Бібліотеки на кшталт Retrofit і Room з suspend-функціями самі виконують роботу поза головним потоком, тож явне перемикання там не потрібне.

StateFlow завжди має поточне значення і віддає його новим підписникам — ідеально для стану екрана. Однакові значення поспіль не надсилаються повторно.

SharedFlow не має обов'язкового значення і підходить для одноразових подій: показати Snackbar, перейти на інший екран. У Compose стан збирають через collectAsStateWithLifecycle(), щоб не працювати у фоні.

ViewModel тримає стан екрана в одному StateFlow<UiState>, отримує дані з репозиторіїв і обробляє дії користувача. UI лише відображає стан і передає події.

У MVI всі дії формалізовані (Intent), а стан змінюється редьюсером — це передбачуваніше й легше тестується. Дані йдуть через шари: UI → ViewModel → UseCase (за потреби) → Repository → джерела даних (Room, Retrofit). DI — Hilt або Koin.

Обмеження системи на фонову роботу щороку посилюються. Для відкладених задач, які мають виконатися гарантовано (синхронізація, завантаження), використовують WorkManager з умовами: мережа, заряд.

Для роботи, яку бачить користувач (відтворення музики, навігація), — Foreground Service з відповідним типом, який з Android 14 треба явно оголошувати. Короткі операції в межах екрана — корутини у viewModelScope.

Спершу виміряти: Layout Inspector показує кількість рекомпозицій, Macrobenchmark — швидкість старту й прокрутки.

Прийоми: стабільні типи параметрів (immutable-класи, ImmutableList), відкладене читання стану через лямбди (Modifier.offset { }), derivedStateOf для похідних значень, key у LazyColumn, винесення важких обчислень з Composable. Baseline Profiles помітно прискорюють старт і першу прокрутку.

Модулі пришвидшують збірку (інкрементальна компіляція, паралельність), задають межі між фічами й дають командам працювати незалежно.

Типова схема: app, модулі фіч (feature:profile), спільні core:ui, core:network, core:data. Фічі не залежать одна від одної напряму — навігація через контракти. Спільні налаштування Gradle — через convention plugins і version catalog.

Кожна корутина запускається в scope, який контролює її життя: коли scope скасовано (наприклад, viewModelScope при закритті екрана), скасовуються всі дочірні корутини. Помилка в дочірній корутині за замовчуванням скасовує батьківську.

Це запобігає витокам і «завислим» запитам. GlobalScope порушує цей принцип, тому його уникають. Для незалежних дочірніх задач використовують SupervisorJob / supervisorScope.

Поетапний реліз (staged rollout) з моніторингом крашів і ANR у Firebase Crashlytics та Android Vitals — якщо показники погіршуються, реліз зупиняють. Feature flags дозволяють вимкнути функцію без нового релізу.

У CI — юніт-тести, скріншот-тести для Compose, статичний аналіз (detekt, Android Lint) і збірка релізної версії з R8. Також стежать за вимогами Google Play: target API level і політики щодо даних користувачів.