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

1. Cómo obtener el registro de fallos

Cuando una aplicación de iOS falla, el sistema creará un registro de fallos y lo guardará en el dispositivo. Este registro de fallas registra información cuando una aplicación falla y generalmente contiene información de llamadas de pila para cada subproceso de ejecución (con la excepción de los registros de fallas con poca memoria), lo cual es muy útil para que los desarrolladores localicen problemas.

Si el dispositivo está cerca, puede conectarlo, abrir Xcode - Ventana - Organizador y seleccionar Dispositivo en el panel izquierdo

Registros (puede seleccionar Registros de dispositivo o Biblioteca de el dispositivo específico

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

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

aplicaciones - Ver detalles - Bloqueo

Informes) 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 esto, porque requiere que el dispositivo del usuario acepte cargar información relevante. Para obtener más detalles, consulte iOS:

Proporcionar a Apple diagnósticos y uso. resumen de información.

Teniendo en cuenta que no todos los usuarios de iPhone permiten el envío automático de informes de diagnóstico (registros de fallos) y, para algunos registros de fallos enviados a Apple, los desarrolladores aún necesitan extraerlos manualmente y encontrar los archivos de símbolos correspondientes. - Esta es una tarea tediosa. Por lo tanto, en el desarrollo de proyectos reales, generalmente se conecta a las herramientas de recopilación de fallas existentes (referencia 1, referencia 2) o se escribe una usted mismo para la recopilación, el análisis y el resumen estadístico automatizados.

2. Cómo analizar los registros de fallos

Al obtener un registro de fallos, debemos asignar la información original, como la dirección hexadecimal que se muestra inicialmente, al nombre del método a nivel de código fuente. líneas de código para que sea legible para los desarrolladores. Este proceso se llama análisis simbólico. Para analizar simbólicamente con éxito un registro de fallos, necesitamos los archivos binarios y de símbolos (.dSYM) de la aplicación correspondiente.

Si se encuentra en la etapa de desarrollo y depuración, Xcode generalmente puede hacer coincidir el archivo binario y el archivo de símbolos correspondiente al registro de fallas, por lo que puede ayudarnos a analizarlo automáticamente.

Si estás en la fase de prueba y el evaluador ha instalado diferentes versiones (como las versiones alfa y beta), debes guardar los archivos binarios y los archivos de símbolos de las versiones correspondientes para que puedas registrar los registro de fallos cuando la aplicación falla. Realizar análisis. Para el registro de fallos generado en este escenario, solo necesita colocar el archivo .crash, el archivo .app y el archivo .dSYM en el mismo directorio, y luego arrastrar y soltar el archivo .crash en Xcode.

- Puede analizarlo en Registros del dispositivo en Biblioteca en el panel izquierdo de Ventana - Organizador.

Si queremos enviarlo para su lanzamiento, normalmente realizamos primero la limpieza, luego la compilación y finalmente lo empaquetamos a través del Producto -

Archivo. De esta manera, Xcode archivará los archivos binarios y de símbolos juntos, que se pueden explorar a través de Archivos en el Organizador.

3. Cómo analizar los registros de fallos

Antes de analizar un registro de fallos, sería fantástico que los desarrolladores comprendieran los tipos de errores comunes.

La generación de registros de fallos proviene de dos problemas: ser asesinado por violar las políticas de iOS y sus propios errores de código.

1. Estrategia de iOS

1.1 Fallo por falta de memoria

Como se mencionó anteriormente, la mayoría de los registros de fallos contienen información de llamada de pila de los subprocesos de ejecución, pero hay poca memoria. registro de fallos, primero echemos un vistazo a cómo se ve el registro de fallos con poca memoria.

Utilizamos dispositivos Xcode 5 e iOS

7 para simular un fallo de memoria baja y luego vemos el registro de fallos generado a través del Organizador. Podemos encontrar que tanto el proceso como el tipo son desconocidos:

p>

El contenido del registro específico es el siguiente:

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

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. La imagen de arriba es crashTypeDemo.

La tercera parte es una lista de procesos específicos, que describe el uso de memoria y el estado actual de cada proceso. En versiones anteriores, se podían ver las palabras "desechado" detrás de algunos procesos, lo que indicaba que estos procesos finalizaron porque usaron demasiada memoria, pero ahora vemos las palabras "vm-pageshortage".

Cuando iOS detecta que la memoria es demasiado baja, (el sistema VM) emitirá una notificación de advertencia de memoria baja e intentará recuperar algo de memoria; si la situación no mejora lo suficiente, iOS finalizará la aplicación en segundo plano; para recuperar más memoria, 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 razonablemente a las notificaciones de advertencia de poca memoria lanzadas por el sistema, liberar algunos datos almacenados en caché y objetos recreables y, al mismo tiempo, evitar problemas como pérdidas de memoria.

La falla de memoria baja está determinada por la política de iOS para finalizar la aplicación. También se basan en la política de iOS el tiempo de espera de vigilancia y la salida forzada del usuario.

1.2 Tiempo de espera de Watchdog

Desarrollador de iOS de Apple

En el sitio web de la Biblioteca, el documento QA1693 describe el mecanismo de Watchdog, incluidos sus escenarios de efectividad y rendimiento. Si nuestra aplicación no responde a tiempo a algunos eventos específicos de la interfaz de usuario (como inicio, suspensión, reanudación, finalización), Watchdog cerrará nuestra aplicación y generará un informe de respuesta fallida.

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

Si los eventos de UI específicos son relativamente abstractos, entonces si se describen directamente en el código, corresponden a varios métodos de UIApplicationDelegate (generado automáticamente por Xcode al crear un proyecto):

Entonces Cuando encuentre el registro de Watchdog, puede verificar si hay acciones serias que bloqueen la interfaz de usuario en los métodos anteriores.

El ejemplo dado por QA1693 es realizar solicitudes de red síncronas en el hilo principal. Si lo usamos en el entorno Wifi de la empresa, todo va bien, pero cuando la aplicación se lanza a una amplia gama de usuarios y se ejecuta en varios entornos de red, inevitablemente aparecerán una serie de informes de tiempo de espera de Watchdog.

Otro escenario donde pueden surgir problemas es la migración de la versión de la base de datos (también en el hilo principal) cuando la cantidad de datos es relativamente grande. Este también es un factor directo que me impulsó a escribir este resumen.

1.3 Salida forzada por el usuario

Cuando vea "Salida forzada por el usuario", lo primero que se le ocurrirá es hacer doble clic en el botón Inicio y luego cerrar la aplicación. Sin embargo, este escenario no generará un registro de fallos, porque después de hacer doble clic en el botón Inicio, todas las aplicaciones están en segundo plano y iOS puede cerrar el proceso en segundo plano en cualquier momento, por lo que no hay un registro de fallos en este escenario.

Otro escenario es que el usuario mantenga presionado el botón de encendido y el botón de Inicio al mismo tiempo para reiniciar el iPhone. Este escenario genera registros (verificados solo una vez) pero no es específico de la aplicación.

El escenario de "salida forzada del usuario" al que nos referimos aquí es una operación un poco más complicada: primero presione y mantenga presionado el botón de encendido hasta que aparezca la interfaz "deslizar para apagar", luego presione y mantenga presionado el botón Inicio. En este momento, la aplicación actual finalizará y se generará un registro de fallos del evento correspondiente.

Por lo general, los usuarios realizarían esta operación cuando la aplicación está bloqueada y la respuesta de iOS se ve afectada, pero esta operación parece muy avanzada, por lo que registros de fallas como este deberían ser relativamente raros.

2. Identificación de errores comunes

2.1 Códigos de excepción

La excepción en el registro de fallos de "Salida forzada por el usuario" arriba

Códigos son "0xdeadfa11" y el código de excepción en el registro de fallas de "Tiempo de espera de vigilancia" anterior es "0x8badf00d", estos son códigos de excepción únicos.

Según la documentación oficial, existen al menos los siguientes códigos de excepción específicos:

Código de error 0x8badf00d: tiempo de espera del perro guardián, que significa "comió comida mala".

Código de error 0xdeadfa11: el usuario se ve obligado a salir, lo que significa "caída muerta".

Código de error 0xbaaaaaad: El usuario presiona el botón Inicio y el botón Volumen para obtener el estado actual de la memoria, lo que no significa un bloqueo.

Código de error 0xbad22222: iOS eliminó la aplicación VoIP (¿porque era demasiado frecuente?).

Código de error 0xc00010ff: Se secó porque hacía demasiado calor, lo que significa "enfriar".

Código de error 0xdead10cc: debido a que todavía ocupaba recursos del sistema (como la libreta de direcciones) en segundo plano y se eliminó, significa "bloqueo muerto".

2.2 Tipos de excepción

Si observa nuestro correo electrónico con el informe de análisis de fallos, descubrirá que el tipo de error que se encuentra con más frecuencia es SEGV (segmentación).

Infracción de segmento ), lo que indica un funcionamiento inadecuado de la memoria, como el acceso a una dirección de memoria no autorizada.

Cuando recibimos la señal SIGSEGV, podemos considerar los siguientes aspectos:

Acceder a direcciones de memoria no válidas, como acceder a objetos Zombie.

Intentar solo lectura; área y escribir datos;

Eliminar puntero nulo;

Usar puntero no inicializado;

Desbordamiento de pila;

Además, hay otros señales comunes:

SIGABRT: cuando se recibe la señal de aborto, puede llamar a abort() él mismo o recibir una señal enviada desde el exterior

SIGBUS: error de bus. La diferencia con SIGSEGV es que SIGSEGV accede a una dirección no válida (por ejemplo, la memoria virtual no se puede asignar a la memoria física), mientras que SIGBUS accede a una dirección válida, pero el acceso al bus es anormal (como un problema de alineación de direcciones);

SIGILL: intento de ejecutar instrucciones ilegales, que pueden no ser reconocidas o no tener autoridad;

SIGFPE: error 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