Cómo solucionar estas pérdidas de memoria
Repita la ruta clave sospechosa varias veces y observe la curva de memoria de la herramienta de monitoreo de memoria para ver si hay una tendencia ascendente y no retrocederá significativamente cuando el programa regrese.
Este método puede identificar las pérdidas de memoria más básicas y obvias, es más valioso para los usuarios, es menos difícil de implementar y es extremadamente rentable.
Herramienta de análisis de memoria MAT
2.1 MAT analiza el uso total de memoria del montón e inicialmente determina si hay fugas
En Dispositivos, haga clic en el programa que desee para monitorear.
En la vista Dispositivos, haga clic en "Actualizar montón" en la fila superior de iconos.
Haga clic en la vista de montón
Haga clic en "Causa GC" (Causa GC)
En este punto se puede monitorizar el proceso a detectar. En el medio de la vista del montón, hay un tipo llamado objeto de datos, que es un objeto de tipo clase que existe mucho en nuestro programa. Hay una columna en la fila del objeto de datos llamada "Tamaño total". Su valor es la memoria total de todos los objetos de datos Java en el proceso actual. En términos generales, el tamaño de este valor determina si se producirá una pérdida de memoria.
Ingrese a una aplicación y opere continuamente, mientras observa el valor de Tamaño total del objeto de datos. En circunstancias normales, el valor de Tamaño total se estabilizará dentro de un rango limitado, es decir, porque el código del programa es bueno. , No hará que el objeto no sea recolectado como basura.
Por lo tanto, aunque nuestras operaciones continuas continuarán generando una gran cantidad de objetos, durante el proceso GC continuo de la máquina virtual, estos objetos se reciclarán y el uso de memoria caerá a un nivel estable; por el contrario, si el código no publica ninguna referencia de objeto, el valor de tamaño total del objeto de datos no disminuirá significativamente después de cada GC. A medida que aumenta el número de operaciones, el valor del tamaño total será cada vez mayor hasta alcanzar el límite superior y provocar la finalización del proceso.
2.2 MAT analiza hprof para encontrar la causa de las pérdidas de memoria.
Esta es una forma eficaz de utilizar MAT para localizar el problema después de una pérdida de memoria.
A) Exporte la imagen de memoria hprof cuando se produzca la pérdida de memoria y analice la clase de fuga sospechosa:
B) Analice los objetos externos que contienen referencias a dichos objetos
C) Analizar la ruta del GC de estos objetos que contienen referencias
D) Analizar la ruta del GC de cada objeto uno por uno para ver si es normal
Se puede ver del camino, que es un objeto antiRadiant. Desde esta ruta, podemos ver que un objeto de la clase de utilidad antiRadiationUtil contiene una referencia a MainActivity, lo que impide que MainActivity se libere. En este punto, debemos ingresar el código para analizar si la referencia de antiRadiationUtil es razonable (si antiRadiationUtil mantiene el contexto de MainActivity y hace que el programa no se destruya después de salir de MainActivity, generalmente es una pérdida de memoria).
2.3 MAT compara hprof antes y después de la operación para encontrar la causa raíz de la pérdida de memoria.
Para encontrar pérdidas de memoria, normalmente es necesario comparar los resultados de dos volcados, abrir el panel Historial de Navigator y agregar los resultados del histograma de las dos tablas a la cesta de comparación.
A ) primer archivo HPROF (usando File gt; Open Heap Dump).
B) Abre la vista de histograma.
) En la vista Historial de navegación (si no está visible en Windows gt;show viewgt;MAT- Historial de navegación), haga clic derecho en el histograma y seleccione Agregar a la cesta de comparación.
D) Abra el segundo archivo HPROF y rehaga los pasos 2 y 3.
E) Cambie a la vista de cesta de comparación y haga clic en el resultado de la comparación (icono "!" rojo).
F) Analizar los resultados de la comparación
Puedes ver los resultados de la comparación de dos objetos de datos hprof.
De esta manera, puede localizar rápidamente el incremento de los objetos retenidos antes y después de la operación, localizando así qué objetos de datos se están perdiendo debido a la operación actual que causa la pérdida de memoria.
Nota:
Si utiliza el complemento MAT Eclipse para obtener el archivo de volcado, puede abrirlo en MAT sin conversión, Adt lo convertirá automáticamente.
Los archivos del SDk Dump móvil deben convertirse antes de que MAT pueda reconocerlos. El SDK de Android proporciona la herramienta hprof-conv (ubicada en sdk/tools)
Primero. , debes pasar Ingresa al directorio de herramientas SDK de tu Android en la consola y ejecuta los siguientes comandos:
./hprof-conv xxx-a.hprof xxx-b.hprof
Por ejemplo , hprof-conv input. hprof out.hprof
Solo entonces puedes colocar out.hprof en MAT en eclipse y abrirlo.
Monitor diario de pérdida de memoria
Actualmente, el Monitor diario de pérdida de memoria de Mobile Manager se ejecuta automáticamente independientemente del tamaño del objeto filtrado y genera un informe por correo electrónico basado en la presencia de una fuga sospechada. . Las tecnologías centrales involucradas incluyen AspectJ, las herramientas propias de MLD (el principio son las referencias virtuales) y UIAutomator.
3.1 Código de monitoreo de seguimiento de AspectJ
Mobile Manager actualmente utiliza scripts ant para agregar código de monitoreo MLD e implementar el seguimiento a través de la sintaxis de AspectJ.
La razón para usar AspectJ es que puede separar de manera flexible el código fuente del proyecto y el código de monitoreo, y empaquetar el paquete de prueba en código para diferentes propósitos a través de diferentes scripts de compilación: si el paquete de prueba se monitorea a través de Aspect y MLD Si el código está vinculado, después de la ejecución se generará un archivo de registro en el formato especificado, que servirá como base de datos para el análisis posterior.
3.2 MLD realiza la lógica central del monitoreo
Este es un proyecto de herramienta en el administrador de teléfonos móviles. El paquete oficial no se puede usar, pero se pueden usar paquetes de prueba de monitoreo diario como BVT. usado. Después de la entrada, puede agregar objetos que deben monitorearse y detectarse a través de interfaces como addObject (verifique si la herramienta está incluida y llame a la herramienta mediante reflexión), y la herramienta detectará automáticamente si el objeto tiene una fuga en un momento específico ( como salir del ama de llaves).
El principio básico de esta detección de pérdidas de memoria es:
Las referencias virtuales se utilizan principalmente para rastrear las actividades de los objetos reciclados por el recolector de basura. Las referencias virtuales deben usarse junto con una cola de referencia (que debe especificarse en asociación con la función de referencia virtual). Cuando el recolector de basura se prepara para recuperar un objeto, si encuentra una referencia virtual, agregará automáticamente la referencia virtual a su cola de referencia asociada antes de recuperar la memoria del objeto. El programa puede determinar si el objeto de referencia está a punto de ser recolectado como basura determinando si se ha agregado una referencia virtual a la cola de referencia.
De acuerdo con este principio, cuando la herramienta MLD llama a la interfaz addObject para agregar un tipo monitoreado, agregará una referencia virtual al objeto de ese tipo, teniendo en cuenta que la referencia virtual no afectará al objeto. Reciclaje normal. Por lo tanto, puede contar la cantidad de objetos monitoreados en la cola de referencia que no se reciclan y ver si superan un umbral específico.
Con PhantomReferences y ReferenceQueue, cuando se agrega un PhantomReferences al ReferenceQueue asociado, se considera que el objeto ha estado o está en la fase de reciclaje del recolector de basura.
El núcleo de los principios de monitoreo de MLD
Actualmente, Mobile Manager ha completado el monitoreo de pérdida de memoria para la mayoría de las clases, incluidas diversas actividades, servicios y páginas de visualización, con el fin de brindar técnicamente a los usuarios la experiencia de producto más fluida.
A continuación presentaremos brevemente el núcleo de la herramienta. Dependiendo del estado de la memoria monitoreado por las referencias virtuales, se necesitan varias estrategias para determinar si existe una pérdida de memoria.
(1) El método más simple es establecer directamente el número máximo de objetos de este tipo al agregar un monitor. Por ejemplo, en teoría cada objeto DAO solo puede existir como máximo uno, por lo que una vez aparecen dos. DAO suele ser una fuga;
(2) El segundo caso es una lista de objetos que no se pueden liberar después de recuperar gc cuando la página sale del programa. Estos tipos de objetos también serán sospechosos de pérdidas de memoria;
(3) El último caso es más complicado y su principio básico es determinar el crecimiento del número de objetos en función de operaciones históricas. Según el crecimiento del objeto, se utiliza el método de mínimos cuadrados para ajustar la tasa de crecimiento del tipo de objeto. Si la tasa de crecimiento excede el valor empírico, se incluye en la lista de objetos sospechosos de fuga.
3.3 UIAutomator completa la automatización de operaciones repetidas
El último paso es muy sencillo. Con tantas operaciones de interfaz de usuario repetitivas, sería un desperdicio ordenarlas manualmente. Usamos UIAutomator para pruebas de operación automatizadas.
En la actualidad, las pruebas automatizadas diarias del administrador móvil han cubierto las rutas principales de cada función e impulsan de manera flexible la adición, eliminación, modificación e inspección de casos de uso a través de archivos de configuración. máximo Esto mejora enormemente el valor de reutilización de los casos de uso.
¡Este es el final de la introducción al programa de prueba de pérdida de memoria de Mobile Butler! ¡Bienvenidos a todo tipo de personas talentosas para comunicarse y comunicarse sobre programas de caja de herramientas de pérdida de memoria cada vez más poderosos!
Introducción a Tencent Bugly
Bugly es una versión complementaria de la plataforma interna de monitoreo de calidad del producto de Tencent. Su función principal es monitorear e informar fallas, retrasos y otros fenómenos que ocurren en el sistema. el lado del usuario después del lanzamiento de la APLICACIÓN, para que los estudiantes de desarrollo puedan comprender la calidad de la APLICACIÓN por primera vez y luego realizar modificaciones oportunas en el modelo. Actualmente, todos los productos de Tencent lo utilizan para monitorear fallas de productos en línea.