Подготовьте ваше приложение к более широким ограничениям объема памяти

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

В Android 17 ввели ограничения памяти для отдельных приложений, начав с устройств Pixel. Их задача — защитить общую отзывчивость системы от приложений, которые потребляют слишком много памяти и вызывают замедление всего устройства. В течение следующего года всё больше производителей начнут использовать ограничения памяти Android для приложений на устройствах с объёмом ОЗУ от 4 ГБ до 16 ГБ и более. Если приложение превысит эти лимиты, система замедлит его работу, а затем может завершить процесс. Поэтому уменьшение объёма потребляемой приложением памяти становится критически важным: это помогает избежать ограничения производительности со стороны ОС и сохранить плавный пользовательский опыт.

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

Как работают ограничения памяти

Когда приложение превышает выделенный ему бюджет памяти, Android постепенно применяет меры для сохранения отзывчивости устройства.

1. Перенос страниц в zRAM. Если приложение достигает установленного лимита, система принудительно переносит его страницы памяти в zRAM — сжатую область оперативной памяти. zRAM позволяет избежать немедленного вытеснения данных, но сжатие и распаковка страниц создают дополнительную нагрузку на процессор. В результате могут появляться заметные подёргивания интерфейса и общее снижение производительности.
2. Завершение процесса. Если приложение продолжает увеличивать потребление памяти и выходит за пределы порога zRAM, система завершает его процесс. Чтобы определить, было ли завершение связано именно с этими ограничениями, можно вызвать getDescription() у ApplicationExitInfo. Если сработал ограничитель памяти, причиной завершения будет указана REASON_OTHER, а строка описания будет содержать MemoryLimiter:AnonSwap. Также можно использовать профилирование по триггерам с TRIGGER_TYPE_ANOMALY, чтобы автоматически сохранять дампы кучи при достижении лимита памяти.

Подробнее о лимитах памяти для отдельных приложений и о том, как система применяет ограничения, можно прочитать в документации Android 17 App Memory Limits. Для тестирования приложения на устройствах с различными конфигурациями памяти можно использовать adb-команды Memory Limiter.

Мониторинг и диагностика проблем с памятью

Нельзя оптимизировать то, что нельзя измерить. Для поиска утечек памяти, чрезмерных выделений в куче и сбоев Out-Of-Memory во всей экосистеме Android стоит использовать несколько дополняющих друг друга инструментов.

• Общая картина с помощью Android vitals. Для анализа поведения приложения на большой аудитории без дополнительной нагрузки Google Play Console предоставляет Android vitals с такими метриками, как Memory Usage (Anonymous RSS + swap) и Bitmap Memory Usage. Они показывают распределение памяти по различным состояниям процесса — на переднем плане, в фоне, в сервисах, заметных пользователю, и в кэшированном состоянии — а также по классам устройств с разным объёмом ОЗУ. Это помогает быстро находить аномально прожорливые конфигурации.
• Отслеживание Memory Limiter и OOM через Firebase Crashlytics. Чтобы замечать серьёзные проблемы с памятью ещё до того, как они повлияют на ключевые показатели, Crashlytics 20.1.0 добавляет дополнительные отладочные данные для поиска, приоритизации и исправления ошибок Out-Of-Memory и завершений процессов из-за ограничителя памяти. Если сопоставлять такие события с собственными журналами и метаданными в виде пар ключ-значение, можно сразу получить контекст состояния процесса в момент сбоя.
• Профилирование на реальных устройствах через ProfilingManager. Для команд, которые поддерживают собственную систему наблюдения за производительностью, интерфейс ProfilingManager, появившийся в Android 15 (API 35), позволяет программно запрашивать и собирать подробные диагностические данные непосредственно с пользовательских устройств. В частности, можно получать дампы Java-кучи и профили памяти. Также можно автоматически запускать создание дампа по системным сигналам, включая TRIGGER_TYPE_OOM и TRIGGER_TYPE_ANOMALY.

Подробнее о других способах мониторинга памяти можно прочитать в документации.

Итоги и дальнейшие шаги

Поскольку Android расширяет использование лимитов памяти для отдельных приложений на устройства всех классов ОЗУ, сейчас самое время провести аудит потребления памяти вашим приложением.

1. Сделайте оптимизацию памяти приоритетной. Чтобы приложение не попадало под ограничения, следуйте рекомендациям по эффективному использованию памяти.
2. Следите за потреблением памяти. Мониторьте поведение приложения, чтобы вовремя выявлять и устранять аномалии.
3. Оптимизируйте игры. Для игр и сложных мультимедийных приложений используйте актуальные рекомендации, чтобы максимально сократить потребление памяти во всех состояниях процесса.

Полезные материалы

• Android 17 Behavior Changes: App Memory Limits
• Android Vitals: Memory Usage (RSS + swap) и Bitmap Memory Usage
• Android Developers Blog: Prioritizing memory efficiency steps for Android 17
• Руководство разработчика: Manage your app’s memory

Источник