Umeng + experto en desarrollo móvil Zhang Wen
"Crash" es lo mismo que "atascado", "salida anormal", etc., que son tres situaciones comunes que afectan la estabilidad de la aplicación. Los datos relevantes muestran que cuando la tasa de fallos de iOS supera el 0,8% y la tasa de fallos de Android supera el 0,4%, hay una disminución significativa en los usuarios activos. No solo causará una interrupción crítica del negocio, una disminución de la tasa de retención de usuarios, un deterioro de la reputación de la marca y otros impactos negativos, sino que también conducirá directamente a descargas y pérdidas. También trae una pérdida de capital para los desarrolladores que no puede subestimarse.
Entonces, ¿es alta la calidad de una aplicación con una tasa de fallas baja? ¿Se puede juzgar directamente la estabilidad de la aplicación por la tasa de fallas?
En primer lugar, al medir la calidad de una aplicación, necesitamos definir un calibre unificado, es decir, ¿qué indicadores se pueden utilizar como calibre de evaluación de estabilidad? Tome el concepto de tasa de estabilidad definido por U-APM de Umeng + como ejemplo, para evaluar la estabilidad y calidad de una App, generalmente considere los siguientes tres puntos:
Cuando ocurre un bloqueo, como un bloqueo de Java y un bloqueo nativo, la tasa de bloqueo se utiliza para evaluar el cálculo;
Cuando se produce ANR, utilice la tasa de ANR del indicador para evaluar y calcular;
Salida anormal, como: asesino de memoria baja, tachado en la lista de tareas, anomalía del sistema, corte de energía, apagado / reinicio provocado por el usuario, etc., es decir, la tasa anormal se utiliza para evaluar el cálculo.
Crash , es decir, el programa es anormal, lo que hace que se cierre. incluir:
Java se bloquea, es decir, se produce una excepción no detectada en el código Java, lo que hace que el programa se cierre de forma anormal. Tales como: excepción de puntero nulo, excepción de matriz fuera de límites, etc.
Excepción nativa, es decir, en el código nativo, se produce un error y se genera la señal de señal correspondiente, lo que hace que el programa se cierre de forma anormal. Tales como: acceder a direcciones ilegales, abordar problemas, etc.
La captura de bloqueos de Java es relativamente simple, y la captura de bloqueos nativos puede requerir que tengamos una cierta comprensión del conocimiento subyacente del sistema. Sabemos que Android está basado en el sistema Linux, y la mayoría de las fallas en el sistema son causadas por errores de codificación o errores de hardware. Cuando el sistema encuentra un error irrecuperable, dispara el proceso de manejo de excepciones mediante interrupciones anormales, y el procesamiento de estas interrupciones se unifica como un semáforo. Cuando la aplicación recibe un determinado semáforo, se procesará de acuerdo con las acciones predeterminadas del kernel, como Term, lgn, Core, Stop y Cont. Al mismo tiempo, también podemos registrar y recibir señales a través de sigaction para especificar acciones de procesamiento, como capturar información sobre fallos. Por supuesto, existen algunas dificultades en el proceso de captura, especialmente en entornos extremos, como el desbordamiento de la pila, debido a que el espacio de la pila se ha agotado, no se puede llamar a nuestra función de procesamiento de señales, por lo que no se puede capturar la información del bloqueo. tiempo, debemos considerar el uso de la pila de señales para que nuestra función de procesamiento de señales pueda asignar un espacio de memoria en el montón como una "pila de señales reemplazable" para procesar la información de caída.
Por supuesto, además de las capacidades de captura estables y seguras, también es necesario enriquecer la información contextual del sitio del accidente, como la información de Logcat, la información de la pila de llamadas, la información del dispositivo, la información ambiental, etc., para brindarnos una información completa. referencia para el posicionamiento posterior y la resolución de problemas.
En el caso de un accidente, utilizamos la tasa de accidentes como indicador de datos. incluir:
Tasa de fallas de UV, es decir, usuarios deduplicados / usuarios deduplicados activos totales con errores de fallas;
Tasa de caída de PV, es decir, la cantidad de errores de caída / la cantidad de inicios;
La tasa de fallas de inicio, es decir, la falla que ocurre durante el proceso de inicio de la aplicación, se pasa por alto fácilmente, pero es un indicador de fallas muy importante, porque el inicio es una etapa muy importante en el ciclo de vida de la APLICACIÓN y muchos anuncios, pantallas de presentación, actividades y Hay otros contenidos en Este proceso revela que es necesario cargar varias inicializaciones durante el inicio, y si hay un error en el inicio, las estrategias de recuperación ante desastres de reparación en caliente y degradación no pueden compensarlo.
ANR, es decir, la aplicación no responde , cuando la aplicación no responde de manera oportuna durante un período de tiempo, aparecerá un cuadro de diálogo ANR, que le permitirá al usuario elegir continuar esperando o cerrarlo a la fuerza. Desde la perspectiva de la experiencia del usuario, a veces ANR puede traer una experiencia peor que una falla, por lo que los desarrolladores también deben prestar mucha atención a la ANR mientras prestan atención a las fallas.
La precisión de la captura de ANR siempre ha sido un proceso de actualización y mejora continua. En los primeros días, usamos FileObserver para monitorear los cambios en el archivo /data/anr/traces.txt para capturar e informar, pero desafortunadamente con la actualización de la versión, el sistema y el fabricante comenzaron a restringir los permisos de los archivos del sistema, y la cobertura de esta solución es cada vez más baja. Como resultado, la precisión de la captura de ANR también se ha reducido.
Luego, mejoramos la forma de monitorear el tiempo de ejecución de la cola de mensajes para capturar ANR, es decir, poner un mensaje vacío en el hilo principal Looper y monitorear si el mensaje vacío se ejecuta después de 5 segundos, pero esta solución no puede capturar realmente el Situación de ANR (hay situaciones de notificación insuficiente y de notificación falsa), y no se puede obtener el contenido completo de ANR. En el seguimiento, nos referimos al principio de realización de Android ANR para implementar una solución de captura ANR precisa y en tiempo real, que sea compatible con todas las versiones del sistema. Sabemos que el proceso system_server del sistema enviará una señal SIGQUIT (señal 3) al proceso ANR después de que detecte el ANR en la APLICACIÓN. Por defecto, libart.so del sistema recibirá esta señal y llamará al método de volcado de la máquina virtual Java para generar trazas.
Al interceptar SIGQUT, primero recibimos la señal cuando ocurre ANR, y generamos trazas y registros ANR. Después de procesar la señal, continuaremos pasando la señal al sistema para que el sistema genere el archivo de trazas. Al generar el archivo de trazas, Asegurarse de que el contenido y el sistema sean nativos Al mismo tiempo, también mejora significativamente la velocidad de generación de archivos de seguimiento, lo que efectivamente evita la posibilidad de que el tiempo de generación de seguimiento sea demasiado largo, y system_server usa SIGKILL (señal 9) para matar de nuevo. Al mismo tiempo, capturamos el contenido. Se ha enriquecido, incluyendo: la razón para activar el ANR, el uso de CPU del proceso TOP en el teléfono móvil, el uso de CPU del subproceso TOP en el proceso ANR, la distribución del tiempo de procesamiento del núcleo de la CPU, el tiempo de espera de las operaciones de E / S del disco y otra información importante, para analizar, localizar y resolver el problema de ANR y proporcionar un soporte más sólido.
De manera similar, para la situación en la que ocurre ANR, también lo dividimos en tasa ANR UV y tasa ANR PV El algoritmo puede referirse al cálculo de la tasa de caída anterior.
Por supuesto, además de los bloqueos y los ANR, a menudo ignoramos el escenario de una salida anormal, pero a menudo a través de una salida anormal podemos encontrar problemas que no se pueden capturar normalmente, como el asesino de memoria baja y el reinicio del sistema. Por ejemplo, los bloqueos causados por problemas de compatibilidad, reinicios del dispositivo y bibliotecas tripartitas que llaman activamente a la función de salida, lo que resulta en un aumento en el número de bloqueos de aplicaciones, etc. son difíciles de encontrar. Por lo tanto, podemos comprender y medir completamente la estabilidad de la aplicación a través de la tasa de salida anormal.
En resumen, creo que todos deberían tener una respuesta a la pregunta al principio del artículo. Por supuesto, no debemos usar la captura de intentos manual para evadir ciertos problemas con el fin de encubrir problemas de calidad del código. Esto puede interrumpir el uso normal del usuario y causar un bloqueo perceptivo de la retroalimentación. Debe basarse en la percepción real del usuario cuando usa la APLICACIÓN. Plantee, detecte y resuelva los problemas a tiempo cuando surjan problemas.
La estabilidad de la aplicación es un proceso iterativo a largo plazo. En este proceso, U-APM es una buena herramienta para mejorar la eficiencia y reducir los costos. Proporciona la capacidad de recopilar, analizar, agregar y analizar. En el próximo número, comenzaremos de Esté atento a las explicaciones sobre cómo resolver y lidiar con fallas, ANR y otros problemas a través de U-APM.