Autor: Diario de codificación de Xiaohai
A diferencia de LeakCanary, en Matrix, las pérdidas de memoria se monitorean principalmente a través de Resource Canary, y el objeto de fuga monitoreado solo admite Actividad. La descripción oficial es la siguiente:
Combinado con la experiencia de analizar LeakCanary, podemos ver que para implementar el monitoreo de pérdida de memoria de actividad, en general se deben implementar dos funciones:
- Monitoreo del ciclo de vida de la actividad.
- Encuentre objetos filtrados y obtenga GC Root Path
Monitoreo del ciclo de vida de la actividad.
Se Activity生命周期监控实现方案puede ver que podemos implementar el monitoreo del ciclo de vida de la actividad a través de Application.registerActivityLifecycleCallbacks, entonces, ¿cómo se implementa en Matrix?
La clase de implementación de Resource Canary en Matrix es ResourcePlugin. Matrix carga todos los objetos de complemento y los inicia llamando a startAllPlugins. startAllPlugins finalmente llama al método de inicio de cada complemento. La implementación es la siguiente:
En ResourcePlugin, la implementación principal está alojada en la clase ActivityRefWatcher, por lo que debe contener la lógica principal de monitoreo de fugas de actividad en esta clase. El método de inicio de esta clase es el siguiente:
A través del código, se puede ver claramente que el monitoreo del ciclo de vida de la actividad se implementa a través de Application.registerActivityLifecycleCallbacks. Cuando el ciclo de vida de la actividad cambia, se volverá a llamar al objeto mRemovedActivityMonitor. Echemos un vistazo a la implementación del objeto mRemovedActivityMonitor:
Se puede ver que en onActivityDestroyed se hacen principalmente dos cosas. La información de la actividad destruida se almacena en mDestroyedActivityInfos y el GC se activa después de un retraso de dos segundos. A diferencia de LeakCanary, no hay una cola de referencia para verificar si hay fugas de objetos de actividad. ¿Ves cómo busca fugas?
Identificar objetos con fugas
Volviendo al método ActivityRefWatcher.start, puede ver que además de registrar el monitor del ciclo de vida de la actividad, también se ejecuta el método ScheduleDetectProcedure ¿Para qué se utiliza este método?
private void scheduleDetectProcedure() {
mDetectExecutor.executeInBackground(mScanDestroyedActivitiesTask);
}
Combinado con los comentarios, podemos ver que el bloqueo de subprocesos se implementa a través del objeto mDestroyedActivityInfos. Cuando la cola no está vacía, active la tarea para la detección de fugas de objetos (al juzgar si el objeto de referencia débil está vacío para determinar el estado de reciclaje, el El objeto de referencia débil está vacío (significa que se ha reciclado y no hay fugas). Puede ver que la GC se realiza externamente y cada vez que los datos de la lista se leen en un bucle para garantizar que el objeto se recicle por completo y evitar falsos positivos. Cuando se descubre que mMaxRedetectTimes (parámetro configurable, después del valor predeterminado es 10), si el objeto Actividad aún no se recicla, se activará el mecanismo de manejo de fugas.
Los manejadores de fugas proporcionados en Matrix se muestran en la siguiente figura:
Los métodos de procesamiento de cada procesador son los siguientes:
- AutoDumpProcessor: la capa de Java genera automáticamente hprof y luego recorta y vuelve a llamar para informar el problema
- ForkAnalyseProcessr: después del proceso de bifurcación de la capa nativa, el gancho genera un archivo hprof y lo analiza
- ForkDumpProcessor: el proceso de bifurcación es suficiente en la capa nativa, el enlace genera el archivo hprof y vuelve a llamar para informar el problema
- LazyForkAnalyseProcessor: analiza hprof cuando la aplicación está en segundo plano, otras son consistentes con ForkAnalyseProcessr
- ManualDumpProcessor: genera y analiza archivos hprof en la capa nativa
- NativeForkAnalyzeProcessor: la implementación es básicamente la misma que ManualDumpProcessor
- NoDumpProcessor: informar problema sin ningún procesamiento
- SilenceAnalyseProcessor: la operación de la capa Java genera un archivo hprof, análisis de la capa nativa
Principio de implementación del monitoreo de fugas de memoria canaria de recursos
Combinando el contenido anterior, no es difícil ver que la pérdida de memoria en Resource Canary en Matrix se logra principalmente mediante la cooperación del hilo principal y el subproceso: el hilo principal recopila información del objeto y el subproceso El subproceso realiza una búsqueda de fugas por turnos para objetos, como se muestra en la siguiente figura:
Para ayudar a todos a comprender mejor la optimización del rendimiento de manera integral y clara, hemos preparado notas centrales relevantes (volviendo a la lógica subyacente):https://qr18.cn/FVlo89
Notas fundamentales de optimización del rendimiento:https://qr18.cn/FVlo89
Optimización de inicio
Optimización de memoria Optimización
de UI
Optimización de red
Optimización de mapas de bits y optimización de compresión de imágenes : optimización de concurrencia multiproceso y optimización de la eficiencia de transmisión de datos Optimización de paquetes de volumenhttps://qr18.cn/FVlo89
"Marco de monitoreo del rendimiento de Android":https://qr18.cn/FVlo89
"Manual de estudio del marco de Android":https://qr18.cn/AQpN4J
- Proceso de inicio de arranque
- Inicie el proceso Zygote en el arranque
- Inicie el proceso SystemServer al arrancar
- conductor de carpeta
- Proceso de inicio de AMS
- El proceso de inicio del PMS
- Proceso de inicio del lanzador
- Los cuatro componentes principales de Android
- Servicio del sistema Android: proceso de distribución del evento de entrada
- Análisis del código fuente del mecanismo de actualización de la pantalla de renderizado subyacente de Android
- Análisis del código fuente de Android en la práctica
