android - mucha - ¿Dalvik VM procesa la memoria RAM del sistema de liberación?
como liberar memoria ram pc (1)
La documentación del desarrollador de Android, como parte de Project Svelte (lema: "¿Alguna vez trataste de instalar Bugdroid en skinny jeans?!?"), Tiene una página en Managing Your App''s Memory . Contiene:
Cuando el usuario navega hacia una aplicación diferente y su UI ya no está visible, debe liberar los recursos que solo utiliza su interfaz de usuario. La liberación de los recursos de la interfaz de usuario en este momento puede aumentar significativamente la capacidad del sistema para los procesos en caché, lo que tiene un impacto directo en la calidad de la experiencia del usuario.
y:
TRIM_MEMORY_RUNNING_LOW: su aplicación se está ejecutando y no se considera imposible, pero el dispositivo tiene una memoria mucho menor, por lo que debe liberar los recursos no utilizados para mejorar el rendimiento del sistema (lo que afecta directamente el rendimiento de su aplicación).
y similares.
Sin embargo, esto solo tendría sentido si "liberar recursos" realmente afectara la RAM del sistema de alguna manera.
Tenía la impresión de que la máquina virtual Dalvik se comportaba como la máquina virtual Java (o quizás "lo hizo") si la cambiaban cuando yo no estaba buscando). AFAIK, Java VM asigna RAM del sistema para aumentar el tamaño del almacenamiento dinámico pero nunca lo libera; una vez asignado, permanece como parte del espacio de almacenamiento dinámico mientras se ejecuta el proceso.
Si la máquina virtual de Dalvik se comporta de la misma manera, no veo cómo aumentar la cantidad de espacio de almacenamiento no asignado en nuestro proceso tendría un impacto en el rendimiento general del sistema. Ahora, liberar espacio en el montón para nuestro proceso es algo bueno, y quizás hacerlo disminuiría la probabilidad de que necesitemos más RAM del sistema en el futuro ... pero eso no es lo que la documentación implica. La documentación indica que "Liberar recursos de IU en este momento puede aumentar significativamente la capacidad del sistema para procesos en caché"; no dice "Liberar recursos de IU en este momento no tiene un impacto inmediato pero ayudará a reducir la huella de RAM del sistema de tu aplicación en el futuro".
Ahora, si las instrucciones nos hubieran dicho que liberamos la memoria asignada a través del NDK, eso tendría sentido, ya que eso ocurre fuera del montón de Dalvik y afectaría la memoria RAM del sistema. Pero la documentación no dibuja esa distinción.
¿De verdad la VM Dalvik libera la RAM asignada de vuelta al sistema, a menos que finalice el proceso? ¿Si es así cuando? Y, en menor medida, ¿cómo se hace eso, teniendo en cuenta que el recolector de basura no es compactante y no copia?
¡Gracias!
Sí. La idea básica es que, si hay una página de 4K sin nada, la página se devolverá al sistema.
La función que hace esto en la VM se llama trimHeaps() , en dalvik/vm/alloc/HeapSource.cpp . Puede verlo usando mspace_trim() , que usa llamadas del sistema operativo para desasignar trozos que ya no son necesarios (vea los comentarios de malloc_trim () alrededor de la línea 1203 en dalvik/vm/alloc/HeapSource.cpp ). Luego recorre el montón con mspace_inspect_all() , que llama a releasePagesInRange() para cada región. La devolución de llamada prueba para ver si se pasó una región sin asignaciones, y si es así, trunca los límites a la alineación de 4 K. Si el resultado no está vacío, sabemos que la región abarca una o más páginas físicas de 4K, que pueden devolverse al sistema con madvise(MADV_DONTNEED) .
trimHeaps() se llama desde algunos lugares, especialmente gcDaemonThread() , que iniciará el recorte cinco segundos después de un GC concurrente. El temporizador se restablece si la GC concurrente ocurre antes de que transcurran cinco segundos, con la idea de que si estamos haciendo GC, la VM está ocupada asignando y este tipo de recorte en tiempo de inactividad será contraproducente.
Debido a que el Dalvik GC no hace compactación, esto no es tan efectivo como podría ser. La fragmentación tiende a acumularse con el tiempo, por lo que la situación puede empeorar mientras más viva el proceso. El marco de aplicación puede "reciclar" servicios de larga duración para aliviar esto.