Android / Kotlin

Системі належить ваш екран

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

Є й друга, жорсткіша версія того самого. Поки застосунок у фоні, система може просто вбити його процес, щоб повернути пам’ять, — і коли користувач повернеться, Android відтворить застосунок на тому екрані, де той його лишив, з нуля. На середньому телефоні з десятком відкритих застосунків це не крайній випадок. Саме тому на питання про зберігання є три відповіді, а не одна, і саме тому хибний вибір дає баґ, який ви не відтворите на власному пристрої.

Та сама логіка керує фоновою роботою. Застосунок, якого немає на екрані, не має права далі працювати, і платформа затягувала це з кожним релізом: обмеження фону, режим doze і виробники, що додають власні обмеження зверху. Робота, яка колись має статися, іде у WorkManager: він зберігає її та виконує, коли система дозволить, переживаючи і смерть процесу, і перезавантаження. Робота, яку має бути видно, поки вона триває, потребує сервісу переднього плану й сповіщення, бо користувач має право знати.

Kotlin і зокрема корутини

Kotlin тепер і є мовою Android: рекомендація Google, мова, якою написано документацію, і те, під що спроєктовані всі сучасні API. Він працює на JVM і напряму викликає Java-бібліотеки, тож впровадження в наявну Java-базу відбувається файл за файлом, а не все одразу. Дві його риси виправдовують себе одразу: можливість null є частиною системи типів, тож значення, яке може бути null, не можна використати так, ніби воно не може; а класи даних прибирають шаблонний код, що робив Java-моделі виснажливими.

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

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

Compose і система View

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

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

Як це виявляється в реальній поставці

Фрагментація реальна, але не така, як її уявляють. Проблему рівнів API здебільшого розв’язано: бібліотеки підтримки переносять більшість назад, а minSdk — це число, яке ви обираєте за даними власних користувачів. Насправді різниться залізо під сподом: телефон із двома гігабайтами пам’яті й повільним процесором швидше вб’є ваш процес, згубить кадри, яких не губить ваш тестовий пристрій, і виявить кожне виділення пам’яті в обробнику скролу. Тестуйте на дешевому пристрої, бо на такому сидить помітна частка ваших користувачів.

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

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

• Стан екрана, що живе в активності, спорожнюється при першому ж повороті пристрою.
• Нічого не записано у збережений стан — і застосунок повертається порожнім після вбивства процесу.
• Контекст активності, який тримає синглтон чи статичне поле, тече разом з усією ієрархією в’ю.
• Фонова робота, запущена поза областю життєвого циклу, працює далі, не маючи куди віддати результат.
• Відкладена робота в сервісі замість WorkManager гине разом із процесом.
• Дозволи, запитані на старті, а не в контексті, привчають користувачів відмовляти.
• Тестування лише на флагмані ховає всі проблеми з пам’яттю й кадрами, які є у ваших користувачів.

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

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

• РозробкаiOS / SwiftiOS — це один вендор, один інструментарій, один набір правил — і взамін платформа, де залізо, ОС і мову проєктують разом. Swift — сучасна строго типізована мова без збирача сміття, тож пам’ять тут — те, про що ви міркуєте, а не те, що з вами стається. На цій сторінці — підрахунок посилань, SwiftUI проти UIKit, паралельність і той процес релізу, що дивує команди, які прийшли з вебу.
• РозробкаJavaJava вже тридцять років є типовою мовою великих бекенд-систем і досі та, яку бачиш, коли банк, авіакомпанія чи телеком відкриває своє дерево коду. Java робить собою не так синтаксис, як машина, на якій вона працює: байт-код замість машинного коду, компілятор, що оптимізує під час роботи програми, і збирач сміття, який налаштовують, а не замінюють. На цій сторінці — JVM, система типів, Spring, паралельність і те, що змінили віртуальні потоки.
• РозробкаFlutterFlutter — це відповідь Google на розробку під кілька платформ з однієї кодової бази, і підхід тут протилежний до React Native: замість просити віджети в операційної системи, Flutter постачає власний рушій рендерингу й малює кожен піксель сам. Це одне рішення пояснює однаковість, продуктивність, розмір бінарника й ті місця, де підхід буксує. На цій сторінці — конвеєр рендерингу, Dart, керування станом і те, куди Flutter пасує.