Співбесіда Android-розробника крутиться навколо ідіом Kotlin, корутин і життєвого циклу платформи — більшість senior-питань насправді перевіряють, чи розумієте ви, що процес можуть убити будь-якої миті. Нижче — питання, які ставлять найчастіше, кожне з еталонною відповіддю. Senior: архітектуру, трейд-офи, менторство та прийняття рішень.
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 — не розширення і просто групує виклики. Вибір за поверненим значенням і формою отримувача якраз і тримає їх читаними, а не хитрими.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Senior Android (Kotlin) →