Приложение долго открывается, подтормаживает при прокрутке или закрывается без предупреждения. Пользователь не разбирается в причинах и уходит, а недовольство остаётся в оценках.
Оптимизацию мобильных приложений ведут по измерениям: замер показывает, что не так, правка устраняет причину, повторный замер подтверждает результат. Без метрики неясно, что стало лучше. Для Google Play у метрик есть и коммерческий смысл: по справке Google, приложение за порогами плохого поведения, вероятно, реже показывается в магазине. Работа идёт на двух уровнях, в самом приложении и в его карточке. Ниже даны пороги метрик и порядок работ, по которым результат задачи проверяется числом.
- Что такое оптимизация мобильных приложений
- Как производительность приложения влияет на видимость
- Метрики производительности и пороги Android vitals
- Что менять в приложении, чтобы оно работало быстрее
- Оптимизация под Android, iOS и слабые устройства
- Порядок оптимизации и инструменты для замера
- Оптимизация карточки приложения в Google Play и App Store
- FAQ по оптимизации мобильных приложений
- Коротко о главном
Что такое оптимизация мобильных приложений
Оптимизация мобильного приложения — это работа над скоростью, стабильностью и расходом ресурсов устройства: памятью, процессором, батареей, трафиком и местом в хранилище. Цель в том, чтобы приложение быстро запускалось, отвечало на действия пользователя и не падало на разных телефонах и версиях системы.
Для бизнеса это значит меньше жалоб и удалений мобильного приложения. Второй слой работ — оптимизация карточки в магазинах, или ASO (App Store Optimization): она влияет на то, находят ли приложение в поиске. Слои решаются разными действиями и командами.
| Слой | Что решается | Кто отвечает |
|---|---|---|
| Производительность приложения | Запуск, плавность, падения, расход ресурсов | Разработка |
| Карточка в Google Play и App Store | Название, ключевые слова, иконка, скриншоты, отзывы | Маркетинг и ASO |
Как производительность приложения влияет на видимость
Основные технические метрики качества (core vitals) в консоли разработчика Play Console влияют на видимость приложения в Google Play. Если приложение выходит за пороги плохого поведения, оно, вероятно, показывается реже, а на карточке в ряде случаев появляется предупреждение. Какой вес у каждой метрики, Google не раскрывает. По отчёту Instabug (ныне Luciq) за 2024 год, собранному по приложениям на платформе мониторинга, а не по всему рынку, оценке в 3 звезды соответствует доля сессий без падений порядка 99,7 %, а оценке выше 4,5 звезды — порядка 99,85 %. Авторы отчёта описывают это как корреляцию, а не правило магазинов.
Удержание работает через пользовательский опыт: нестабильное приложение раздражает, и вероятность возврата снижается. Платный трафик приводит новых людей в то же приложение, поэтому при падениях у порогов качество стоит поставить в приоритет раньше закупки трафика.
Метрики производительности и пороги Android vitals
Android vitals — это раздел Play Console с метриками качества приложения по данным реальных пользователей. Стабильность описывают две метрики. Доля пользователей с заметным падением — это доля ежедневных пользователей хотя бы с одним падением, которое человек, вероятно, заметил. Доля с заметным ANR (Application Not Responding, «приложение не отвечает») считается так же, но сейчас в неё входит только тип «input dispatching timed out».
Для видимости в Google Play Google задаёт пороги плохого поведения отдельно по среднему значению и по каждой модели устройства. Это значения для приложений на телефонах, для часов пороги другие, а числа взяты из справки Google на 2026 год и могут быть пересмотрены.
| Метрика | Значение по справке Google | Условие |
|---|---|---|
| Заметные падения | 1,09 % в среднем, 8 % на модель | Порог видимости, телефоны |
| Заметные ANR | 0,47 % в среднем, 8 % на модель | Порог видимости, телефоны |
| Чрезмерные wake lock (фоновые блокировки, которые не дают устройству уснуть) | 5 % сессий за 28 дней | Порог видимости с 1 марта 2026 года |
| Медленный запуск с нуля, возврат при живом процессе, возврат на загруженный экран | 5 секунд, 2 секунды, 1 секунда и больше | Определение метрики Play Console, не порог видимости |
| Отрисовка кадра | Быстрее 16 мс при 60 кадрах в секунду (11 мс при 90, 8 мс при 120); замороженный кадр — дольше 700 мс | Интерфейсы на системе View |
Начинать стоит со строк с порогами видимости, а остальные строки помогают найти причину. Метрики Play Console нельзя напрямую сравнивать с независимыми отчётами: Play Console считает падения на ежедневного пользователя, а Instabug — на сессию.
Что менять в приложении, чтобы оно работало быстрее
Запуск, главный поток и размер сборки
Правки ставят по четырём направлениям, и у каждого есть цепочка «метрика, причина, действие». Самые доказанные из них — главный поток и сборка. ANR возникает, когда главный поток приложения, отвечающий за интерфейс, заблокирован слишком долго. Для ввода порог составляет 5 секунд без реакции на касание, у других типов ANR он иной. Причины по документации Google — медленный ввод-вывод и долгие вычисления в главном потоке, а действие одно: вынести их оттуда. Запуск оптимизируют в расчёте на холодный старт, это может улучшить тёплый и горячий, а следить стоит за временем до первого кадра (TTID) и до полной готовности (TTFD).
Размер сборки сокращает R8 — оптимизатор Android, который удаляет неиспользуемые код и ресурсы, переписывает код для скорости и сокращает имена классов и методов. По документации Google это даёт более быстрый запуск, меньшее потребление памяти и меньше ANR, но выигрыш зависит от приложения. С февраля 2027 года Google Play требует, чтобы оптимизация, сжатие и обфускация через R8 или аналогичный инструмент охватывали не меньше 25 % кода. Правила keep, в которых разработчик перечисляет код, не подлежащий удалению, требуют проверки из-за рефлексии, то есть обращения к коду по имени во время работы.
Память, фон и батарея
Утечка памяти — это ситуация, когда приложение удерживает память, которая ему уже не нужна. Система чаще запускает сборку мусора и в итоге может завершить процесс, а пользователь видит подтормаживания, пропуск кадров, зависания и падения. Чтобы найти утечки, в Android Studio снимают дамп кучи, то есть снимок объектов в памяти, после длительного сеанса работы. С февраля 2027 года, по записи блога Google от 26 августа 2026 года, приложения должны укладываться в пороги по памяти, в том числе по памяти под изображения, иначе Google Play может снизить видимость и ограничить публикацию.
Разработчику мобильных приложений задачу по фону формулируют как запрос на отчёт: какие фоновые задачи работают, какие срочные, а какие можно запускать при зарядке или на безлимитном Wi-Fi. Однотипные задачи Google советует объединять в одну, чтобы устройство просыпалось один раз, а неверно выбранное управление фоном может помешать публикации в Google Play. С 1 марта 2026 года Google Play учитывает и чрезмерные wake lock: если они есть больше чем в 5 % сессий за 28 дней, приложение может реже попадать в рекомендации, а на карточке может появиться предупреждение о расходе батареи.
Сеть, запросы и изображения
Приложение тормозит и тратит трафик, когда делает лишние запросы, повторно загружает одни и те же данные и держит в памяти тяжёлые изображения. Google рекомендует кэшировать данные как можно активнее, включая полноразмерные изображения, и использовать HTTP-заголовки кэширования, чтобы не показывать устаревшее. Частые запросы пользователя, например обновление экрана свайпом, стоит ограничивать, так как каждый тратит заряд. Изображение загружают в разрешении элемента интерфейса: большее не даёт выигрыша, но занимает память.
Часть задержек лежит вне приложения, в ответе сервера и API, то есть интерфейса, через который приложение обращается к серверу. Если экран ждёт сервер, задачу ставят команде бэкенда.
Сначала правьте ту метрику, которая уже вышла за порог видимости или близка к нему, а остальные оставьте на следующий замер.
Оптимизация под Android, iOS и слабые устройства
Приложение может укладываться в пороги в среднем и плохо работать на одной массовой модели телефона, поэтому порог 8 % на модель важен не меньше среднего. В Play Console показатели можно разбить по версии приложения и версии Android, по типу и модели устройства, а также по стране. По тем же данным Instabug (Luciq) за 2024 год медианная доля сессий без падений на iOS составила 99,91 %, на Android — 99,80 %.
Слабые модели проверяют отдельно, в том же разрезе по модели и версии Android. По документации Android, сборка мусора во время анимации может вывести отрисовку кадра за 16 мс. Для iOS метрики запуска, отзывчивости, памяти и энергии доступны в Xcode Organizer, окне Xcode с отчётами по приложению, с разбивкой по модели устройства, а данные реальных устройств присылает системный фреймворк MetricKit.
Порядок оптимизации и инструменты для замера
Цикл оптимизации описан в документации Apple: измерить, изменить одну вещь, проверить результат. Тот же порядок подходит и для Android.
- Поставьте цель и выберите метрики: запуск, плавность, падения, ANR, память.
- Измерьте исходные значения до правок.
- Найдите причину профилировщиком и данными реальных пользователей.
- Измените одну вещь и сравните метрики до и после.
- Закрепите результат мониторингом после релиза.
Профилировщик Android Studio показывает, где приложение неэффективно использует процессор, память, графику и батарею. Android vitals собирает данные работы приложения с мобильных устройств пользователей и показывает масштаб проблемы. Для iOS эти роли выполняют Instruments, профилировщик Xcode, и Xcode Organizer.
Профилируйте релизную сборку, как советует документация Android Studio, а для оптимизации запуска записывайте трассу с самого старта приложения.
.jpg)
Тестирование до релиза и мониторинг после него
Измерения лучше снимать на реальном устройстве: Apple отмечает, что они точнее, чем в симуляторе. Для замеров запуска и анимаций в Android есть библиотека Macrobenchmark: Google советует запускать её проверки регулярно, чтобы не пропустить регрессии. Версии сравнивают на одном наборе устройств и в одинаковых условиях сети. После выхода версии её показатели сверяют с предыдущей по тем же метрикам и порогам из таблицы, а ухудшение возвращает к замеру.
Ошибки процесса, из-за которых замеры теряют смысл:
- оптимизация без замера, когда эффект оценивают на глаз;
- сравнение версий на разных устройствах и при разной сети;
- работа в главном потоке принимается за норму;
- одновременная правка нескольких вещей.
Оптимизация карточки приложения в Google Play и App Store
Результаты поиска в App Store зависят от текстовой релевантности и поведения пользователей. Релевантность — это совпадение запроса с названием, подзаголовком, ключевыми словами и категорией, а поведение — загрузки, оценки и отзывы. Поле ключевых слов ограничено 100 символами, слова из названия, подзаголовка и категории в нём повторять не нужно. В Google Play, помимо технического качества, над карточкой работают через название, описание, иконку, скриншоты и отзывы.
Такую работу показывает кейс Mobisharks, агентства из Kokoc Performance: с 2023 года команда продвигает приложения двух аптечных брендов в App Store и Google Play, названия брендов в кейсе не раскрываются. Специалисты разделили семантическое ядро (более 300 запросов на каждое приложение), переписали метаданные, обновили скриншоты и работали с репутацией, а с августа 2025 года подключили performance-трафик. С 2024 по 2025 год доля рекламных расходов приложения 1 в Google Play снизилась с 3,33 % до 1,27 %. По данным кейса, загрузки этого приложения в App Store выросли на 467 % и достигли 2,63 млн. Результат дал весь комплекс ASO и performance-каналов, а не отдельная правка. Подробности по этапам — на странице кейса об ASO двух аптечных приложений.
FAQ по оптимизации мобильных приложений
Как отличить проблему приложения от проблемы устройства?
Сравните показатели по версиям приложения и по моделям, а не среднее значение. Если сбои начались с последней версии на всех моделях, причина в самом приложении. Если они держатся на одной модели или версии Android во всех сборках, причина в совместимости или нехватке ресурсов устройства.
Как часто проверять метрики?
Данные Android vitals обновляются ежедневно, а почтовые уведомления сейчас приходят только при аномалиях, поэтому отчёт нужно открывать самим. Открывайте его после релиза и перед увеличением рекламного бюджета: так видно, не вышла ли новая версия за пороги.
Чем отличается от оптимизации мобильного сайта?
У сайта и веб-приложений свой набор метрик загрузки страницы, Core Web Vitals. У мобильного приложения другие показатели: Android vitals в Play Console и данные магазинов, поэтому оценивают его по ним.
Коротко о главном
- Оптимизация мобильного приложения — это работа над скоростью, стабильностью и расходом ресурсов в самом приложении и в его карточке в магазине.
- Оптимизацию приложения ведут по цепочке «замер → причина → правка → проверка», а не наугад.
- По справке Google, пороги видимости в Google Play — 1,09 % падений и 0,47 % ANR в среднем, 8 % на модель и 5 % сессий с чрезмерными wake lock; с февраля 2027 года добавятся пороги по памяти и требование оптимизировать код.
- Порядок работ: цель, замер, причина, одна правка, сравнение до и после, мониторинг.
- Правки ставят по четырём направлениям: запуск и главный поток, память и фон, сеть и изображения, размер сборки.
.png)
.png)
Комментарии
Комментариев пока нет. Будьте первым!
Оставить комментарий