Grab сократила ANR примерно на треть: что изменили в сборке Android-приложения
Кейс от 19 октября описывает поэтапную оптимизацию большого приложения: R8, точные правила сохранения классов и профили важных пользовательских сценариев. Итоговые проценты относятся к внедрению нескольких инструментов.
Почему обновления становились трудным моментом
У Grab десятилетняя кодовая база с более чем десятью миллионами строк и сотнями сторонних библиотек. После очередного выпуска пользователи сталкивались с пиками ANR — ситуациями, когда приложение не отвечает. Команда связывала проблему в том числе с чтением множества DEX-файлов и затратами на подготовку кода при старте. В опубликованном кейсе суммарный результат оценивается примерно в 32,5% снижения пользовательских ANR, 30,4% уменьшения загрузки и 35% улучшения холодного запуска. Это показатели Grab, а не универсальная гарантия Android.
Оптимизатор и профиль решают разные задачи
R8 анализирует приложение при сборке, удаляет недостижимый код и выполняет преобразования, уменьшающие работу во время исполнения. Baseline Profile описывает важные пути выполнения, которые Android Runtime может заранее скомпилировать. Такой профиль полезен уже после установки или обновления: критический сценарий меньше зависит от того, успела ли система накопить сведения о реальном использовании. Startup Profile дополняет эту работу организацией кода для запуска. Эти инструменты нельзя считать взаимозаменяемыми: более компактная программа всё ещё может плохо выбирать, что именно исполнять первым. Baseline Profile перечисляет участки кода, соответствующие важным действиям, и поставляется вместе с приложением либо библиотекой. Cloud Profiles формируются другим способом — по использованию приложения аудиторией. В истории Grab именно собственные пути инициализации, недостаточно охваченные общими профилями, стали причиной внедрения своего набора. Профиль не содержит оптимизированную копию всех данных пользователя и не заменяет базу приложения: это описание кода для подготовки исполнения. Разница объясняет, почему новая установка и обновление уже используемой программы могут получать пользу с первого запуска.
Переход в полный режим потребовал разбирательства с отражением
В 2025 году команда включила оптимизацию в совместимом режиме, а в 2026-м перешла на R8 Full Mode. Особого внимания потребовали библиотеки и участки, использующие reflection и динамические прокси. Компилятор не всегда видит такие обращения как обычные вызовы, поэтому может удалить или переименовать нужный класс. Документация R8 объясняет назначение keep rules: они сохраняют конкретные элементы, необходимые во время выполнения. Широкое исключение для всего пакета уменьшает пользу оптимизации, а чрезмерно узкое способно сломать сериализацию. Поэтому перенос сопровождался проверкой реальных сценариев, а не только успешной компиляцией.
Как читать опубликованные проценты
Эффекты этапов нельзя просто складывать: второй процент считается от состояния после первого изменения. В таблице Grab раздельно приведены совместимый режим, полный режим и уточнение keep rules. Профили также должны соответствовать актуальным путям запуска и навигации. В официальном описании Baseline Profiles речь идёт об оптимизации отмеченного кода, а не ускорении любой операции приложения. Сетевое ожидание или медленный сервер профиль не устраняет. Продолжение проекта Grab связано с анализом конфигурации и контролем новых правил в процессе сборки — опубликованные показатели не означают, что работа над приложением завершена.
Измерения относятся к выпуску целиком
Для сравнения важны одинаковый класс устройства, тип запуска и состояние после установки. Отладочная сборка может вести себя иначе, чем оптимизированная рабочая. Поэтому числовые результаты кейса описывают наблюдение команды, а не сумму независимых рекламных обещаний инструментов. Восстановление после обновления, сериализация данных и фоновые задачи также входят в область проверки: небольшой размер пакета не компенсирует ошибку, мешающую открыть существующие данные пользователя.
