Uso de memoria (RSS anónimo + intercambio)

El uso de memoria (RSS anónimo + espacio de intercambio) es una métrica de Android vitals que refleja el uso de memoria de tu app.

La memoria anónima es la memoria que no está respaldada por un archivo en el almacenamiento, como las asignaciones de montón y la memoria asignada por mmap. Esto captura las asignaciones de memoria dinámicas de tu app, incluida la pila de Java o Kotlin, las asignaciones de pila nativa no administradas (donde residen los datos de píxeles de Bitmap en Android 8.0 [nivel de API 26] y versiones posteriores) y las pilas de ejecución de subprocesos. Si bien el SO puede liberar memoria respaldada por archivos bajo presión, no puede liberar memoria anónima.

El tamaño del conjunto residente (RSS) es la cantidad total de páginas de memoria (compartidas y no compartidas) que utiliza un proceso y que se almacenan en la RAM física. Una página se considera "compartida" si más de un proceso accede a ella (por ejemplo, apps que acceden a la misma biblioteca).

En el caso de la memoria anónima, el sistema puede escribir páginas en el espacio de intercambio (o zRAM en Android) cuando la memoria está bajo presión. El sistema puede volver a leer estas páginas desde el intercambio si es necesario.

En conjunto, el uso de memoria (RSS anónimo + intercambio) es una medida de la cantidad total de páginas de memoria de tu app que no están respaldadas por un archivo en el almacenamiento, incluida cualquier memoria que el sistema también conserve en el intercambio. El seguimiento anónimo de RSS y el intercambio garantizan que veas el espacio en memoria real y no expulsable de tu app.

Si el uso de memoria de tu app es alto, investiga más a fondo y corrige el problema con las indicaciones de esta página.

Identifica el uso elevado de memoria

Android vitals

Android vitals comparte el uso de memoria de tu app desglosado por los siguientes estados de proceso:

  • Primer plano: El proceso de la app es visible. Un P99 alto suele afectar el rendimiento percibido por el usuario (bloqueos o fallas por OOM) y se debe en gran medida a componentes o actividades de la IU que no se desalojan.
  • Servicio en primer plano: La app está ejecutando un servicio en primer plano. Debido a que estos servicios están diseñados para tareas de larga duración, son candidatos ideales para las pérdidas acumulativas del ciclo de vida que inflan de forma agresiva la cola del P99 con el tiempo.
  • Segundo plano: La app está ejecutando un servicio en segundo plano o pasó a segundo plano recientemente, pero aún no se almacenó en caché. Aquí es donde se acumulan las pérdidas del procesamiento en segundo plano.
  • Almacenada en caché: La app está en estado de caché. Este estado es muy sensible a la presión de la memoria del sistema, como los LMK. Dado que el SO puede expulsar este estado del proceso a voluntad, este estado solo se proporciona con fines de depuración.

Para comprender cómo se correlacionan estos estados del proceso con las devoluciones de llamada de onTrimMemory, consulta la guía para liberar memoria en respuesta a eventos.

Android vitals también desglosa el uso de memoria de tu app por intervalos de RAM. La métrica de uso de memoria se muestra como una línea de tiempo de los valores de percentil diarios, junto con el valor diario más reciente para los percentiles 50 y 90.

Una vez que hayas identificado tu valor de referencia de memoria, sigue la guía para diagnosticar y mejorar el uso excesivo de memoria.

Identifica las fugas de memoria con el sesgo de cola

Para identificar pérdidas de memoria, busca una divergencia entre tus usuarios típicos (P50) y los usuarios de la cola (P90) en Android vitals. Si bien el aumento general de recursos infla la memoria de manera uniforme en todos los percentiles, las pérdidas de memoria se agravan con el tiempo, lo que sesga en gran medida los datos del extremo inferior.

Debes comparar tus métricas de P90 y P99 con tu modelo de referencia de P50 por nombre de proceso. Si la proporción entre el P90 y el P50 supera 3.5, indica una posible fuga de memoria durante las sesiones prolongadas. En ciertos casos de uso, una proporción elevada no siempre indica una fuga, pero debes evaluar el flujo de trabajo específico para determinar si el uso elevado de memoria es el comportamiento esperado.

Recursos

Diagnostica el uso excesivo de memoria de forma local

Para comenzar a diagnosticar la fuente del uso excesivo de memoria, puedes capturar un volcado de montón con Record heap dump en la configuración del desarrollador, Android Studio o Perfetto. Te recomendamos que comiences por capturar un volcado de montón de forma local después de probar los recorridos del usuario principales de tu app.

En especial, te recomendamos que pruebes los siguientes recorridos del usuario:

  • Sesiones de navegadores integrados en la app y vistas web
  • Desplazamiento infinito con mucho contenido multimedia
  • Flujos de creación y edición de recursos

Para investigar posibles pérdidas de memoria, primero identifica los procesos que consumen más memoria con la tabla Nombre del proceso en el panel de Android vitals sobre el uso de memoria. A continuación, ejecuta los recorridos del usuario correspondientes de forma local y recopila volcados de montón en diferentes estados del proceso (visible, servicio en primer plano y en caché) para verificar si la app libera memoria después de pasar a segundo plano.

Si depuras problemas de memoria con el Generador de perfiles de Android Studio, también puedes integrar LeakCanary para optimizar la detección de fugas y la detección de mapas de bits duplicados para optimizar el uso de imágenes.

Después de recopilar el volcado de montón, te recomendamos que uses las habilidades de Perfetto AI para analizarlo y, así, identificar posibles fuentes de uso elevado de memoria.

Este es un ejemplo de lo que podrían responder las habilidades de IA:

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.

Recursos adicionales para interpretar volcados de montón

Los siguientes recursos proporcionan más información para interpretar volcados de montón y depurar el uso de memoria:

Mejora el uso de la memoria

Consulta estas secciones para obtener más información sobre cómo mejorar el uso de memoria de tu app:

Para obtener orientación detallada sobre cómo corregir problemas de memoria, consulta la guía Cómo administrar la memoria de tu app.

Anterior
Optimizadores de poca memoria (LMK)
Siguiente
Bloqueos de activación parciales sostenidos