[Optimización del rendimiento de Android] ¿Cómo monitorear los problemas de ANR?

Prefacio

ANR significa Solicitud sin respuesta y el programa no responde. El sistema Android está diseñado con un mecanismo ANR, cuyo propósito es monitorear el tiempo de espera de los componentes con los que interactúa (Actividad, etc.) y la interacción del usuario (InputEvent). Esto puede determinar si el proceso de solicitud (hilo principal) está bloqueado o responde demasiado lento.

En comparación con Crash, los problemas de ANR tienen causas complejas y son difíciles de localizar. Este artículo incluye principalmente los siguientes contenidos

1. Flujo de trabajo ANR
2. ¿Cómo monitorear ANR?
3. ¿Cómo localizar la causa de la ANR?

Flujo de trabajo ANR

Hay muchas ocasiones en las que se puede activar ANR, que generalmente se pueden dividir en los siguientes aspectos:

El principio básico es en realidad la idea de WatchDog: si el evento enviado no se consume dentro de un cierto período de tiempo, se activará ANR.

Hablemos del proceso general aquí, como se muestra en la siguiente figura:

1. Después de que ocurre un ANR, el sistema recopilará una gran cantidad de datos de proceso y realizará volcados de pila para generar un archivo de seguimiento ANR. Entre ellos, el primer proceso a recopilar debe ser el proceso donde ocurre ANR.
2. El sistema enviará la señal SIGQUIT a estos procesos de aplicación, y estos procesos de aplicación comenzarán a realizar volcados de pila después de recibir la señal.
3. Una vez que el proceso de solicitud Dump stack es exitoso, se comunica con el proceso del sistema a través de Socket y escribe el archivo de seguimiento.
4. Después de escribir el archivo de seguimiento, si el proceso donde ocurrió el ANR es el proceso en primer plano, aparecerá el cuadro de diálogo; de lo contrario, el proceso se cerrará directamente.

¿Cómo monitorear ANR?

Después de comprender el flujo de trabajo de ANR, ¿cómo podemos monitorear la aparición de ANR?

Ideas de detección de ANR WatchDog

Dado que la causa del ANR es que la entrada no responde dentro de un cierto período de tiempo, naturalmente pensamos en enviar una tarea al hilo principal, si no se ejecuta dentro de un período de tiempo, se considera que ha ocurrido un ANR. .

Esta idea tiene principalmente los siguientes problemas:

1. Las condiciones de tiempo de espera inexactas no necesariamente causan ANR; por ejemplo, un tiempo de espera de 5 segundos es solo una de las condiciones para que ocurra un ANR cuando el TouchEvent no se consume, y las otras condiciones no son necesariamente 5 segundos.
2. Detección faltante: si el tiempo de espera se establece en 5 segundos, existe una cierta probabilidad de que falte detección (el ciclo no está sincronizado) al detectar el ANR de TouchEvent.

Ideas de monitoreo de señales ANR

Al presentar el proceso general de ANR anteriormente, notamos que la señal SIGQUIT se enviará cuando ocurra una ANR. Entonces, ¿no podemos implementar el monitoreo de ANR escuchando esta señal? De hecho, tanto XCrash como Matrix implementan el monitoreo ANR de esta manera.

Cabe señalar aquí que, de forma predeterminada, el proceso realiza volcados de pila y genera archivos de seguimiento ANR SignalCatcherescuchando señales. SIGQUITPor lo tanto, después de monitorear SIGQUITla señal, debemos SignalCatcherenviarla nuevamente.SIGQUIT

Si no hay ningún paso para reenviar la señal SIGQUIT al SignalCatcher, el Servicio de administración del sistema Android (AMS) esperará a que el proceso ANR escriba la información de la pila. Hasta que se exceda el período de tiempo de espera de 20 segundos, AMS se verá obligado a interrumpir y continuar el proceso posterior. Esto hará que la ventana emergente ANR se muestre muy lentamente (porque el tiempo de espera es de 20 segundos) y el archivo de seguimiento ANR completo no se puede generar en el directorio /data/anr.

Manejo de falsos positivos

Cuando se monitorea la señal SIGQUIT, ANR no necesariamente ocurre.

La documentación de Matrix menciona dos casos de falsos positivos:

1. Por ejemplo, puede ser que otro proceso tenga un ANR y el proceso donde ocurrió el ANR no sea el único proceso que necesite un volcado de pila. El sistema recopila volcados de pila de muchos otros procesos y los utiliza para generar archivos ANR Trace.
2. La señal la envía el propio fabricante o desarrollador SIGQUIT. Enviar la señal SIGQUIT es realmente muy fácil.

Por lo tanto, debemos realizar otra verificación al escuchar la señal: antes de la ventana emergente ANR, el proceso donde ocurrió el ANR se marcará con un indicador NOT_RESPONDING, y podemos obtener este indicador a través de ActivityManager.

private static boolean checkErrorState() {
   
    
    
    try {
   
    
    
        Application application = sApplication == null ? Matrix.with().getApplication() : sApplication;
        ActivityManager am = (ActivityManager) application.getSystemService(Context.ACTIVITY_SERVICE);