Android / Kotlin

Що знищує ваш екран — шістнадцять подій і що переживає кожну

На Android система, а не ваш застосунок, вирішує, скільки житимуть екран і його процес. Активність — об’єкт, що веде один екран, — знищують і будують заново щоразу, коли змінюється конфігурація пристрою. Весь процес убивають щоразу, коли системі потрібна його пам’ять, а коли користувач повертається, Android відбудовує екран, з якого той пішов, ніби нічого не сталося. Кожна подія знищує різний обсяг, і частина стану переживає подію, лише якщо живе там, куди ця подія не дістає. Тож корисне питання до будь-якого екрана — не «чи він працює?». Воно таке: «що від нього лишиться після кожної з цих подій?». Ось шістнадцять подій. Наступні розділи посилаються на рядки за номерами.

Смерть процесу, збережений стан і пам’ять

Рядки 11 і 12 існують тому, що телефон тримає десятки застосунків у кількох гігабайтах пам’яті й не вивантажує пам’ять застосунків на диск — натомість стискає її. Коли цього не вистачає, системна служба, low-memory killer, завершує процеси за важливістю: спершу кешовані застосунки у фоні, потім менш важливі. На телефоні середнього класу з камерою чи грою на передньому плані ваш застосунок у фоні може зникнути за секунди. І тоді Android виконує обіцянку, якої користувач не бачить: коли той повертається з «Недавніх», запускається новий процес і екран, з якого він пішов, відбудовується — та сама вкладка, та сама позиція скролу, те саме недописане повідомлення, — якщо застосунок це зберіг.

Механізм — збережений стан. Коли активність зупиняється, Android просить у неї Bundle — невеликий набір значень — і тримає його поза процесом застосунку, тож він переживає процес і передається новому. SavedStateHandle у ViewModel і rememberSaveable у Compose пишуть саме туди. Bundle подорожує через Binder — механізм Android для викликів між процесами, — чий буфер має 1 МБ і ділиться між усім, що процес надсилає в цю мить. Google радить тримати збережений стан меншим за 50 КБ, а з Android 7.0 перевищення межі кидає TransactionTooLargeException — падіння, що стається на шляху у фон.

Перевірка рядків 11–12 займає хвилину. Опція розробника «Не зберігати активності» знищує кожну активність, щойно з неї йдеш, і ловить частину проблеми. Справжня перевірка — відправити застосунок у фон, виконати adb shell am kill з назвою його пакета — вона вбиває лише фоновий процес — і знову відкрити застосунок із «Недавніх». Екран має виглядати рівно так, як ви його лишили. З Android 11 ApplicationExitInfo каже новому процесу, чому завершився попередній — брак пам’яті, падіння, ANR, користувач, — тож команда може рахувати смерті процесу в продакшні, а не вгадувати.

Саму пам’ять тепер контролюють з двох боків. Android 17, що вийшов 16 червня 2026 року, встановлює межі пам’яті для кожного застосунку залежно від загального обсягу RAM пристрою й завершує процес, який за них виходить; причина завершення містить текст «MemoryLimiter:AnonSwap». Google Play зробив використання пам’яті ключовим показником із порогами для кожного класу RAM — на телефоні з 4 ГБ це 2 ГБ на передньому плані й 1 ГБ у фоні — і каже, що застосунки понад них можуть втратити видимість у магазині з лютого 2027 року. Звична причина — зображення, з тієї самої причини, що на сторінці про React Native: декодоване зображення займає ширина × висота × 4 байти, тож фото на 12 мегапікселів займає в пам’яті 48 МБ.

Kotlin і корутини: робота, що закінчується разом з екраном

Kotlin — мова від JetBrains, стабільна з лютого 2016 року, яку Google зробив офіційною мовою Android у травні 2017-го, а з 2019 року — пріоритетною. Jetpack Compose існує лише на Kotlin, а документацію й нові APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни пишуть спершу для нього. Kotlin компілюється в той самий JVMJVMJava Virtual Machine — середовище виконання JavaМашина, на якій насправді виконується скомпільований Java-код. Вона дає збирач сміття і JIT — і саме вона пояснює, чому одна збірка без змін працює на Windows, Linux і macOS: різниця платформ є проблемою JVM, а не програми.Докладніше в статті →Усі терміни-байткод, що й Java, а збірка Android потім перетворює його на DEX-код для середовища виконання Android, тож обидві мови напряму викликають одна одну, а Java-кодову базу можна переводити по одному файлу. Дві риси окуповуються одразу. Можливість null є частиною типу — String? не можна вжити як String без перевірки, — а data- та sealed-класи описують стани екрана кількома рядками, які компілятор потім вичерпно перевіряє в when.

Корутини змінили саме письмо Android-коду. suspend-функція може призупинитися — чекаючи на мережу чи базу даних — без блокування свого потоку, тож асинхронна робота читається згори вниз. Диспетчери кажуть, де вона виконується: Dispatchers.Main — для інтерфейсу, IO — для блокувальних читань і записів, Default — для обчислень. Безпечними, а не лише зручними, корутини робить структурована паралельність. Кожну корутину запускають в області (scope), і коли область скасовують, скасовується все, що в ній запущено. Тож таблиця на початку сторінки — це ще й таблиця областей: правильна область та, що закінчується рівно тоді, коли робота перестає бути корисною.

Поверх корутин лежить Flow — потік значень у часі: запит до бази, що видає результат знову, коли змінюються рядки; поле пошуку, що робить запити, поки користувач набирає. Для стану екрана StateFlow тримає поточне значення й видає оновлення — саме те, що потрібно відбудованому екрану: щось, що можна прочитати одразу й спостерігати далі. Як екран його збирає, важить не менше, ніж де його створюють. collectAsStateWithLifecycle() у Compose або repeatOnLifecycle(STARTED) з View припиняє збирання, коли застосунок іде у фон, і починає знову, коли той повертається. Без цього потік оновлень геолокації тримає GPS увімкненим для екрана, на який ніхто не дивиться.

Головний потік на Android теж має дедлайн. Якщо він не обробить подію введення за 5 секунд, система показує діалог «Застосунок не відповідає» — ANR. Google Play рахує частку сесій, де користувач побачив ANR, і понад 0,47% загалом або 8% на будь-якій окремій моделі телефона видимість застосунку в магазині може постраждати. Більшість ANR — звичайна робота не на своєму місці: запит до бази, розбір великого JSONJSONJavaScript Object Notation — текстовий формат данихТекстовий формат для передавання даних: пари «ключ — значення», списки, числа й рядки. Він народився в JavaScript, але сьогодні його читає будь-яка мова — і саме тому ним відповідає більшість API, а не чимось потужнішим.Усі терміни чи читання файлу на Dispatchers.Main. StrictMode, увімкнений у debug-збірках, повідомляє про доступ до диска й мережі в головному потоці тієї ж миті.

Compose: три фази і що перескладається

Jetpack Compose, стабільний з липня 2021 року й у версії 1.12 станом на вересень 2026-го, — набір інструментів для інтерфейсу, який рекомендує Google. Ви пишете composable-функції, що описують екран для заданого стану; коли змінюється стан, який вони читають, Compose виконує їх знову — це перескладання (recomposition) — і оновлює те, що змінилося. Він замінює XML-розкладки, findViewById, адаптери й звичку тримати посилання на в’ю та змінювати їх руками. Для списку це різниця між RecyclerView з адаптером і view holder та LazyColumn з лямбдою.

Compose будує кожен кадр у три фази. Композиція вирішує, що показати, виконуючи composable-функції. Розкладка вирішує, де: кожен елемент вимірюють і розміщують. Малювання виводить пікселі. Compose запам’ятовує, яка фаза прочитала кожну частину стану, і коли стан змінюється, повторює лише цю фазу й наступні. Це дає головному правилу продуктивності точну форму: читайте стан якомога пізніше. Заголовок, що рухається зі скролом і читає зсув скролу у своїй composable-функції, перескладається на кожному кадрі скролу. Той самий заголовок, що читає зсув усередині Modifier.offset { }, повторює лише розкладку, а всередині graphicsLayer { } — лише малювання.

Друге правило — пропуск. Під час перескладання Compose пропускає composable-функцію, чиї параметри не змінилися. З Kotlin 2.0.20 strong skipping увімкнено типово: параметри стабільних типів порівнюють через equals(), а все інше — за ідентичністю: це той самий об’єкт? Через це один патерн стає дорогим так, що цього не видно. Room видає новий список нових об’єктів щоразу, коли змінюється будь-який рядок запиту, тож кожен рядок LazyColumn отримує інший об’єкт і перескладається, навіть якщо змінився лише один. Давайте елементам списку стабільні key, позначайте справді незмінні data-класи як @Immutable і читайте звіт про стабільність від компілятора Compose, перш ніж гадати.

Compose також несе зміни платформи у формі екрана. Відколи застосунки мусять мати target Android 15, вони малюються від краю до краю, під рядком стану й панеллю навігації; для застосунків із target Android 16 відмови від цього вже немає, жест «назад» типово показує передбачувальну анімацію, а на екранах від 600 dp система ігнорує фіксацію орієнтації — рядок 9. Розкладка, написана для одного телефона у вертикальному положенні, тепер має працювати на планшеті, розкладеному складаному телефоні й у вікні зі змінним розміром. Саме для цього є класи розміру вікна й адаптивні бібліотеки Compose, а сторінка про React Native наводить ті самі дедлайни з боку кросплатформної команди.

Фонова робота: що система дозволяє виконувати

Застосунок, якого немає на екрані, типово не має права далі працювати, і майже кожен реліз Android з 2015 року звужував те, що йому дозволено. Doze в Android 6.0 відкладав мережу й задачі, поки телефон лежить нерухомо. Android 8.0 обмежив фонові сервіси. Android 9 розклав застосунки за кошиками очікування залежно від того, як давно ними користувалися. Android 14 вимагав, щоб кожен сервіс переднього плану декларував тип, і перестав типово давати точні будильники щойно встановленим застосункам. Android 15 обмежив сервіси синхронізації даних шістьма годинами на добу. Понад це кілька виробників додають власні менеджери батареї, що завершують фонову роботу агресивніше за стоковий Android; сайт dontkillmyapp.com відстежує їх за брендами.

Практичний наслідок: «працювати у фоні» — ніколи не вимога, яку можна прийняти як написано. Спитайте, що користувачеві потрібно, щоб сталося, і коли йому треба дізнатися, що це сталося. Більшість відповідей — це WorkManager з умовою, сервіс переднього плану зі сповіщенням або push-повідомлення від сервера, яке каже застосунку, що є що забрати. Перевіряйте кожен фоновий шлях на двох-трьох телефонах від виробників, відомих агресивним керуванням батареєю, бо стоковий емулятор — єдине місце, де фонова робота виконується завжди.

Випуск: доріжки, поетапні розгортання й календар Google Play

Google Play дає кожному застосунку чотири доріжки. Внутрішнє тестування охоплює до 100 тестувальників, зазвичай за секунди після додавання збірки. Закрите й відкрите тестування охоплюють більші групи, а продакшн — усіх. Особистий акаунт розробника, створений після 13 листопада 2023 року, мусить провести закрите тестування щонайменше з 12 тестувальниками, підписаними 14 днів поспіль, перш ніж узагалі зможе публікувати в продакшн. Рев’ю зазвичай швидше, ніж в Apple, але воно є, а перевірки політик — декларації дозволів, форма безпеки даних, що відповідає тому, що застосунок робить, target API — автоматизовані й не торгуються.

Поетапне розгортання (staged rolloutstaged rolloutоновлення для дедалі більшої частки користувачівВипуск оновлення спершу для невеликої частки користувачів — 1%, потім 5%, 20%, усі — з перевіркою частоти падінь і помилок перед кожним кроком, щоб поганий реліз дійшов до небагатьох, а не до всіх. Воно обмежує, до скількох людей дійде поганий реліз, а не те, чи дійде він узагалі: у магазинах застосунків зупинене розгортання не забирає оновлення в тих, хто його вже має.Усі терміни) випускає оновлення на обраний вами відсоток користувачів, який ви з часом піднімаєте, — 1%, потім 5%, потім 20%, — і його можна зупинити будь-коли. Поки воно триває, Android vitals у Play Console показує частоту падінь і ANR нової версії проти порогів, що впливають на видимість застосунку: частота падінь, які бачить користувач, — 1,09% загалом або 8% на одній моделі телефона, частота ANR — 0,47% загалом або 8% на одній моделі. Поріг на модель — саме той, що ловить фрагментацію: падіння на телефонах одного виробника може бути непомітним у загальному середньому й однаково коштувати застосунку видимості на цих телефонах.

Календар Google Play — вимоги близько до дати цієї сторінки

Яка Android-кодова база перед вами

П’ять кейсів і те, чого в кожному бракувало

Кейси Android мають одну форму: щось, чого застосунок не контролює, — система, спільний компонент, виробник, інший застосунок, — змінюється під ним. Кожен задокументували ті, кого він стосувався: розкриття від безпекової компанії, власна документація й заяви Google, компанії, чиїх користувачів це зачепило.

Кейс із WebView показує, що це означає на практиці. 22 березня 2021 року оновлення Android System WebView — компонента, що малює вебвміст усередині інших застосунків і оновлюється через Google Play, — автоматично дійшло до телефонів, і застосунки по всій екосистемі почали падати: Gmail, застосунок Google, Amazon, Discord, Outlook, банківські застосунки. Жоден із них нічого не випускав. Google за кілька годин підтвердив проблему й випустив WebView і Chrome 89.0.4389.105, а користувачам порадили оновити обидва. Для команди застосунку урок — у моніторингу: сплеск падінь без релізу за ним — це системний компонент, доки не доведено інше, а звіти про падіння мають нести версію WebView, щоб це показати.

П’ятий кейс — найсерйозніший і найповчальніший. У грудні 2021 року користувач повідомив, що дзвінок на 911 з телефона Pixel не пройшов: телефон показав дзвінок, один раз видав гудок і ні з чим не з’єднався. Google простежив це до ненавмисної взаємодії з Microsoft Teams. Коли Teams був встановлений, але користувач не ввійшов, застосунок знову й знову реєстрував телефонний акаунт у телеком-службі Android, і на деяких Pixel дублікати ламали шлях екстреного дзвінка. Microsoft за кілька днів випустила виправлений Teams, а Google додав власне виправлення платформи в січневе оновлення 2022 року. API платформи, викликаний у циклі, — звичайний баґ. Урок у тому, що виклики застосунку до спільних системних служб дістають до шляхів, яких не дістають власні тести застосунку, — а екстрений дзвінок — шлях, який ніхто не може спробувати в продакшні.

Де це вироджується

Android щедрий до команди, що проєктує з урахуванням того, що застосунком володіє система, і безжальний до тієї, що припускає, ніби процес лишається живим. Мова й набір інструментів добрі; збої приходять від подій із таблиці й від телефонів, яких у команди немає. Майже кожен збій — одне з цього:

• Стан екрана в активності, що спорожнюється на першому ж повороті (рядки 5–10).
• Нічого в збереженому стані — і застосунок повертається порожнім після того, як система забрала пам’ять (рядки 11–12).
• Забагато в збереженому стані — і застосунок падає на шляху у фон.
• configChanges, яким глушать поворот замість збереження стану.
• Робота в GlobalScope і корутини, що ковтають власне скасування.
• Потоки, які збирають без огляду на життєвий цикл, — і сенсори й мережа працюють у фоні.
• Стан, прочитаний у композиції, хоча його можна прочитати в розкладці чи малюванні, і нові об’єкти від шару даних на кожне оновлення.
• Фонова робота, яку вважають гарантованою, wake lock, утримані на шляхах помилки, і жодного тесту на телефоні агресивного виробника.
• Тестування лише на флагмані й емуляторі, яке ховає всі проблеми з пам’яттю й кадрами, що є у ваших користувачів.
• Календар Google Play — target API, сторінки по 16 КБ, пороги vitals, — виявлений тоді, коли оновлення відхилили.

Чесна межа — охоплення без контролю. Android працює на більшій кількості видів пристроїв, ніж будь-яка інша система, — від телефонів на 2 ГБ до складаних і вікон на десктопі, — і саме це охоплення є причиною під нього будувати: у більшій частині світу більшість користувачів саме там. Те саме охоплення означає, що застосунок ніколи не знає пристрою, на якому працює, система забирає його, коли захоче, а частини платформи під ним оновлюються за чужим розкладом. Жодна архітектура цього не прибирає. Добра робить кожну подію з таблиці такою, яку можна пережити, вимірює, що стається на телефонах, яких команда не має, і вважає щорічний цільовий рівень Play сталим пунктом плану.

Практична перевірка займає десять хвилин. Прочитайте targetSdk, minSdk і версію Kotlin та знайдіть їх у таблиці календаря. Пошукайте configChanges, GlobalScope, onBackPressed, catch (e: Exception) навколо призупинних викликів і .collect { поза repeatOnLifecycle. Відправте застосунок у фон на найнавантаженішому екрані, виконайте adb shell am kill і відкрийте його знову з «Недавніх». Поверніть кожен екран один раз. Відкрийте Android vitals і прочитайте частоту падінь і ANR для кожної моделі телефона, а не лише загальну. І перевірте, які з ваших SDK беруть wake lock.

Коли це застосовувати

Пов’язані сторінки

• РозробкаiOS / SwiftРозробка під iOS — це створення застосунків для iPhone та iPad мовою Swift, компільованою мовою, що звільняє пам’ять підрахунком посилань, а не збирачем сміття. Цей один вибір пояснює найчастіший тихий баґ платформи — два об’єкти, які назавжди тримають один одного живими, — і більшість того, що нативна iOS-команда проєктує свідомо. Сторінка починається з шістнадцяти посилань, які тримає iOS-застосунок, і того, що звільняє кожне; далі — підрахунок посилань, SwiftUI проти UIKit і кому належить стан, паралельність у Swift до версії 6.4, рев’ю, TestFlight і семиденний поетапний реліз, дедлайни Apple на 2026 рік, п’ять задокументованих кейсів і те, де все це вироджується.
• РозробкаJavaJava — статично типізована мова, що компілюється в байт-код для JVM — середовища, яке компілює гарячий код під час роботи й звільняє пам’ять збирачем сміття. Тридцять років вона є типовим вибором для великих бекенд-систем — банків, авіакомпаній, телекомів, — і найбільше за останні п’ять років змінилося те, як на ній пишуть і як вона чекає: записи, запечатані типи й зіставлення зі зразком у мові, віртуальні потоки в середовищі. Сторінка починається з кожного будівельного блоку на одному екрані — сучасний спосіб поруч із тим, який він замінив; далі — релізи й ліцензії, JVM, пам’ять у контейнері, Spring і його проксі, потоки й віртуальні потоки та п’ять задокументованих кейсів.
• РозробкаFlutterFlutter — це UI-фреймворк від Google, який малює кожен піксель застосунку власним рушієм з однієї кодової бази на Dart для iOS, Android, вебу й десктопа. Через цей вибір застосунок на Flutter виглядає однаково всюди й не змінюється, коли змінюється операційна система, — навіть коли вона змінюється навмисно, як це зробила iOS 26. Сторінка починається з шістнадцяти речей, які потрібні застосунку, і того, малює їх Flutter чи мусить просити платформу; далі — три дерева й бюджет кадру, ціна перебудови, Dart та ізоляти, межа з платформою й редизайни ОС, релізи до Flutter 3.47, п’ять задокументованих кейсів і те, де все це вироджується.