Análisis en profundidad de la optimización de la estabilidad de Android

Autor: Programador Jiang

prefacio

AndroidLa estabilidad de la aplicación es Androidun indicador importante del rendimiento, y también es la parte más básica y crítica del sistema de construcción de calidad de la aplicación . Si la aplicación falla con frecuencia o si las funciones clave no están disponibles, eso obviamente tiene un gran impacto en nuestra retención.
Para garantizar la estabilidad de la aplicación, primero debemos establecer una comprensión correcta de la estabilidad.Este artículo incluye principalmente los siguientes contenidos:

Comprensión correcta de la optimización de la estabilidad
CrashPasos generales en el procesamiento
CrashGobernanza a largo plazo
Construcción de soluciones de alta disponibilidad empresarial
Preguntas comunes de la entrevista sobre optimización de la estabilidad

Comprensión correcta de la optimización de la estabilidad

Métricas clave para la optimización de la estabilidad

Para optimizar la estabilidad, la primera pregunta es, ¿qué efecto se debe lograr? Crash¿Cuál es la tasa de excelencia?Solo después de aclarar el objetivo podemos entender correctamente el papel de nuestro trabajo.

Para calcular Crashla tasa, primero debemos comprender algunos indicadores clave de la optimización de la estabilidad.

`UV Crash`tasa contra `PV Crash`tasa

PV（Page View）Es decir, el número de visitas, UV（Unique Visitor）es decir, visitantes únicos, y el mismo terminal dentro de 0-24 horas solo se cuenta una vez

UV CrashTasa: Para las estadísticas de uso de los usuarios, se cuenta la proporción de caídas de todos los usuarios en un período de tiempo, que se utiliza para evaluar el Crashrango de influencia de la tasa.
PV CrashTasa: en función de las estadísticas de los tiempos de uso de los usuarios, evalúe Crashla gravedad de los impactos relacionados.

Puede elegir el indicador apropiado según sus propias necesidades. Cabe señalar que debe asegurarse de utilizar siempre el mismo método de medición.

`Crash`tasa de evaluación

Entonces, ¿cuánto más baja es nuestra Apptasa Crashpara ser considerada un nivel normal o un nivel excelente?

JavaLa Nativetasa total de accidentes debe ser inferior al 2 por mil.
CrashEl percentil 10,000 es excelente

Tenga en cuenta que lo mencionado anteriormente es UVla tasa de accidentes

Dimensiones de la optimización de la estabilidad

Mucha gente piensa que la optimización de la estabilidad es para reducir Crashla tasa, pero si su aplicación APPno falla, pero las funciones clave no están disponibles, ¿cómo puede considerarse estable?,
por lo tanto, la estabilidad de la aplicación se puede dividir en tres latitudes, como sigue:

1. CrashLatitud: El indicador más importante es Crashla tasa de aplicación.
2. Latitud de rendimiento: incluidas las direcciones de optimización, como la velocidad de inicio, la memoria, el dibujo, etc., que Crashson relativamente secundarias, pero también forman parte de la estabilidad de la aplicación.
3. Latitud de alta disponibilidad comercial: este es un paso muy crítico. Necesitamos usar varios métodos para garantizar Appla estabilidad de nuestro proceso principal y ruta principal.

`Crash`Pasos generales en el procesamiento

Echemos un vistazo a cómo lidiar con eso Crash, es decir, si la aplicación falla, ¿cómo debes analizarla?
Analizar principalmente desde dos perspectivas de la escena del accidente y el análisis del accidente.

lugar del accidente

La escena del accidente es nuestra "primera escena del crimen" y contiene muchas pistas valiosas. Cuanta más información extraigamos aquí, más clara será la dirección del próximo análisis, en lugar de confiar en conjeturas ciegas.
A continuación, echemos un vistazo a qué información se debe recopilar en el lugar del accidente.

Información de Accidentes

A partir de la información básica del accidente, podemos tener un juicio preliminar sobre el accidente.

Nombre del proceso, nombre del hilo. ¿El proceso de bloqueo es un proceso en primer plano o en segundo plano, y si el bloqueo se produjo en el subproceso de la interfaz de usuario?
Bloqueo de pila y tipo. ¿El accidente pertenece a Javaaccidente , Nativeaccidente o ANR, prestamos atención diferente a los diferentes tipos de accidentes. En particular, debemos mirar la parte superior de la pila de fallas para ver si la falla específica está en el código del sistema o en nuestro propio código.

Mensaje del sistema

Además de la información del bloqueo, la información del sistema a veces contiene algunas pistas clave, que son muy útiles para resolver el problema.

Logcatproducción. Esto incluye los registros de funcionamiento de la aplicación y del sistema. A veces, no puede ver mucha información de la pila, pero puede obtener ganancias inesperadas Logcatde ella.
Modelo, sistema, fabricante, CPU, ABI, Linuxversión, etc. Recopilaremos hasta docenas de dimensiones, que serán muy útiles para encontrar problemas comunes cuando hablemos de ello más adelante.
Estado del dispositivo: si root, si es un emulador. Algunos problemas son causados por Xposedla apertura excesiva del software, tenemos que tratar estos problemas de manera diferente.

información de la memoria

OOM, ANR, agotamiento de la memoria virtual, etc., muchos bloqueos están directamente relacionados con la memoria. Si dividimos la memoria del teléfono móvil del usuario en dos grupos de "menos de 2 GB" y "más de 2 GB", encontraremos que la tasa de fallas de los usuarios de "menos de 2 GB" es varias veces mayor que la de los usuarios de "más de 2 GB".

Memoria restante del sistema. En cuanto al estado de la memoria del sistema, los archivos se pueden leer directamente /proc/meminfo. Cuando la memoria disponible del sistema es muy pequeña (menos MemTotaldel 10%), es muy probable que ocurran problemas como OOMmemoria, grandes cantidades GCy suicidios frecuentes del sistema.
Las aplicaciones usan memoria. Incluyendo Javamemoria , RSS( Resident Set Size), PSS( Proportional Set Size), podemos obtener el tamaño y distribución de la memoria propia de la aplicación.
Memoria virtual. La memoria virtual /proc/self/statusse puede obtener , y /proc/self/mapsla distribución específica se puede obtener a través del archivo. A veces, por lo general, no prestamos mucha atención a la memoria virtual, pero muchos problemas como OOM, tgkilletc. son causados por una memoria virtual insuficiente.


Name:     com.sample.name   // 进程名
FDSize:   800               // 当前进程申请的文件句柄个数
VmPeak:   3004628 kB        // 当前进程的虚拟内存峰值大小
VmSize:   2997032 kB        // 当前进程的虚拟内存大小
Threads:  600               // 当前进程包含的线程个数

En términos generales, para un proceso de 32 bits, si es de 32 bits CPU, la memoria virtual alcanza los 3 GB, lo que puede causar fallas en la aplicación de memoria. Si es de 64 bits CPU, la memoria virtual suele estar entre 3 y 4 GB. Por supuesto, si admitimos procesos de 64 bits, la memoria virtual no será un problema. Por lo tanto, nuestra aplicación debe intentar adaptarse a 64 bits

información de recursos

A veces encontraremos que la memoria del montón de la aplicación y la memoria del dispositivo son muy suficientes, pero aún habrá fallas en la asignación de memoria, que pueden tener una mayor relación con las fugas de recursos.

manejador de fdarchivos Por lo general, el número máximo de identificadores de archivos que puede abrir un solo proceso es 1024. Pero si el identificador del archivo 800excede , es más peligroso. Debe fdenviar todos los nombres de archivo y los correspondientes al registro, y verificar si hay una fuga de archivo o hilo.
Hilos. Un solo subproceso puede 2MBocupar la memoria virtual, demasiados subprocesos ejercerán presión sobre la memoria virtual y los identificadores de archivos. Según mi experiencia, si el número de subprocesos supera los 400, es peligroso. Todos los subprocesos idy enviarse al registro para verificar si hay problemas relacionados con los subprocesos.

información de la aplicación

Además del sistema, nuestra aplicación se comprende mejor a sí misma y puede dejar mucha información relevante.

Escena del accidente. En cuál Activityo Fragment, en qué negocio ocurrió el accidente.
ruta crítica de operación. A diferencia del registro de gestión detallado durante el proceso de desarrollo, podemos registrar las rutas de operación de los usuarios clave, lo que nos será de gran ayuda para reproducir fallas.
Información personalizada adicional. Las diferentes aplicaciones pueden tener diferentes preocupaciones. Por ejemplo, Netease Cloud Music se centrará en la música que se está reproduciendo actualmente, y QQ Browser se centrará en la URL o el vídeo actualmente abierto. Además, información como el tiempo de actividad, si se ha cargado un parche, si se trata de una instalación nueva o una actualización, etc., también son muy importantes.

La información que debe recopilarse en el lugar del accidente se introdujo anteriormente. Por supuesto, aún es muy complicado desarrollar una plataforma de recopilación de este tipo. En la mayoría de los casos, solo necesitamos acceder a algunas plataformas de terceros como buglyy Sentry. Pero a través de la introducción anterior, podemos saber en qué información debemos centrarnos al analizar fallas. Al mismo tiempo, si faltan las capacidades de la plataforma, también podemos agregar informes personalizados.

análisis de accidentes

Una vez que se reporta suficiente información en el lugar del accidente, podemos comenzar a analizar el accidente. A continuación, presentamos la "trilogía" del análisis de accidentes.

Paso 1: determina tu enfoque

Para confirmar y analizar los puntos clave, la clave es encontrar información importante en el registro y tener un juicio general sobre el problema. En términos generales, sugiero que pueda concentrarse en los siguientes puntos en el paso de determinar el enfoque.

Confirme la gravedad y la prioridad . Resolver fallas también depende de la rentabilidad Damos prioridad a resolver Topfallas o tener un gran impacto en el negocio.
Información básica sobre accidentes . Determine el tipo de bloqueo y la descripción de la excepción, y tenga un juicio aproximado sobre el bloqueo. En términos generales, la mayoría de los bloqueos simples se pueden concluir después de este paso.

Javacolapsar. JavaEl tipo de bloqueo es obvio, NullPointerExceptioncomo un puntero nulo OutOfMemoryErroro recursos insuficientes. En este momento, debe verificar más la "información de memoria" y la "información de recursos" en el registro.
Nativecolapsar. Necesidad de ver signal, etc, y la pila en el codemomento delfault addr accidente . JavaPara obtener una introducción al signalsignificado , puede ver la introducción a las señales de choque. Los más comunes son SIGSEGVy SIGABRT, el primero generalmente es causado por punteros nulos y punteros ilegales, y el último ANRes abort()causado principalmente por llamadas y salidas.
ANR. Mi experiencia es, primero mire la pila del hilo principal, si es causado por la espera de bloqueo. Luego ANRmire iowait, CPU, y otra información en el registro para determinar si se trata de un problema , un problema GCde competencia o una gran cantidad de causas que hacen la tarjeta muera.system serverI/OCPUGC

Logcat. LogcatEn general, habrá algunas pistas valiosas, y el nivel de registro es Warningy Errornecesita atención especial. A partir de Logcatél podemos ver algunos comportamientos del sistema y el estado del móvil en ese momento, por ejemplo, ANRcuando aparece, estará "am_anr", Appcuando se mata, estará "am_kill". Los registros generados por diferentes sistemas y fabricantes son diferentes. Cuando no pueda ver la causa del problema u obtener información útil de un registro de fallas, no se dé por vencido. Se recomienda verificar más registros de fallas en el mismo punto de falla. .
La situación de cada recurso. Combinado con la información básica del bloqueo, veamos si está relacionado con "información de memoria" o "información de recursos". Por ejemplo, la memoria física es insuficiente, la memoria virtual es insuficiente o el identificador de archivo se fdpierde .

Tanto los archivos de recursos como Logcatla información relacionada con la memoria y los subprocesos requieren una atención especial, y muchos bloqueos se deben a su uso inadecuado.

Paso dos: encontrar puntos en común

Si el método anterior aún no puede localizar el problema de manera efectiva, podemos intentar averiguar si hay puntos en común en tales bloqueos. Una vez que se encuentran los puntos en común, se pueden encontrar más diferencias y la solución al problema estará un paso más cerca.

Modelo, sistema ROM, fabricante y ABIesta información recopilada del sistema se puede agregar como dimensiones Problemas comunes como si es porque está instalado Xposed, si solo aparece en teléfonos móviles x86de , si es solo el modelo de Samsung, si está sólo en el sistema Android 5.0de . La información de la aplicación también se puede agregar como dimensiones, como enlaces que se abren, videos que se reproducen, países, regiones, etc. Si encuentra algo en común, puede tener pautas más claras para su próximo paso para reproducir el problema.

Paso 3: intenta reproducir

Si ya conocemos la causa del bloqueo, para confirmar más información, debemos intentar reproducir el bloqueo. Si no tenemos ninguna pista sobre el bloqueo, también esperamos intentar reproducirlo a través de la ruta de operación del usuario y luego analizar la causa del bloqueo.

"Mientras se pueda reproducir localmente, puedo resolverlo", creo que es lo que han dicho muchos desarrolladores y pruebas. Dicha confianza se debe principalmente a que en la ruta de recurrencia estable, podemos usar varios medios o herramientas, como agregar registros o usarlos para un análisis posterior Debugger.GDB

Resolución de fallos del sistema

A veces, algunos bloqueos no son causados por nuestra aplicación, sino por el sistema. Los bloqueos del sistema a menudo nos hacen sentir muy impotentes. Puede ser causado por una determinada Androidversión modificaciónbug por parte de un determinado fabricante . La pila de errores en este caso puede no tener nuestro propio código y es difícil localizar directamente el problema.ROM

Para este difícil problema, podemos intentar resolverlo a través de los siguientes métodos.

Busque las posibles causas. A través de la clasificación común anterior, primero verifiquemos si se trata de un problema de una determinada versión del sistema o un problema específico ROMde . Aunque el registro de fallas puede no tener nuestro propio código, al manipular la ruta y el registro, podemos encontrar algunos puntos sospechosos.
Intenta evitarlo. Verifique las llamadas de código sospechosas, si se usan inapropiadas APIy si se pueden usar otros métodos de implementación para evitarlas.
Hookresolver. Después de comprender el motivo, finalmente puede Hookmodificar la lógica del código del sistema para solucionarlo.

Por ejemplo, descubrimos que hubo un bloqueo del sistema Toastrelacionado , que solo apareció Android 7.0en el sistema de, y parecía Toastque la ventana tokenno era válida cuando se mostraba. Es posible que la ventana haya sido destruida cuando Toastnecesita ser mostrada.

android.view.WindowManager$BadTokenException: 
  at android.view.ViewRootImpl.setView(ViewRootImpl.java)
  at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java)
  at android.view.WindowManagerImpl.addView(WindowManagerImpl.java4)
  at android.widget.Toast$TN.handleShow(Toast.java)

Android 8.0¿Por qué el sistema no tiene este problema? Android 8.0Después de revisar el código fuente de , encontramos las siguientes modificaciones:

try {
  mWM.addView(mView, mParams);
  trySendAccessibilityEvent();
} catch (WindowManager.BadTokenException e) {
  /* ignore */
}

Por lo tanto, podemos referirnos a Android 8.0su práctica y catchcaptar directamente esta excepción. La clave aquí es encontrar Hookel punto , Toasthay una variable llamada mTN, su tipo es handler, solo necesitamos hacer un proxy para realizar la captura.

`Crash`Gobernanza a largo plazo

Lo anterior describe Crashlos pasos generales para manejar en línea, pero Crashla etapa realmente importante de la gobernanza es antes de entrar en línea. Necesitamos comenzar desde la etapa de desarrollo y llevar a cabo Crashuna gobernanza sistemática a largo plazo.

etapa de desarrollo

CrashLa gobernanza a largo plazo debe comenzar desde la etapa de desarrollo. A largo plazo, una mejor calidad del código traerá una mayor estabilidad. Podemos mejorar la calidad del código desde las siguientes dos perspectivas

Estándares de codificación unificados, habilidades de codificación mejoradas, revisión técnica, CodeReviewmecanismo mejorado
Optimización de la arquitectura, convergencia de capacidades (encapsulación de algunas operaciones comunes), tolerancia a fallas unificada: por ejemplo, en las utilidades de la biblioteca de red, la información devuelta se verifica previamente de manera uniforme y, si es ilegal, el siguiente proceso no se seguirá directamente.

fase de prueba

Además de los procedimientos de prueba de rutina, como las pruebas funcionales, las pruebas automatizadas, las pruebas de regresión y la instalación de superposición, también es necesario probar escenarios, modelos y otros límites especiales: como datos anormales devueltos por el servidor, tiempo de inactividad del servidor, etc. .

etapa compuesta

Cuando nuestra función está desarrollada y está a punto de fusionarse con la rama principal, primero debemos realizar una detección de compilación y un escaneo estático para encontrar posibles problemas.
Una vez que se completa el escaneo, no se puede fusionar directamente porque varias ramas pueden entrar en conflicto, por lo que primero realizamos un proceso de precompilación, es decir, fusionamos en una rama que es la misma que la rama principal y luego la empaquetamos para que sea automática. prueba de regresión del proceso principal Después de que el proceso pasa Merge a la rama principal nuevamente. Por supuesto, puede ser problemático hacerlo, pero estos pasos deben automatizarse.

etapa de lanzamiento

En la etapa de lanzamiento, debemos realizar múltiples rondas de escala de grises, y la escala de grises debe cambiar gradualmente de pequeña a grande, para exponer los problemas por adelantado con el costo más bajo.
Los lanzamientos en escala de grises también deben dividirse en escenarios y cubrir múltiples latitudes de manera integral. Se pueden realizar escalas de grises especiales para versiones especiales, modelos, etc., para ver si los usuarios que tienen más probabilidades de tener problemas tienen problemas.

Fase de operación y mantenimiento

Después de conectarse, también se debe prestar atención a los problemas de estabilidad, por lo que depende especialmente de APMun monitoreo sensible y una alarma oportuna cuando se encuentran problemas.
Si hay una situación anormal, también es necesario revertir o degradar la estrategia de acuerdo con la situación.
Si no se puede deshacer o degradar, también se puede reparar mediante una reparación en caliente. Si la reparación en caliente falla, solo puede confiar en la solución local de recuperación ante desastres para recuperarse.

Construcción de soluciones de alta disponibilidad empresarial

Mucha gente piensa que la optimización de la estabilidad es reducir Crashla tasa, pero de hecho, otra dimensión importante de la optimización de la estabilidad es la alta disponibilidad del negocio.
Es posible que la falta de disponibilidad del negocio no provoque un bloqueo, pero reducirá la experiencia del usuario, lo que afectará directamente a nuestros ingresos.

Construcción de soluciones de alta disponibilidad empresarial

A diferencia de la alta disponibilidad del negocio Crash, necesitamos recopilar datos nosotros mismos. Necesitamos ordenar el proceso principal, la ruta central, los nodos clave del proyecto y agregar puntos
Para la recopilación de datos, también podemos usar AOPmétodos para recopilar datos para reducir el costo de la gestión manual.
Después de informar los datos, podemos crear un tablero de datos y contar la tasa de conversión de cada paso.
Tras el informe de datos, también podemos establecer estrategias de alarma, como alarmas de umbral, alarmas de tendencia (en comparación con el mismo período) y alarmas de indicadores específicos (como fallas en el pago)
Al mismo tiempo, podemos hacer un trabajo de monitoreo anormal, como Catchinformar anomalías y lógica anormal. Aunque estas anomalías no fallarán, también es a lo que debemos prestar atención.
Para algunos problemas difíciles de resolver, podemos usar el método de recuperación de registro completo para usuarios específicos para recopilar más información.
Después de descubrir la anomalía, podemos resolver el problema a través de algunas estrategias de ida y vuelta, como ayudar a habilitar o deshabilitar el cambio de función a través del centro de configuración. Cuando encontramos un problema con una nueva función, podemos ocultar directamente la función, o configurar la ruta saltar a otra vía

Solución de recuperación ante desastres del cliente

Después de que ocurre una excepción de rendimiento o de negocio, ¿cómo debemos resolverla? El proceso tradicional debe pasar por varios pasos, como comentarios de los usuarios, reempaquetado y actualización del canal. Se puede ver que en realidad es más problemático y menos receptivo para los usuarios. Podemos construir una solución de recuperación ante desastres para el cliente desde las siguientes
perspectivas

Para funciones recién agregadas o refactorización de código, se admite configurar el interruptor a través del centro de configuración, y se puede cerrar a tiempo si ocurre un problema
Al mismo tiempo, si todas nuestras Apppáginas se redireccionan a través del enrutamiento, podemos saltar a la página de manejo de errores unificado configurando dinámicamente el enrutamiento, o saltar a la página temporal h5
Reparación mediante tecnología de reparación en caliente BUG, como acceder a Tencent Tinkero Meituan, Robustetc.
Si su proyecto usa RNo Weex, puede implementar directamente actualizaciones incrementales
Si el bloqueo ocurre al inicio APP, la actualización dinámica y la configuración dinámica no serán válidas en este momento, y se debe usar el modo seguro en este momento. El modo seguro Crashse restaura automáticamente de acuerdo con la información y restablece la aplicación al estado inicial de la instalación después de múltiples fallas de inicio. Si es particularmente grave Bug, también se puede solucionar bloqueando la reparación en caliente, es decir, solo después de que la reparación en caliente sea exitosa se puede ingresar APP. El modo seguro se puede usar no solo para APPcomponentes, sino también para componentes. Si un componente informa un error varias veces, puede ingresar a la página inferior

Preguntas comunes de la entrevista sobre optimización de la estabilidad

A continuación, se presentan las preguntas de la entrevista simulada para la optimización de la estabilidad.

¿Qué optimizaciones de estabilidad has hecho?

Respuesta de referencia:

Con la madurez gradual del proyecto, la base de usuarios ha aumentado gradualmente y DAUsigue aumentando. Hemos encontrado muchos problemas de estabilidad. Para nuestros estudiantes técnicos, hemos encontrado muchos desafíos. Los usuarios a menudo usan nuestros Appbloqueos o las funciones no están disponibles, por lo que hemos iniciado una optimización especial para la estabilidad, y hemos optimizado principalmente tres elementos:

CrashOptimización especial
Optimización de la estabilidad del rendimiento
Optimización de la estabilidad empresarial

A través de la optimización de estos tres aspectos, hemos construido una plataforma de alta disponibilidad para terminales móviles. Al mismo tiempo, se han tomado muchas medidas para Applograr verdaderamente una alta disponibilidad.

¿Cómo se hace la estabilidad del rendimiento?

Respuesta de referencia:

Optimización integral del rendimiento: velocidad de inicio, optimización de memoria, optimización de dibujo
Encuentre problemas sin conexión y céntrese en la optimización
Principalmente monitoreo en línea
CrashOptimización especial

Hemos realizado optimizaciones multidimensionales en términos de velocidad de inicio, memoria, carga de diseño, congelación, adelgazamiento, tráfico y potencia.

Nuestra optimización se divide principalmente en dos niveles, a saber, en línea y fuera de línea. Para fuera de línea, nos enfocamos en encontrar problemas y resolverlos directamente, con el objetivo de resolver los problemas tanto como sea posible antes de conectarse. Cuando se trata de la línea real, nuestro objetivo principal es monitorear. Para el monitoreo de varias latitudes de rendimiento, podemos obtener la alarma de situaciones anormales lo antes posible.

Al mismo tiempo, para el problema de rendimiento en línea más serio: Crash, hemos realizado una optimización especial, no solo optimizamos Crashlos indicadores específicos, sino que también obtuvimos la mayor Crashcantidad de información detallada posible cuando ocurrió, combinado con agregación de back-end, alarma y otras funciones, para que podamos localizar rápidamente el problema.

¿Cómo garantizar la estabilidad empresarial?

Respuesta de referencia:

Adquisición de datos + alarma
Es necesario monitorear el proceso principal y la ruta central del proyecto,
Al mismo tiempo, también necesitamos saber cuántas excepciones ocurrieron en cada paso, para que sepamos la tasa de conversión de todos los procesos comerciales y la tasa de conversión de la interfaz correspondiente.
Combinado con el mercado, si la tasa de conversión es inferior a un cierto valor, se emitirá una alarma
Monitoreo anormal + seguimiento de un solo punto
Estrategias de ida y vuelta, como el modelo de seguridad Tmall

La alta disponibilidad de los servicios móviles se enfoca en la disponibilidad completa de las funciones del usuario, principalmente para resolver algunas anomalías en línea que hacen que los usuarios no tengan bloqueos ni problemas de rendimiento, pero es solo una función simple que no está disponible. y la ruta central del proyecto se monitorean en puntos enterrados para calcular la tasa de conversión real de cada paso. Al mismo tiempo, también es necesario saber cuántas excepciones ocurrieron en cada paso. De esta forma, conocemos la tasa de conversión de todos los procesos de negocio y la tasa de conversión de la interfaz correspondiente.Con los datos del mercado, sabemos que si la tasa de conversión o la tasa de éxito de algún seguimiento es inferior a un valor determinado, es muy importante. Puede ser que haya una anomalía en línea. Combinado con la función de alarma correspondiente, no necesitamos esperar a que los usuarios den su opinión. Esta es la base para la garantía de estabilidad comercial.

Al mismo tiempo, para algunos casos especiales, por ejemplo, algunos bloques de código aparecen durante el proceso de desarrollo o en el código, catchy la excepción se detecta para que el programa no se bloquee. Esto en realidad no es razonable. Aunque el programa no se bloqueó. , la función del programa en ese momento ya no está disponible, por lo que catchtambién debemos informar estas anomalías, para que podamos saber qué problemas el usuario ha causado la anomalía. Además, hay algunos problemas de un solo punto en línea. Por ejemplo, los usuarios no pueden iniciar sesión después de hacer clic en el botón de inicio de sesión. Este es un problema de un solo punto. De hecho, no podemos encontrar los puntos en común entre este y otros problemas. es necesario encontrar sus correspondientes detalles.

Finalmente, si se produce una situación anómala, también hemos adoptado una serie de medidas para detener rápidamente la pérdida.

Si ocurre una situación anormal, ¿cómo detener rápidamente la pérdida?

Respuesta de referencia:

interruptor de función
centro de salto
Correcciones dinámicas: correcciones urgentes, actualizaciones de paquetes de recursos
Autocuración: modo seguro

En primer lugar, debe tener Appalgunas capacidades avanzadas. Para que se inicie cualquier función nueva, debemos agregar un interruptor de función. El interruptor emitido por el centro de configuración determina si mostrar la entrada de la nueva función. Si hay una situación anormal, la entrada de la nueva función se puede cerrar con urgencia, para que esta se mantenga Appen un estado controlable.

Luego, debemos Appconfigurar los saltos de enrutamiento. Todos los saltos de interfaz deben distribuirse a través del enrutamiento. Si hacemos coincidir una nueva función que necesita saltar a bugalguna , entonces no saltaremos o saltaremos a la interfaz de manejo de excepciones unificada. Si estos dos métodos no son posibles, puede considerar la reparación dinámica a través de la reparación en caliente. La solución actual de reparación en caliente es relativamente madura. Podemos agregar capacidades de reparación en caliente a nuestros proyectos a bajo costo. Por supuesto, sería mejor RNo , entonces la actualización dinámica se puede realizar actualizando el paquete de recursos. WeeXY si nada de esto es posible, puede considerar agregar una capacidad de autorreparación a la aplicación usted mismo. Si la inicia Appvarias veces, puede considerar borrar todos los datos almacenados en caché y Apprestablecerla al estado instalado. El nivel más grave puede bloquear el hilo principal En este momento, los usuarios deben esperar a que Appla revisión sea exitosa antes de permitir que los usuarios ingresen.

Resumir

Este artículo presenta principalmente Androidla comprensión correcta de la estabilidad, cómo manejarla Crash, Crashla gobernanza a largo plazo, la construcción de soluciones comerciales de alta disponibilidad, etc., y presenta algunas ideas y soluciones para la optimización de la estabilidad.

Cuando estamos en la optimización y el monitoreo del rendimiento, encontrará que hay muchos puntos de conocimiento relacionados con el Marco subyacente. Por lo tanto, mientras aprendemos la optimización y el monitoreo del rendimiento, también debemos aprender y comprender los principios subyacentes del Marco. Como referencia:

Notas del estudio de ajuste del rendimiento de Android:https://qr18.cn/FVlo89

Notas básicas de Android Framework:https://qr18.cn/AQpN4J