Uso de memoria (RSS anónimo + intercambio)

El uso de memoria (RSS anónimo + espacio de intercambio) es una métrica 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, incluido el montón de Java o Kotlin, las asignaciones de montón nativo no administrado (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 (tanto compartidas como no compartidas) que utiliza un proceso y que se almacenan en la RAM física. Se considera que una página es "compartida" si se accede a ella desde más de un proceso (como las 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 del RSS anónimo y del espacio de intercambio garantiza 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.

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, ejecuta los flujos 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. 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.

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

Después de recopilar el volcado de montón, te recomendamos que uses la habilidad de Android Profiler para analizarlo y, luego, 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.