Эта страница переведена с помощью Cloud Translation API.

Использование памяти (анонимный RSS + файл подкачки)

Использование памяти (анонимный RSS + файл подкачки) — это показатель в Android Vitals, отражающий использование памяти вашим приложением.

Анонимная память — это память, не связанная с файлом в хранилище, например, выделенная память в куче и память, выделенная с помощью mmap. Это включает в себя динамическое выделение памяти вашим приложением, в том числе память в куче Java или Kotlin, неуправляемое выделение памяти в собственной куче (где хранятся пиксельные данные Bitmap в Android 8.0 (уровень API 26) и выше), а также стеки выполнения потоков. Хотя ОС может освободить память, связанную с файлом, под давлением, она не может освободить анонимную память.

Resident Set Size (RSS) is the total number of memory pages (both shared and non-shared) used by a process that are held in physical RAM. A page is considered "shared" if it's accessed by more than one process (such as apps that access the same library).

В случае использования анонимной памяти система может записывать страницы в пространство подкачки (или zRAM на Android), когда память испытывает нехватку. При необходимости система может считать эти страницы обратно из пространства подкачки.

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

Если ваше приложение использует много памяти, проведите дальнейшее исследование и устраните проблему, следуя инструкциям на этой странице.

Выявление случаев интенсивного использования памяти

Основные параметры Android

Android Vitals отображает использование памяти вашим приложением в разбивке по следующим состояниям процесса :

Передний план : Процесс приложения виден. Высокий показатель P99 здесь часто влияет на воспринимаемую пользователем производительность (заикания или сбои из-за нехватки памяти) и в значительной степени обусловлен невытесненными компонентами или действиями пользовательского интерфейса.
Служба переднего плана : Приложение запускает службу переднего плана . Поскольку эти службы предназначены для длительных задач, они являются основными кандидатами на накопление утечек жизненного цикла, которые со временем значительно увеличивают хвост P99.
Фоновая ситуация : приложение работает в фоновом режиме или было переведено в фоновый режим, но кэш еще не создан. Именно здесь усугубляются проблемы, связанные с фоновой обработкой.
Кэшированное состояние : Приложение находится в кэшированном состоянии. Это состояние очень чувствительно к нагрузке на системную память, например, к LMK-сообщениям. Поскольку ОС может по своему усмотрению освободить это состояние процесса, эта информация предоставляется только для целей отладки.

Чтобы понять, как эти состояния процесса соотносятся с обратными вызовами onTrimMemory , обратитесь к руководству по освобождению памяти в ответ на события .

Android Vitals также отображает использование памяти вашим приложением по сегментам оперативной памяти. Показатель использования памяти отображается в виде временной шкалы ежедневных значений в процентилях, а также самых последних ежедневных значений для 50-го и 90-го процентилей.

После определения вашего базового уровня памяти следуйте приведенным ниже рекомендациям для диагностики и улучшения ситуации с чрезмерным использованием памяти.

Выявление утечек памяти с помощью анализа асимметрии хвоста распределения

Чтобы выявить утечки памяти, обратите внимание на расхождение в показателях производительности Android между типичными (P50) и последними (P90) пользователями. В то время как общее раздувание ресурсов равномерно увеличивает объем памяти во всех процентилях, утечки памяти накапливаются со временем, сильно искажая данные по последним пользователям.

Следует сравнить показатели P90 и P99 с базовым показателем P50 по имени процесса. Если соотношение P90 к P50 превышает 3,5x, это указывает на вероятную утечку памяти во время длительных сеансов работы. В некоторых случаях повышенное соотношение не всегда свидетельствует об утечке, но следует оценить конкретный рабочий процесс, чтобы определить, является ли повышенное использование памяти ожидаемым поведением.

Ресурсы

Диагностика чрезмерного использования памяти локально.

Для начала диагностики источника чрезмерного использования памяти вы можете сделать дамп кучи с помощью функции «Запись дампа кучи» в настройках разработчика, Android Studio или Perfetto . Мы рекомендуем начать с создания локального дампа кучи после тестирования основных пользовательских сценариев вашего приложения.

Мы особенно рекомендуем протестировать следующие сценарии взаимодействия пользователя с системой:

Веб-просмотры и внутриприложения браузерные сессии
Бесконечная прокрутка с большим количеством медиаконтента
Процессы создания и редактирования активов

Для исследования потенциальных утечек памяти сначала определите процессы с наибольшим потреблением ресурсов, используя таблицу имен процессов на панели мониторинга использования памяти Android Vitals. Затем запустите соответствующие сценарии взаимодействия с пользователем локально и соберите дампы памяти в различных состояниях процессов (видимый, работающий на переднем плане и кэшированный), чтобы проверить, освобождает ли приложение память после перехода в фоновый режим.

Если вы отлаживаете проблемы с памятью с помощью профилировщика Android Studio, вы также можете использовать интеграцию с LeakCanary для упрощения обнаружения утечек памяти и выявления дубликатов растровых изображений, чтобы оптимизировать использование изображений .

После получения дампа памяти мы рекомендуем использовать инструменты Perfetto AI Skills для его анализа и выявления потенциальных источников интенсивного использования памяти.

Вот пример того, что могли бы ответить навыки искусственного интеллекта:

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

Дополнительные ресурсы для интерпретации дампов памяти

Следующие ресурсы содержат дополнительную информацию об интерпретации дампов памяти и отладке использования памяти:

Ручной анализ: Воспользуйтесь руководством Perfetto Heap Dump Explorer, чтобы узнать, как перемещаться по визуализациям дампов кучи и интерпретировать их в пользовательском интерфейсе Perfetto.
Выделение памяти в Java/Kotlin: Прочитайте статью «Визуализация первого дампа кучи ART» для пошагового анализа дампов кучи среды выполнения Android (ART).
Выделение памяти нативными приложениями: обратитесь к документации Perfetto Native Profiling , чтобы узнать, как собирать и анализировать профили памяти нативных приложений (C/C++).
Проверка через командную строку: используйте команду adb dumpsys meminfo , чтобы быстро получить подробную информацию об использовании памяти вашим приложением на устройстве.
Анализ с помощью ИИ: используйте навыки Perfetto AI для проведения анализа на основе LLM, который поможет обнаружить утечки памяти и чрезмерное выделение памяти в ваших трассировках.
Анализ на основе SQL: используйте Perfetto SQL и навыки анализа трассировки для выполнения структурированных запросов и специализированных скриптов для анализа сложных данных трассировки.

Улучшить использование памяти

Для получения дополнительной информации об улучшении использования памяти вашим приложением ознакомьтесь с этими разделами:

Подробные инструкции по устранению проблем с памятью см. в руководстве «Управление памятью вашего приложения» .

Убийцы низкой памяти (LMK)

Зависание частичной блокировки пробуждения