Android NDK: Dalvik Heap y Native Heap – Cómo separar entre los dos
Sé que hay montón de Dalvik (JVM) y montón nativo en una plataforma androide. Y el GC Dalvik no tiene trabajo en el montón nativo. Pero no estoy seguro de cómo este trabajo, me refiero a cómo el sistema operativo Android separarlos?
posible situación 1: compuesto por hardware de memoria independiente (no creo mucho)
- FragmentStatePagerAdapter fuga de memoria (fragmentos anidados con viewpager)
- Uso de la memoria V8
- Agregar una ScrollView simple a la Galería provoca una pérdida de memoria
- Encontrar el mecanismo de caché de memoria "asesino" para Android
- LeakCanary informa actividad filtrada Instancia por implementación anónima de localización
posible situación 2: Android OS tiene cantidad FIJA de memoria para ambos montón
posible situación 3: Android OS tiene que asignar parte del montón de memoria Dalvik para convertirse en montón nativo cuando sea necesario, y por lo que el tamaño de montón nativo y montón Dalvik es flexible.
¿Cuál es la verdad, o posibilidad que no mencioné?
- ¿Por qué EditText conserva el contexto de su actividad en Ice Cream Sandwich
- Fuera de los errores de memoria se producen con un tamaño de montón alto pero tamaño asignado bajo. ¿Por qué?
- Android: cómo manejar el almacenamiento de archivos en la memoria baja del dispositivo (memoria interna / externa)
- Android - recuperarse de una condición de memoria baja
- Fuga de memoria de Android con final estático
- Tabla de referencia local de JNI de Android Expand
- Excepción de objetos muertos de Android
- ¿Qué significa si totalMemory es pequeño, pero totalPss es muy grande?
El montón nativo es administrado por dlmalloc()
, que utiliza una combinación de mmap()
y llamadas estándar como sbrk()
para asignar memoria. El montón administrado ("Dalvik") es (en su mayoría) un fragmento grande asignado con mmap()
. Todo se ejecuta en la parte superior del núcleo de Linux, por lo que si usted entiende la gestión de la memoria de Linux, ya sabes cómo funcionan las partes de bajo nivel.
Puede leer más acerca de cómo Dalvik devuelve páginas vacías de la pila administrada al sistema operativo en esta publicación .
Editar: la publicación canónica para obtener información sobre la gestión de la memoria de Android es ésta . No creo que responda directamente a su pregunta, pero tiene un montón de buena información y enlaces a sitios informativos.
Dado que Android es de código abierto, puede comprobar el código fuente usted mismo . Parece que llama create_mspace_with_base()
. No estoy exactamente seguro de lo que hace, pero de acuerdo con este post , se asigna la memoria de /dev/zero
.
Así que realmente está utilizando un montón "separado". Asigna directamente sus propias páginas de memoria y las gestiona por sí mismo.
Es casi su segundo caso
Hay dos heaps
separados, uno para el runtime
Art
(previamente DalvikVM
) y uno para los programas native
.
Usted puede ver fácilmente estas dos áreas diferentes mediante la realización de un cat
en el pseudo-archivo de maps
del sistema de archivos proc
.
Considere la siguiente salida:
2a028000-2a029000 rw-p 00000000 00:00 0 [heap] b6400000-b6c00000 rw-p 00000000 00:00 0 [anon:libc_malloc]
En el ejemplo anterior, la primera área, que sólo tiene una página, es administrada por el ART Runtime
. Ambos dlmalloc
y rosalloc
son compatibles, pero ART
utiliza rosalloc
ya que es más rápido. Esta área, en contraste con lo que dijo @fadden (al menos para Lollipop), es gestionado por sbrk
. Crece upwards
.
La segunda área, que es 2048
páginas de largo, es el native heap
. Es utilizado por la biblioteca bionic
, que es una implementación de libc
para Android. Ambos dlmalloc
y jemalloc
son compatibles, y el que se está utilizando depende del dispositivo. No he encontrado una llamada que extiende este montón, pero supongo que mmap
sería suficiente. Crece downwards
, hacia el montón de runtime
.