Asignación de memoria en Java – Android

Si tengo:

Bitmap bitmap = Bitmap.create(..); // instance a bitmap = Bitmap.create(...); // instance b bitmap = null; bitmap = Bitmap.create(...); // instance c bitmap.recycle(); bitmap = Bitmap.create(...); // instance d bitmap.recycle(); bitmap = null;

Una vez que se ejecuta este código, ¿cuáles de las 4 instancias están todavía en la memoria? Sé .recycle () instruye el código nativo para desasignar todos los recursos a ese objeto, pero no hay garantía de cuando eso sucede.

La razón por la que estoy preguntando, es echemos un vistazo al siguiente bucle:

 Bitmap bitmap = null; while (true) { bitmap = Bitmap.create(...); }

Esto supongo que eventualmente se bloqueará la aplicación (fuera de la memoria)? Si es así, ¿cómo se debe reescribir este bucle? (Si estoy usando mapa de bits para animar y mostrar el estado cambiado).

Java (y por extensión Android) utilizan la recolección asíncrona de basura para limpiar la memoria asignada. El colector funciona en el fondo que libera qué memoria puede. Lo que esto significa es que en ningún momento en el tiempo puede garantizar * cuántos objetos inalcanzables se han limpiado frente a los que todavía están pendientes.

Inmediatamente después de que su primer bloque de código haya terminado de ejecutarse, es posible que los cuatro objetos Bitmap todavía existan en el montón, pero en algún momento el recolector de basura se ejecutará, determinará que ya no son accesibles y liberará su memoria asociada.

Lo mismo ocurre en su segundo bloque de código; Algunos números arbitrarios de objetos seguirán existiendo en el montón, aunque ya no son accesibles, sin embargo el GC hará todo lo posible para limpiarlos como esto sucede. En la práctica, el GC es muy bueno en la limpieza de estos objetos de corta duración, por lo que incluso puede ser capaz de mantener el ritmo de su bucle (pero eso no es una garantía).

La JVM / ART hará todo lo posible para evitar una situación OutOfMemory , incluyendo una agresiva recolección de basura de último paso para intentar recuperar cualquier memoria posible para mantener la aplicación en ejecución. Por lo tanto, es improbable que su segundo bucle cause algún problema, pero sería bastante fácil para que lo pruebes.

Esperemos que no esté literalmente creando e inmediatamente descartando miles de objetos Bitmap ; Presumiblemente están siendo utilizados durante al menos algún período de tiempo durante el cual no sólo están creando más Bitmap que literalmente no se usan (si es así, ese es su problema).

_{* Hay trucos, como el uso de PhantomReference , que le permiten supervisar el estado de la recolección de basura, sin embargo esto pondrá más carga en el GC y por lo tanto no son una buena idea – o necesaria – en general.}

Android utiliza DalvikVM que funciona casi como Java. No recuerda a menos que se requiera.

MAT es una excelente herramienta para analizar los vertederos de memeory usando hprof para android.

Puedes encontrar respuesta usando MAT