Android Instant Apps: модульная архитектура и внедрение

Android Instant Apps: где ломается первый запуск

Отказ происходит не внутри приложения, а до него. Пользователь кликает по ссылке, попадает в магазин и видит экран загрузки — и уходит, не дождавшись первого экрана. Чем больше вес загружаемого пакета и чем больше шагов между ссылкой и работающим интерфейсом, тем выше эта потеря, и измеряется она в разы, а не в единицах процентов.

Мгновенный запуск — это не ускорение загрузки, а отказ от неё. Приложение собирается из модулей: в базовом остаются точка входа и общие ресурсы, остальное подтягивается по ходу сценария. Пользователь получает первый экран сразу после перехода, а установка полной версии идёт фоном — и часто уже не нужна, если задача решена в одном разделе.

Модульная сборка перестраивает архитектуру целиком, и здесь же появляются свои узкие места. Границы модулей приходится проводить по пользовательским сценариям, а не по слоям, общие зависимости — выносить в отдельный слой, иначе их вес дублируется в каждом модуле. Каждый новый раздел — это правило появления в конкретном маршруте, запись в конфигурации сборки и проверка, что переход не тянет за собой половину приложения.

Ошибка в этих границах проявляется тихо: приложение работает, но первый запуск снова деградирует, а отказ на этапе установки возвращается. Ловится это только на реальных устройствах и в реальных сетях — синтетические прогоны на быстром канале дают ровную картину там, где живые пользователи уходят. Поэтому дальше разбираем, как размечать модули и какие проверки удерживают вес загружаемого пакета под контролем после каждого релиза.

Измеримый эффект: скорость запуска, размер, отказы

Переход на модульную доставку меняет не архитектуру ради архитектуры, а три числа, по которым видно результат: время до первого экрана, доля скачиваемого пакета и конверсия из ссылки. Пока приложение монолитное, переход по внешней ссылке стоит человеку полной установки — на слабом канале это 10-15 секунд ожидания и заметная доля отказов, которые случаются ещё до первого экрана.

После разделения на базовый модуль и функциональные модули клиент получает только то, что нужно для текущего сценария. Доля скачиваемого пакета падает до 15-25% от полного объёма, время до первого экрана — до 2-4 секунд, а конверсия из ссылки растёт: пользователь видит нужный экран раньше, чем решает, нужно ли ему приложение целиком. Google Play отдаёт модули по запросу, поэтому глубина сценария ограничена только тем, что вы вынесли в отдельный модуль.

Отдельный эффект — класс отказов, который исчезает совсем: прерванная установка, нехватка места, несовместимая версия, отклонённое обновление. Обновление без полной установки работает на уровне модулей: правка в одном сценарии подтягивается отдельно и не заставляет переустанавливать приложение целиком.

Метрики снимаем до и после: медиана и 90-й перцентиль времени до первого экрана, доля скачиваемого пакета, доля сессий без установки, конверсия из ссылки в целевое действие.

Варианты запуска: Instant Apps, установка, ссылка

Режим доставки решает, что пользователь получает в первые секунды: работу без установки, переход по ссылке в браузер или полноценную установку из магазина. Выбор упирается в одно — какая часть сценария обязана работать сразу, а какая может подождать до следующего визита.

Ограничения платформы задают границы жёстче, чем пожелания к интерфейсу: мгновенный запуск лимитирован по объёму модуля и набору доступных системных возможностей. Ниже — четыре схемы, между которыми реально выбирают на старте.

На практике чаще выигрывает гибридная схема: первый экран отдаём мгновенным модулем, а установку предлагаем в момент, когда пользователь уже получил результат. Тогда переход по ссылке не теряет состояние — корзина, авторизация и прогресс переносятся в установленное приложение, а не начинаются заново.

Порядок работ: аудит, разбиение модулей, проверка

Внедрение мгновенного запуска — это не «сделать ещё одну сборку», а перестройка проекта под модульную архитектуру. Начинаем с аудита: без карты экранов, точек входа и внешних зависимостей не понять, что вообще имеет смысл выносить в запуск без установки. Дальше идём по фиксированной последовательности — от нарезки кода до проверки на живых устройствах и передачи команде.

1. Аудит приложения. Собираем карту экранов и пользовательских путей, список внешних зависимостей, размер сборки и время холодного запуска. На выходе — перечень сценариев, которые реально выигрывают от мгновенного старта.
2. Определение границ сценариев. Решаем, какие пути становятся отдельными модулями, а что остаётся в общем ядре. Ядро держим минимальным: всё, что попадает в мгновенный запуск, напрямую влияет на время до первого экрана.
3. Разбиение на модули. Переносим код в модули-сценарии, общие ресурсы и работу с сетью — в ядро. После каждого шага сверяем, что стартовая часть не раздулась и модуль не тянет лишних зависимостей.
4. Схема зависимостей и правила сборки. Фиксируем направление связей: сценарии зависят от ядра, но не наоборот. Версии выносим в единый каталог, запрет обратных зависимостей проверяем автоматически на сборке — иначе архитектура разъезжается за пару релизов.
5. Проверка на устройствах. Прогоняем сценарии на реальных аппаратах разных производителей, включая слабую сеть и холодный запуск. Отдельно — обновление уже установленного приложения и откат на предыдущую версию.
6. Передача команде. Отдаём документацию по модулям, правила сборки, порядок добавления нового сценария и релиза. Дальше команда заказчика ведёт модули самостоятельно.

Что остаётся у вас: схемы, модули, регламенты

Мы передаём проект не «как есть», а в состоянии, в котором ваша команда выпускает обновления без нас. Комплект описывает модульную архитектуру Android Instant Apps: какая часть кода уходит в мгновенный запуск, какая остаётся в установленном приложении и где проходят границы между модулями.

• Карта модулей — граф зависимостей, точки входа, владелец и границы каждого модуля; отдельно отмечено, что попадает в мгновенный вариант, а что доступно только после установки.
• Настроенные сборки — профили для мгновенного и полного варианта с общими ресурсами и контрактами взаимодействия; проверка на сборочном конвейере не пропускает рост загружаемого пакета выше заданного порога.
• Регламент выпуска — порядок шагов от слияния правок до публикации, обязательные автотесты, кто подтверждает выпуск и в какой момент включается откат на предыдущую версию.
• Политика обновлений — периодичность, каналы (закрытое тестирование, поэтапная раскатка, полный выпуск) и критерии, по которым раскатка останавливается автоматически.
• Инструкция для команды — как развернуть окружение, собрать и проверить мгновенный вариант на устройстве, добавить новый модуль и где смотреть журналы сбоев.
• Схема переходов — какие ссылки открывают мгновенный опыт, в какой момент пользователь переходит в установленное приложение и какие данные при этом переносятся.
• Набор метрик и панель наблюдения — события, по которым видно долю установок после мгновенного запуска и места, где пользователи уходят.

Кейс: вес сборки втрое меньше, сбои запуска ушли

Проект — приложение сети магазинов: каталог, карта лояльности, оформление заказа. Монолит из трёх десятков модулей означал, что правка в каталоге тянет полную пересборку и повторную загрузку всего пакета. Разнесли продукт на независимо собираемые модули и подняли лёгкую точку входа на Android Instant Apps. Кейс внедрения — семь недель от разбора задачи до рабочего релиза.

Что было

Пользователь скачивал 28 МБ и ждал первый экран каталога около четырёх секунд на среднем устройстве. На холодном старте терялось 9% запусков: приложение не успевало отрисовать список или падало на инициализации зависимостей. Каждый такой сбой — потерянный заказ, повторно человек уже не возвращался.

Точку входа собрали из одного модуля каталога: по ссылке человек получает список товаров без установки, а оформление заказа догружается отдельным модулем. Общие библиотеки вынесли в базовый слой, связи между модулями описали явно, сборку сделали инкрементальной — пересобирается только изменённая часть.

Результат

Вес сборки, которую скачивает пользователь, упал с 28 до 9 МБ, первый экран открывается примерно за полторы секунды, доля неудачных запусков — ниже 3%. Полное время сборки сократилось с 14 до 5 минут, а откат на предыдущий релиз занимает один шаг. Следующий этап — карта лояльности на том же модульном контуре.

Что делать, если приложение уже собрано монолитом?

Монолит не переписывают целиком — на время переписывания релизы встают, а регрессии собираются в один общий пакет. Рабочий путь другой: точка входа оформляется отдельным модулем внутри той же кодовой базы, собирается в Android App Bundle и выпускается независимо, а основной пакет продолжает выходить по своему графику.

Первыми выносят части без состояния: каталог, поиск, карточка товара, просмотр статуса заказа. Критерий отбора — минимум связей с внутренними сервисами и отсутствие зависимости от локального хранилища: у лёгкого модуля нет права держать постоянные данные. Такой код переезжает почти без правок, потому что уже не завязан на глобальное состояние и работает от сетевого ответа.

Совместимость версий держится на трёх вещах: имя пакета и подпись остаются прежними, поэтому обновление приходит на уже установленные устройства без переустановки; связи между модулями описываются контрактами, а не прямыми вызовами; ядро и вынесенный модуль версионируются отдельно, чтобы откат касался только одной части.

Главные риски миграции — скрытые связи через общее состояние, дублирование ресурсов и рост времени сборки. Их снимают до первых правок: строят граф зависимостей, запрещают модулям обращаться друг к другу напрямую и проверяют сборку каждого модуля отдельно на сборочном конвейере. Тогда вынос следующего куска превращается в плановую задачу, а не в остановку продукта.

Технические сомнения и ограничения платформы

Ограничения платформы проявляются не на демо, а на живом потоке: часть устройств не поддерживает мгновенный запуск, часть ограничивает фоновую установку. До старта мы фиксируем матрицу совместимости — какие версии системы и оболочки производителей покрываем, а что показываем остальным: тот же экран, но через обычную установку из магазина.

Второй слой — доступ к функциям, аналитика и обновления. Мгновенный модуль получает урезанный набор разрешений, поэтому камеру, оплату и геолокацию проверяем отдельно на каждом сценарии. Переход в установленное приложение размечаем единым событием: без этого воронка обрывается на середине и доля дошедших до установки считается неверно.

Как считается аналитика переходов между модулем и приложением?

События мгновенного модуля и установленного приложения идут разными потоками, поэтому без единого идентификатора сессии они не сходятся. Мы размечаем вход, ключевые шаги и установку общим признаком — тогда видно, на каком экране теряется пользователь и что именно стоит упростить.

Что с безопасностью данных при мгновенном запуске?

Модуль работает в изолированной среде и не сохраняет ключи доступа между запусками. Критичные данные не кэшируем, авторизацию проверяем при каждом входе, обмен идёт только по защищённому каналу — требования к хранению здесь строже, чем в обычном приложении.

Насколько часто можно выпускать обновления?

Мгновенный модуль обновляется вместе с релизом в магазине и подхватывается при следующем запуске, без действий со стороны пользователя. Единственное ограничение — размер модуля: чем он тяжелее, тем выше доля отказов при загрузке, поэтому крупные разделы мы выносим в установленную часть.

Обсудим вашу задачу: что нужно для старта работ

Чтобы мы вернулись с оценкой сроков, а не с общими словами, нужен минимум входных данных о текущем состоянии проекта и границах задачи. Опишите её в свободной форме: назначение приложения, что уже работает и что мешает. Уточняющие вопросы зададим сами — на этом этапе важнее контекст, чем формальное описание требований.

• Ссылку на репозиторий или архив проекта: по коду видно состояние модулей, зависимости и накопленный долг.
• Схему модулей и их границ — что уже выделено, что связано напрямую, где логика дублируется между основным приложением и сценарием Android Instant Apps.
• Описание сценария, который должен запускаться без установки: что пользователь делает в первые секунды и какой результат считается успехом.
• Данные о релизном цикле: как часто выходят версии, сколько занимает сборка, кто проверяет изменения перед выпуском.
• Ограничения: минимальная версия системы, список целевых устройств, требования к доступам и хранению персональных данных.
• Ответственного с вашей стороны — того, кто подтверждает приоритеты и принимает промежуточные результаты.
• Ожидания по срокам и точки, в которых нужна промежуточная приёмка.

После разбора вернёмся с оценкой сроков, схемой работ по модулям, планом внедрения и составом команды — с ролями и загрузкой по этапам. Если часть данных отсутствует, это не блокирует старт: зафиксируем допущения и уточним их по ходу.