como saber si una memoria esta goteada
Durante el desarrollo de una aplicación, me di cuenta de que finalmente se estrelló porque la JVM no podía asignar más memoria. Utilizando el comando dumpsys meminfo de adb shell, pude ver que el montón asignado nativo creció mientras cambiaba las actividades hasta que se acercaba a 16M, cuando se estrelló. Creo que ahora he corregido el código para impedir que esto suceda, pero me doy cuenta de que las cifras devueltas por ..meminfo varían un poco y en general parecen aumentar ligeramente ahora.
Básicamente, no estoy seguro de si deben volver a los mismos valores cuando inicio y detener una aplicación. Tengo estas cifras y no estoy seguro de si significan que tengo una fuga de memoria o no:
En pantalla de inicio, aplicación en memoria (PID visto en DDMS), pero no en ejecución
Adb shell dumpsys meminfo (PID relevante) da:
native dalvik other total size: 5248 4039 N/A 9287 allocated: 5227 3297 N/A 8524 free: 12 742 N/A 754 (Pss): 2183 3534 1726 7443 (shared dirty): 1976 4640 876 7492 (priv dirty): 2040 1664 940 4644
La aplicación se inició desde la pantalla de inicio, las actividades iniciadas fueron:
Pantalla de bienvenida -> modo de selección -> Actividad 1, luego todos los respaldados con el botón Atrás, hasta volver a la pantalla de inicio
Meminfo ahora: native dalvik other total size: 5572 4231 N/A 9803 allocated: 5497 3153 N/A 8650 free: 74 1078 N/A 1152 (Pss): 2479 3614 1742 7835 (shared dirty): 1976 4632 876 7484 (priv dirty): 2336 1740 956 5032
Proceso repetido: native dalvik other total size: 5696 4231 N/A 9927 allocated: 5211 2949 N/A 8160 free: 392 1282 N/A 1674 (Pss): 2515 3713 1742 7970 (shared dirty): 1976 4632 876 7484 (priv dirty): 2372 1840 956 5168
Eclipse Memory Analyzer Tool (que no encuentro todo lo informativo) informa sobre los siguientes 'sospechosos de fugas': 3,143 instances of "java.lang.Class", loaded by "<system class loader>" occupy 736,760 (35.69%) bytes. Biggest instances: class com.ibm.icu4jni.util.Resources$DefaultTimeZones @ 0x40158fe0 - 165,488 (8.02%) bytes. class android.text.Html$HtmlParser @ 0x400eebd8 - 126,592 (6.13%) bytes. class com.google.googlenav.proto.GmmMessageTypes @ 0x43d183d8 - 56,944 (2.76%) bytes. class org.apache.harmony.security.fortress.Services @ 0x40071430 - 51,456 (2.49%) bytes. class android.content.res.Resources @ 0x4004df38 - 33,584 (1.63%) bytes. class android.text.AutoText @ 0x400f23c8 - 31,344 (1.52%) bytes. Keywords java.lang.Class Details » Problem Suspect 2 8,067 instances of "java.lang.String", loaded by "<system class loader>" occupy 497,304 (24.09%) bytes. Keywords java.lang.String Details » Problem Suspect 3 54 instances of "org.bouncycastle.jce.provider.X509CertificateObject", loaded by "<system class loader>" occupy 256,024 (12.40%) bytes. These instances are referenced from one instance of "java.util.HashMap$HashMapEntry[]", loaded by "<system class loader>" Keywords org.bouncycastle.jce.provider.X509CertificateObject java.util.HashMap$HashMapEntry[]
Todos los comentarios serán agradecidos
5 Solutions collect form web for “¿Cómo saber si una aplicación de Android está realmente goteando memoria?”
En MAT, casi nunca he encontrado un "Leak Suspect" que en realidad era una fuga. Lo que realmente buscas son objetos que están siendo retenidos después de un barrido de GC que no debería ser.
Por ejemplo, supongamos que tengo una actividad de cuadro de mandos que puede iniciar las actividades A y B. Inicie el panel de control, luego iniciar la actividad A, presionar el botón Atrás, iniciar la actividad B y presionar el botón Atrás.
Mediante la vista Depurar de Eclipse, puede forzar un evento de recopilación de GC mediante el botón "Causa GC". Ahora, haga clic en el botón "Descargar archivo HPROF" y ejecute MAT. Haga clic en el enlace "Dominator Tree".
En este punto, esperaría que cualquier memoria asociada con las actividades A y B se hayan recogido como basura a menos que haya un error en el código. Normalmente, esto es lo que calificaría como una "pérdida de memoria" en la aplicación.
Esto ocurre más a menudo debido a contextos retenidos, que pueden comer mucha memoria ya que los contextos a menudo representan grandes componentes (actividades, servicios, etc.).
Cualquier cosa que parezca sospechosa en el Dominator Tree se puede investigar más fácilmente a través de la opción "Path to GC Roots" -> "excluir referencias débiles" (disponible mediante menú contextual). La vista raíz de path2gc es probablemente la manera más fácil de encontrar qué objetos contienen referencias a objetos de tal manera que no se pueden liberar.
Una vez que encuentre las referencias inesperadas que se conservan puede tomar más cavar a través del código para entender por qué. Si tiene que ver con un componente del sistema / OS, grepcode es tu amigo 🙂
El registro y el no registro del receptor dará lugar a fugas de memoria
Como por ejemplo si usted ha registrado el receptor con registerReceiver () y en la aplicación que usted mismo intenta registrarlo agin sin hacer unregistering entonces le llevará demasiado problema de fuga de memoria.
Llegó a saber esto de la depuración y la fijación de errores cosas.
Basado en mi experiencia con la creación de aplicaciones de Android, el sistema operativo parece dejar una gran cantidad de basura en la memoria. Sin embargo, cuando el dispositivo lo necesita para algo importante, tomará (casi indiscriminadamente) lo que necesite. Incluso si sobrescribe un dato en otra aplicación actualmente abierta.
Aparte de eso, es probable que varias otras cosas sucedan en el fondo que afectan a sus números, así que no creo que podamos extraer ninguna información concluyente de ellos. Si una aplicación que ha creado se está filtrando, entonces es más probable que algo que está haciendo que causaría una pérdida de memoria en cualquier otro entorno basado en Java también. Un artículo como: http://www.ibm.com/developerworks/library/j-leaks/ debe ayudar con la fijación de la mayoría de los problemas de fugas.
Si estoy experimentando problemas de memoria con mi aplicación, estoy utilizando la versión standal de la herramienta ddbms incluida en las herramientas de desarrollo de android.
Echa un vistazo a este enlace: http://android-developers.blogspot.com/2009/02/track-memory-allocations.html
Con esta herramienta puedes echar un vistazo al consumo de memoria desde "el punto de vista java" para que puedas ver qué objetos están bloqueando la mayor parte de tu memoria. Esto le dará la posibilidad de localizar con precisión la pérdida de memoria que está experimentando y de optimizar su código.
La salida que ha dado da sólo una visión general de toda la memoria utilizada en su aplicación, pero no cómo se utiliza.
Mientras comprueba el resultado de la herramienta Analizador de memoria, la herramienta Mat no promete encontrar una memory leak pero muestra un problem o suspect función de su secuencia de comandos
La herramienta MAT hace que PIE Chart, Dominator Tree, Path 2 GC vista basada en el análisis de heap de aplicaciones en ejecución
El desarrollador puede analizar el uso de memoria basado en el resultado anterior y mejorar su programación de aplicaciones
Muy buen enlace para saber más sobre cómo eliminar la pérdida de memoria es: aquí
No hay comentarios:
Publicar un comentario