Співбесіда 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) →