Android Instant Apps: де ламається перший запуск
Відмова відбувається не всередині застосунку, а до нього. Користувач клікає по посиланню, потрапляє в магазин і бачить екран завантаження — і йде, не дочекавшись першого екрана.
Чим більша вага пакета, що завантажується, і чим більше кроків між посиланням і працюючим інтерфейсом, тим вища ця втрата, і вимірюється вона у рази, а не в одиницях відсотків.
Миттєвий запуск — це не прискорення завантаження, а відмова від нього. Застосунок збирається з модулів: у базовому залишаються точка входу й спільні ресурси, решта підтягується під час сценарію.
Користувач отримує перший екран одразу після переходу, а встановлення повної версії відбувається у фоні — і часто вже не потрібне, якщо завдання вирішено в одному розділі.
Модульна збірка перебудовує архітектуру повністю, і тут же з’являються свої вузькі місця. Межі модулів доводиться проводити за користувацькими сценаріями, а не за шарами, спільні залежності — виносити в окремий шар, інакше їхня вага дублюється в кожному модулі.
Кожен новий розділ — це правило появи в конкретному маршруті, запис у конфігурації збірки й перевірка, що перехід не тягне за собою половину застосунку.
Помилка в цих межах проявляється тихо: застосунок працює, але перший запуск знову деградує, а відмова на етапі встановлення повертається.
Ловиться це лише на реальних пристроях і в реальних мережах — синтетичні прогони на швидкому каналі дають рівну картину там, де живі користувачі йдуть.
Тому далі розбираємо, як розмічати модулі й які перевірки утримують вагу пакета, що завантажується, під контролем після кожного релізу.
Вимірюваний ефект: швидкість запуску, розмір, відмови
Перехід на модульну доставку змінює не архітектуру заради архітектури, а три числа, за якими видно результат: час до першого екрана, частка пакета, що завантажується, і конверсія з посилання.
Поки застосунок монолітний, перехід за зовнішнім посиланням коштує людині повного встановлення — на слабкому каналі це 10-15 секунд очікування й помітна частка відмов, які трапляються ще до першого екрана.
Після розділення на базовий модуль і функціональні модулі клієнт отримує лише те, що потрібно для поточного сценарію.
Частка пакета, що завантажується, падає до 15-25% від повного обсягу, час до першого екрана — до 2-4 секунд, а конверсія з посилання зростає: користувач бачить потрібний екран раніше, ніж вирішує, чи потрібен йому застосунок повністю.
Google Play віддає модулі на запит, тому глибина сценарію обмежена лише тим, що ви винесли в окремий модуль.
Окремий ефект — клас відмов, який зникає зовсім: перерване встановлення, нестача місця, несумісна версія, відхилене оновлення.
Оновлення без повного встановлення працює на рівні модулів: правка в одному сценарії підтягується окремо й не змушує перевстановлювати застосунок повністю.
Метрики знімаємо до й після: медіана та 90-й перцентиль часу до першого екрана, частка пакета, що завантажується, частка сесій без встановлення, конверсія з посилання в цільову дію.
Варіанти запуску: Instant Apps, встановлення, посилання
Режим доставки вирішує, що користувач отримує в перші секунди: роботу без встановлення, перехід за посиланням у браузер або повноцінне встановлення з магазину. Вибір упирається в одне — яка частина сценарію має працювати одразу, а яка може зачекати до наступного візиту.
Обмеження платформи задають межі жорсткіше, ніж побажання до інтерфейсу: миттєвий запуск лімітований за обсягом модуля й набором доступних системних можливостей. Нижче — чотири схеми, між якими реально обирають на старті.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Миттєвий запуск (Instant Apps) | Сценарій на 1–2 екрани: оплата, замовлення, промо | Ліміт на обсяг модуля, урізаний набір дозволів |
| Перехід за посиланням у браузері | Охоплення з пошуку й месенджерів, контент без складної логіки | Немає доступу до частини можливостей пристрою, слабше утримання |
| Повне встановлення | Довгий цикл, офлайн-режим, фонова робота | Бар’єр на вході: частина користувачів іде під час завантаження й видачі дозволів |
| Гібридний сценарій | Перший контакт миттєво, далі — повноцінний застосунок | Потрібна модульна архітектура й перенесення стану між модулями |
На практиці частіше виграє гібридна схема: перший екран віддаємо миттєвим модулем, а встановлення пропонуємо в момент, коли користувач уже отримав результат.
Тоді перехід за посиланням не втрачає стан — кошик, авторизація й прогрес переносяться у встановлений застосунок, а не починаються заново.
Порядок робіт: аудит, розбиття модулів, перевірка
Впровадження миттєвого запуску — це не «зробити ще одну збірку», а перебудова проєкту під модульну архітектуру. Починаємо з аудиту: без карти екранів, точок входу й зовнішніх залежностей не зрозуміти, що взагалі має сенс виносити в запуск без встановлення.
Далі йдемо за фіксованою послідовністю — від нарізки коду до перевірки на живих пристроях і передачі команді.
- Аудит застосунку. Збираємо карту екранів і користувацьких шляхів, список зовнішніх залежностей, розмір збірки й час холодного запуску. На виході — перелік сценаріїв, які реально виграють від миттєвого старту.
- Визначення меж сценаріїв. Вирішуємо, які шляхи стають окремими модулями, а що залишається в спільному ядрі. Ядро тримаємо мінімальним: усе, що потрапляє в миттєвий запуск, напряму впливає на час до першого екрана.
- Розбиття на модулі. Переносимо код у модулі-сценарії, спільні ресурси й роботу з мережею — в ядро. Після кожного кроку звіряємо, що стартова частина не роздулася й модуль не тягне зайвих залежностей.
- Схема залежностей і правила збірки. Фіксуємо напрямок зв’язків: сценарії залежать від ядра, але не навпаки. Версії виносимо в єдиний каталог, заборону зворотних залежностей перевіряємо автоматично на збірці — інакше архітектура роз’їжджається за пару релізів.
- Перевірка на пристроях. Прогоняємо сценарії на реальних апаратах різних виробників, включно зі слабкою мережею й холодним запуском. Окремо — оновлення вже встановленого застосунку й відкат на попередню версію.
- Передача команді. Віддаємо документацію щодо модулів, правила збірки, порядок додавання нового сценарію й релізу. Далі команда замовника веде модулі самостійно.
Що залишається у вас: схеми, модулі, регламенти
Ми передаємо проєкт не «як є», а в стані, у якому ваша команда випускає оновлення без нас. Комплект описує модульну архітектуру Android Instant Apps: яка частина коду йде в миттєвий запуск, яка залишається у встановленому застосунку й де проходять межі між модулями.
- Карта модулів — граф залежностей, точки входу, власник і межі кожного модуля; окремо позначено, що потрапляє в миттєвий варіант, а що доступно лише після встановлення.
- Налаштовані збірки — профілі для миттєвого й повного варіанта зі спільними ресурсами й контрактами взаємодії; перевірка на складальному конвеєрі не пропускає зростання пакета, що завантажується, вище заданого порогу.
- Регламент випуску — порядок кроків від злиття правок до публікації, обов’язкові автотести, хто підтверджує випуск і в який момент вмикається відкат на попередню версію.
- Політика оновлень — періодичність, канали (закрите тестування, поетапне розгортання, повний випуск) і критерії, за якими розгортання зупиняється автоматично.
- Інструкція для команди — як розгорнути середовище, зібрати й перевірити миттєвий варіант на пристрої, додати новий модуль і де дивитися журнали збоїв.
- Схема переходів — які посилання відкривають миттєвий досвід, у який момент користувач переходить у встановлений застосунок і які дані при цьому переносяться.
- Набір метрик і панель спостереження — події, за якими видно частку встановлень після миттєвого запуску й місця, де користувачі йдуть.
Кейс: вага збірки втричі менша, збої запуску зникли
Проєкт — застосунок мережі магазинів: каталог, карта лояльності, оформлення замовлення. Моноліт із трьох десятків модулів означав, що правка в каталозі тягне повну перезбірку й повторне завантаження всього пакета.
Рознесли продукт на незалежно збирані модулі й підняли легку точку входу на Android Instant Apps. Кейс впровадження — сім тижнів від розбору завдання до робочого релізу.
Що було
Користувач завантажував 28 МБ і чекав перший екран каталогу близько чотирьох секунд на середньому пристрої. На холодному старті втрачалося 9% запусків: застосунок не встигав відмалювати список або падав на ініціалізації залежностей. Кожен такий збій — втрачене замовлення, повторно людина вже не поверталася.
Точку входу зібрали з одного модуля каталогу: за посиланням людина отримує список товарів без встановлення, а оформлення замовлення довантажується окремим модулем.
Спільні бібліотеки винесли в базовий шар, зв’язки між модулями описали явно, збірку зробили інкрементальною — перезбирається лише змінена частина.
Результат
Вага збірки, яку завантажує користувач, впала з 28 до 9 МБ, перший екран відкривається приблизно за півтори секунди, частка невдалих запусків — нижче 3%. Повний час збірки скоротився з 14 до 5 хвилин, а відкат на попередній реліз займає один крок. Наступний етап — карта лояльності на тому самому модульному контурі.
Що робити, якщо застосунок уже зібрано монолітом?
Моноліт не переписують повністю — на час переписування релізи зупиняються, а регресії збираються в один спільний пакет.
Робочий шлях інший: точка входу оформлюється окремим модулем усередині тієї самої кодової бази, збирається в Android App Bundle і випускається незалежно, а основний пакет продовжує виходити за своїм графіком.
Першими виносять частини без стану: каталог, пошук, картка товару, перегляд статусу замовлення. Критерій відбору — мінімум зв’язків із внутрішніми сервісами й відсутність залежності від локального сховища: у легкого модуля немає права тримати постійні дані.
Такий код переїжджає майже без правок, бо вже не зав’язаний на глобальний стан і працює від мережевої відповіді.
Сумісність версій тримається на трьох речах: ім’я пакета й підпис залишаються незмінними, тому оновлення приходить на вже встановлені пристрої без перевстановлення; зв’язки між модулями описуються контрактами, а не прямими викликами; ядро й винесений модуль версіонуються окремо, щоб відкат стосувався лише однієї частини.
Головні ризики міграції — приховані зв’язки через спільний стан, дублювання ресурсів і зростання часу збірки.
Їх знімають до перших правок: будують граф залежностей, забороняють модулям звертатися одне до одного напряму й перевіряють збірку кожного модуля окремо на складальному конвеєрі. Тоді винесення наступного фрагмента перетворюється на планове завдання, а не на зупинку продукту.
Технічні сумніви й обмеження платформи
Обмеження платформи проявляються не на демо, а на живому потоці: частина пристроїв не підтримує миттєвий запуск, частина обмежує фонове встановлення.
До старту ми фіксуємо матрицю сумісності — які версії системи й оболонки виробників покриваємо, а що показуємо решті: той самий екран, але через звичайне встановлення з магазину.
Другий шар — доступ до функцій, аналітика й оновлення. Миттєвий модуль отримує урізаний набір дозволів, тому камеру, оплату й геолокацію перевіряємо окремо на кожному сценарії.
Перехід у встановлений застосунок розмічаємо єдиною подією: без цього воронка обривається на середині й частка тих, хто дійшов до встановлення, вважається неправильно.
Які пристрої не підтримують миттєвий запуск?
Покриття залежить від версії системи й набору сервісів виробника. Точну частку ми рахуємо за логами до релізу, а для решти користувачів залишаємо той самий функціональний шлях — посилання на встановлення зі збереженням контексту, щоб людина не починала сценарій заново.
Як рахується аналітика переходів між модулем і застосунком?
Події миттєвого модуля й встановленого застосунку йдуть різними потоками, тому без єдиного ідентифікатора сесії вони не сходяться. Ми розмічаємо вхід, ключові кроки й встановлення спільною ознакою — тоді видно, на якому екрані губиться користувач і що саме варто спростити.
Що з безпекою даних під час миттєвого запуску?
Модуль працює в ізольованому середовищі й не зберігає ключі доступу між запусками. Критичні дані не кешуємо, авторизацію перевіряємо при кожному вході, обмін іде лише захищеним каналом — вимоги до зберігання тут суворіші, ніж у звичайному застосунку.
Як часто можна випускати оновлення?
Миттєвий модуль оновлюється разом із релізом у магазині й підхоплюється під час наступного запуску, без дій з боку користувача. Єдине обмеження — розмір модуля: чим він важчий, тим вища частка відмов під час завантаження, тому великі розділи ми виносимо у встановлену частину.
Якщо у вас уже є застосунок і ви думаєте про миттєвий запуск як про додатковий вхід, опишіть поточний сценарій — повернемося з оцінкою та планом за етапами.Обговоримо ваше завдання: що потрібно для старту робіт
Щоб ми повернулися з оцінкою термінів, а не із загальними словами, потрібен мінімум вхідних даних про поточний стан проєкту й межі завдання. Опишіть її у вільній формі: призначення застосунку, що вже працює і що заважає.
Уточнювальні питання поставимо самі — на цьому етапі важливіший контекст, ніж формальний опис вимог.
- Посилання на репозиторій або архів проєкту: за кодом видно стан модулів, залежності й накопичений борг.
- Схему модулів і їхніх меж — що вже виділено, що пов’язано напряму, де логіка дублюється між основним застосунком і сценарієм Android Instant Apps.
- Опис сценарію, який має запускатися без встановлення: що користувач робить у перші секунди й який результат вважається успіхом.
- Дані про релізний цикл: як часто виходять версії, скільки займає збірка, хто перевіряє зміни перед випуском.
- Обмеження: мінімальна версія системи, список цільових пристроїв, вимоги до доступів і зберігання персональних даних.
- Відповідального з вашого боку — того, хто підтверджує пріоритети й приймає проміжні результати.
- Очікування щодо термінів і точки, у яких потрібне проміжне приймання.
Після розбору повернемося з оцінкою термінів, схемою робіт за модулями, планом впровадження й складом команди — з ролями й завантаженням за етапами. Якщо частина даних відсутня, це не блокує старт: зафіксуємо припущення й уточнимо їх по ходу.
