Cómo obtener registros de fallos de aplicaciones en el desarrollo de iOS

Cuando una aplicación iOS falla, el sistema creará un registro de fallos y lo guardará en el dispositivo. Este registro de fallos registra la información de tiempo del fallo de la aplicación y generalmente contiene información de llamada de pila para cada subproceso de ejecución (excepto los registros flash con poca memoria), lo que ayuda a los desarrolladores a localizar el problema.

Si el dispositivo está cerca, puede conectarlo, abrir Xcode - Ventana - Administrador, seleccionar Dispositivos en el panel izquierdo

Registros (puede seleccionar registros de dispositivo para un dispositivo específico O los registros de dispositivos

de todos los dispositivos en la biblioteca) y luego vea los registros de fallas en el dispositivo ordenados por tiempo. Este es el método más común utilizado durante las fases de desarrollo y prueba.

Si la aplicación se envió a la App Store para su publicación y los usuarios la instalaron, el desarrollador puede usar iTunes Connect (Administre su

aplicación - Ver detalles - Bloqueo

p>

report) para obtener el registro de fallos del usuario. Sin embargo, esto no es 100% efectivo y la mayoría de los desarrolladores no confían en él porque requiere que el dispositivo del usuario dé su consentimiento para cargar información, como se describe en iOS:

Proporciona un resumen de información de diagnóstico y uso. a Apple.

Este es un problema teniendo en cuenta que no todos los usuarios de iPhone pueden enviar automáticamente informes de diagnóstico (registros de fallos) y que algunos registros de fallos enviados a Apple requieren extracción y análisis manual para encontrar los archivos de símbolos correspondientes. de un trabajo tedioso, por lo que no estamos seguros de que sea una buena idea. Esto es algo muy tedioso. Por lo tanto, en el desarrollo de proyectos reales, generalmente se conecta a herramientas de recopilación de fallas existentes (Referencia 1, Referencia 2) o escribe sus propias herramientas para la recopilación, el análisis y el resumen estadístico automático.

En segundo lugar, cómo analizar el registro de fallos

Cuando obtenemos una copia del registro de fallos, necesitamos asignar la información original (como la dirección hexadecimal mostrada inicialmente) al nombres de métodos a nivel de código fuente y líneas de código para que sean legibles por los desarrolladores. Este proceso se llama resolución de símbolos. Para realizar correctamente la resolución de símbolos en los registros de fallos, necesitamos los binarios de la aplicación adecuados, así como los archivos de símbolos (.dSYM).

Si se encuentra en la fase de depuración, Xcode normalmente buscará coincidencias con los archivos binarios del registro de fallas y los archivos de símbolos, por lo que puede resolver estos archivos automáticamente.

Si estás en una fase de prueba y los evaluadores instalan diferentes versiones (por ejemplo, alfa, beta), debes guardar la versión correspondiente de los archivos binarios y símbolos para que el registro de fallas se pueda analizar si la aplicación falla. . Para el registro de fallos generado en este caso, simplemente puede colocar el archivo .crash, el archivo .app y el archivo .dSYM en el mismo directorio, luego arrastrar y soltar el archivo .crash en Registros de dispositivos en Bibliotecas en el panel izquierdo de Xcode. Sólo

- Ventana - Análisis.

Si deseamos comprometernos para el lanzamiento, normalmente realizamos una limpieza, luego una compilación y finalmente un empaquetado a través de Producto -

Archivo. De esta manera, Xcode archiva los archivos binarios y de símbolos juntos y los hace navegables a través del archivo en el organizador.

Tres: Cómo analizar los registros de fallos

Antes de analizar los registros de fallos, es mejor que los desarrolladores tengan una cierta comprensión de los tipos de errores comunes.

Los registros de fallos son el resultado de dos tipos de problemas: que te eliminen por violar la política de iOS y errores en tu propio código.

1. Política de iOS

1.1 Flashback de memoria baja

Como se mencionó anteriormente, la mayoría de los registros de fallas contienen información de llamada de pila para el subproceso que los ejecutó, excepto los de baja memoria. registros de flashback de memoria. A continuación, veremos rápidamente cómo se ve un registro de flashback con poca memoria.

Utilizamos dispositivos Xcode 5 e iOS

7 para simular un fallo de memoria insuficiente y luego miramos el registro de fallos generado a través del Organizador y descubrimos que tanto el Proceso como el Tipo eran desconocidos:

p>

El contenido del registro específico es el siguiente:

La primera parte es la información del fallo. La primera parte es información sobre fallas, incluida la identificación, información de hardware y software e información de tiempo.

La segunda parte es la información del fallo.

La segunda parte es la información de asignación de la página de memoria y el proceso que ocupa actualmente la mayor cantidad de memoria, que se muestra como crashTypeDemo.

La tercera parte es una lista de procesos específicos, que describe cómo cada proceso usa la memoria y su estado actual. En versiones anteriores, se podía ver "desechado" después de algunos procesos, lo que indicaba que esos procesos se eliminaban por usar demasiada memoria, mientras que ahora vemos las palabras "vm-pageshortage" (vm - escasez de páginas).

Cuando iOS detecta que la memoria es demasiado baja, (el sistema de la máquina virtual) emitirá una notificación de advertencia de memoria baja e intentará recuperar algo de memoria; si la situación no ha mejorado lo suficiente, iOS finalizará; la aplicación en segundo plano recupera más memoria; finalmente, si todavía no hay suficiente memoria, la aplicación en ejecución puede finalizar.

Por lo tanto, nuestra aplicación debe responder adecuadamente a las notificaciones de advertencia de poca memoria lanzadas por el sistema, liberar algunos datos almacenados en caché y objetos recreables, y evitar problemas como pérdidas de memoria.

Los fallos por falta de memoria están determinados por las políticas de iOS que finalizan la aplicación. También se basan en las políticas de iOS los tiempos de espera de vigilancia y las salidas forzadas del usuario.

1.2 Tiempo de espera de vigilancia

Desarrollador de iOS de Apple

El documento QA1693 en el sitio web de la biblioteca presenta el mecanismo de vigilancia, incluidos escenarios de aplicación efectivos y comportamiento. Si nuestra aplicación no responde a ciertos eventos de la interfaz de usuario de manera oportuna (por ejemplo, inicio, suspensión, reanudación, finalización), Watchdog cerrará nuestra aplicación y generará un informe de falla de la respuesta.

Lo interesante de este informe de fallos es el código de excepción: "0x8badf00d", que significa "comer comida mala".

Si un evento de UI específico es abstracto, la descripción directa en el código corresponderá a varios métodos en UIApplicationDelegate (Xcode lo generará automáticamente cuando crees el proyecto)

Por lo tanto, cuando Si encuentra el registro de vigilancia, puede verificar el método anterior que bloquea más operaciones de la interfaz de usuario. Operaciones de interfaz de usuario.

El ejemplo dado en QA1693 es una solicitud de red síncrona en el hilo principal. Si lo usamos en un entorno Wifi corporativo, entonces todo funciona bien, pero cuando la aplicación se distribuye a una amplia gama de usuarios que se ejecutan en varios entornos de red, inevitablemente habrá fragmentos de informes de tiempo de espera de vigilancia.

Otra situación en la que pueden surgir problemas es la migración de la versión de la base de datos (también en el hilo principal, la cantidad de datos es grande en este momento, que también es el factor directo que me impulsó a escribir este resumen).

1.3 El usuario fuerza la salida

Cuando veas "El usuario fuerza la salida", tu primer pensamiento puede ser hacer doble clic en el botón de inicio y cerrar la aplicación. Sin embargo, no se generará ningún registro de fallos en este escenario porque todas las aplicaciones están en segundo plano después de hacer doble clic en el botón Inicio y iOS puede cerrar procesos en segundo plano en cualquier momento, por lo que no se generará ningún registro de fallos en este escenario.

Otro escenario es cuando el usuario mantiene presionados el botón de Encendido y el botón de Inicio al mismo tiempo, lo que hace que el iPhone se reinicie. Este escenario genera registros (validados solo una vez) pero no es relevante para la aplicación.

El funcionamiento del escenario de la aplicación "Usuario forzado a salir" es un poco complicado: presione y mantenga presionado el botón de encendido hasta que aparezca la pantalla "Deslizar para apagar", luego presione y mantenga presionado el botón Inicio. la aplicación actual será cancelada y se generará el correspondiente informe de fallas de los eventos. Esto finalizará la aplicación actual y generará un registro de fallos de los eventos correspondientes.

Normalmente, esto sucede cuando una aplicación se bloquea y afecta la capacidad de respuesta de iOS, pero este caso parece muy avanzado, por lo que los registros de fallas como este deberían ser raros.

2. Códigos de error comunes

2.1 Códigos de excepción

La excepción en el registro de fallos "usuario obligado a salir" anterior

El El código es "0xdeadfa11", y la excepción en el registro de fallas "Watchdog Timeout" anterior

El código es "0x8badf00d"

Según la documentación oficial, existe al menos lo siguiente código de excepción específico:

Código de error 0x8badf00d: tiempo de espera de vigilancia, que significa "comer comida en mal estado". ".

Código de error 0xdeadfa11: el usuario sale a la fuerza, lo que significa "caer hasta morir".

Código de error 0xbaaaaaad: el usuario presiona el botón Inicio y el botón de volumen para obtener el estado actual de la memoria no significa una falla

0xbad22222 Código de error: iOS eliminó la aplicación VoIP (¿con demasiada frecuencia?)

0xc00010ff Código de error: se eliminó porque también lo era. hot.Dead significa "enfriamiento".

Código de error 0xdead10cc: el motivo de la muerte es que todavía está ocupando recursos del sistema (como contactos) en segundo plano, es decir, "punto muerto". 2.2 Tipos de excepción

Al revisar los correos electrónicos de informes de análisis de fallos, encontramos que el tipo de error más común es SEGV (Segmentación

Violación), que indica una manipulación inadecuada de la memoria. Por ejemplo, se accede a una dirección de memoria sin privilegios

Cuando recibimos una señal SIGSEGV, podemos considerar las siguientes situaciones:

Acceder a una dirección de memoria no válida, como por ejemplo un objeto Zombie;

Intentó escribir en un área de solo lectura;

Hizo referencia a un puntero nulo;

Utilizó un puntero no inicializado;

Desbordamiento de pila;

Además, existen otras señales comunes:

SIGABRT: Al recibir la señal de terminación, puede ser que llame a abort() él mismo, o puede ser que reciba una señal externa;

SIGBUS: error de bus. SIGSEGV accede a una dirección no válida (por ejemplo, la memoria virtual no está asignada a la memoria física), mientras que SIGBUS accede a una dirección válida, pero hay una excepción de acceso al bus (por ejemplo, problema de alineación de direcciones). ;

SIGBUS: error de bus, problema de alineación de direcciones);

SIGILL: intentando ejecutar una instrucción ilegal, que puede no ser reconocida o autorizada;

SIGFPE: errores de punto flotante, problemas relacionados con cálculos matemáticos (puede no limitarse a cálculos de punto flotante), como operaciones de división por cero;

SIGPIPE: no hay ningún proceso en el otro extremo de la tubería para hacerse cargo de los datos;

3. Errores de código

Además, los fallos más comunes son causados ​​básicamente por errores de código, como el desbordamiento de matrices o la inserción de valores nulos. , seguridad de subprocesos múltiples, acceso a punteros salvajes, envío de selectores no implementados, etc. Si se introducen Core

Data, surgen otros problemas comunes, pero ese es otro tema

Cuando estos. Si se encuentran errores, hay una explicación clara de la causa del error, como "Índice 0. Más allá de los límites de la matriz vacía". Una cosa a tener en cuenta es el problema de subprocesos múltiples. Si no puedes encontrar una solución en este momento, también puedes considerarla desde la perspectiva de subprocesos múltiples.