android - studio - Localización y reparación de la causa del tamaño grande de almacenamiento dinámico

memory leaks android studio

Question

Estoy tratando de averiguar por qué mi aplicación usa tanta memoria. A menudo lo veo usando entre 15 y 18 MB, que es sustancialmente más alto de lo que esperaba. Eché un vistazo al tamaño del montón a través de DDMS y vi esto:

Eso parecía un poco sospechoso porque mi aplicación no se ocupa de imágenes grandes en absoluto. De hecho, la suma total de los elementos extraíbles en mi aplicación es de aproximadamente 250 KB. Así que creé un volcado de pila y utilicé MAT para localizar dónde iba todo este recuerdo. las matrices byte [] eran, con mucho, el mayor consumidor, así que profundicé y noté lo siguiente:

No tengo ni idea de por qué sPreloadedDrawables es responsable de un tamaño de almacenamiento tan alto. Tampoco tengo idea de cómo identificar la causa raíz, o cómo "arreglarla".

¿A dónde debería ir desde aquí? Mi aplicación funciona principalmente en segundo plano a través de servicios que no se ocupan en absoluto de los datos de imagen. Tengo Actividades que el usuario puede elegir usar, pero una vez más, usan pequeñas herramientas que no explican un tamaño de montón tan grande. También verifiqué si había alguna desagradable ocurrencia de fugas de actividad, etc., pero no encontré ninguna.

EDITAR: Me di cuenta de que el tamaño del montón es sustancialmente menor cuando se ejecuta en el emulador. Esto es bastante confuso : /

Answer 1

El sistema precargará los recursos predeterminados del sistema, esto es independiente de los recursos de su aplicación, cosas como los Drawwables estándar para casillas de verificación y botones de opción. 10.5MB parece grande pero hay muchos recursos predeterminados del sistema y las imágenes son más grandes una vez almacenadas en la memoria. La precarga no es nueva, pero el tamaño de la precarga podría ser mayor en ICS. La densidad de visualización probablemente tenga un papel en esto, junto con la simple adición de más sistemas Drawables precargados en ICS.

Actualmente no hay forma de reducir la memoria almacenada en sPreloadedDrawables

Es lamentable que no haya una manera de aclarar esto después de que el proceso de la aplicación se genera para las aplicaciones (especialmente los juegos) que no utilizan la mayoría de los Drawables del sistema. En este caso, aunque el gran tamaño de los recursos de precarga parece haber sido un error con un lanzamiento específico (o puerto de dispositivo) de ICS. De lo contrario, normalmente es una pequeña cantidad de memoria, por lo que dudo que alguna vez sea necesario tener un mecanismo para reducir el uso de la memoria de precarga.

Si se está quedando sin memoria como resultado de este caché, entonces probablemente presentaría un informe de error a Google.

Puede rastrear a través del proceso de precarga de recursos aquí si está interesado en más detalles internos. ZygoteInit.preloadResources