Explicación detallada para el perfil de "adb shell dumpsys meminfo mi-app-name"?

¿Puede alguien darme una explicación detallada sobre el perfil obtenido por adb shell dumpsys meminfo my-app-name ?

El resultado es el siguiente como se menciona en ¿Cómo descubro el uso de memoria de mi aplicación en Android? :

 ** MEMINFO in pid 890 [process-name] ** native dalvik other total size: 10940 7047 N/A 17987 allocated: 8943 5516 N/A 14459 free: 336 1531 N/A 1867 (Pss): 4585 9282 11916 25783 (shared dirty): 2184 3596 916 6696 (priv dirty): 4504 5956 7456 17916 Objects Views: 149 ViewRoots: 4 AppContexts: 13 Activities: 0 Assets: 4 AssetManagers: 4 Local Binders: 141 Proxy Binders: 158 Death Recipients: 49 OpenSSL Sockets: 0 SQL heap: 205 dbFiles: 0 numPagers: 0 inactivePageKB: 0 activePageKB: 0 

¿Qué significa cada columna (nativa, dalvik, otra, total)? Especialmente cuál es la "otra" columna (no puedo entender qué es eso además de nativo y dalvik)? Sería fantástico si alguien puede dar un ejemplo concreto para elaborar sobre esto. Por ejemplo, tengo una aplicación A. A tiene su propio objeto obj_private y su propia biblioteca nativa lib_private. Además, A hace referencia a algún objeto del framework Android obj_shared ya algún lib nativo del framework de Android lib_shared. Y obj_shared referencia alguna lib nativa de Android lib_shared_indirect. Para este caso, ¿puedo decir eso?

  1. El "tamaño total" equivale a toda la memoria utilizada por "obj_private + lib_private + obj_shared + lib_shared + lib_shared_indirect".
  2. El "sucio privado" es igual a la memoria sucia por "obj_private + lib_private"

La razón por la que queremos aclarar esto es: hay un aumento inusual en la memoria de tiempo de ejecución de nuestra última versión de la aplicación en comparación con la versión anterior. Y cuando utilicé el meminfo de los dumpsys, encontré que las columnas "nativo" y "otro" aumentaron dramáticamente. Pero el cambio de la nueva versión solo está relacionado con java y no hay explicación sobre la columna "other". Busqué esto en Google y no encontré ningún documento. También intenté leer el código fuente del adb. Pero he encontrado que es fácil perderse en el código fuente para principiantes como yo. Así que publicar esta pregunta aquí en caso de que alguien puede ayudar.

Ahora tenemos más documentación sobre el uso de la memoria RAM en Android que incluye detalles sobre lo que significan los diferentes números de RAM: Administración de la memoria de la aplicación . En particular, eche un vistazo a la mitad de la página aquí que discute las partes clave del volcado meminfo: Investigando su uso RAM .

Parece que su salida de meminfo es de una versión bastante antigua de Android, antes de poder identificar muchos de los diferentes tipos de asignaciones. Para mapear lo que está viendo a la documentación actual, considere "otro" como todo lo que muestra el volcado moderno además de las secciones nativas y dalvik. En su vertedero, creo que su sección dalvik es en realidad el moderno "Dalvik Heap" y "Dalvik Otros" juntos.

En cuanto a la nativa y otras secciones cada vez más después de sólo un cambio en el código Java, sí, esto puede suceder sin duda. Un número de partes de la API de Java de Android se sitúa encima de las asignaciones nativas, y también puede causar otras asignaciones. El ejemplo clásico de esto sería mapas de bits en Gingerbread y anteriores, donde los datos para el mapa de bits era una asignación nativa en lugar de ser una asignación de matrices en el montón de Java como lo es hoy en día.

El aumento de otras asignaciones puede deberse a una serie de cosas, como se verá en las versiones más recientes de los datos: los cursores de respaldo de memoria, las áreas de memoria compartida de ashmem, los dispositivos que asignan cosas como texturas gráficas, etc. Hay tantas cosas que puede ser difícil decir lo que podría estar pasando, por lo que el informe es más detallado en estos días. (E incluso allí, todavía tenemos un número de cosas que consiguen colapsado adentro a desconocido.)

Para depurar esto, es probable que desee ver su montón de Java para los objetos filtrados. Puesto que la asignación real para el objeto no está en el montón de Java, esto puede ser difícil por supuesto. Yo sugeriría tomar un volcado de montón al principio de su aplicación, hacer lo que haga lo que hace que su huella de RAM aumente, tomar un volcado de montón después de eso, y buscar lo que cuenta de objetos han aumentado. La documentación referenciada muestra cómo comparar los volcados de montón con MAT.

También cuando usted está mirando su montón de Java apenas como un análisis general (excepto cuando haciendo diffs), siempre esté seguro de seguir las instrucciones allí para desnudar la parte del zygote del montón. Como se menciona en la documentación, cada proceso tiene un gran número de asignaciones de zygote, pero éstas se comparten en todos los procesos, por lo que generalmente no son relevantes para el análisis de heap. A menudo veo a la gente preocupada porque ven muchos mapas de bits muy grandes en su aplicación que el sistema parece haber asignado a ellos, y piensan que es lo más importante que usa la RAM en su aplicación, cuando no lo es, es sólo el Asignaciones compartidas de zygote.

  • Cómo mencionar el camino de las bibliotecas en el archivo Android.mk o el archivo Application.mk?
  • TensorFlow reentrenado en el modelo v3 falla en Android
  • Cómo escribir una aplicación de Android para hacer sysfs leer / escribir.
  • UnsatisfiedLinkError en Samsung S6
  • Pasar el puntero de C a Java se convierte en NULL
  • Uso de libxml para Android
  • Sustituyendo glReadPixels por EGL_KHR_image_base para una copia de píxeles más rápida
  • ¿Cómo ver las opciones reales de gcc al construir Android desde el origen?
  • Obtener el nombre del paquete y las firmas de uid / pid de la aplicación en el cliente nativo
  • Portar un juego iPhone a Android - Texturas y búferes
  • ¿Cómo obtener la frecuencia de muestreo y la frecuencia del archivo de música (MP3) en android?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.