¿Cómo obtiene el código información del proceso cuando falla el desarrollo de iOS?
Cuando una aplicación de iOS falla, el sistema crea un registro de fallos y lo guarda en el dispositivo. Este registro de fallos registra información cuando la aplicación falla, y generalmente incluye información de llamada de pila de cada subproceso de ejecución (excepto los registros de flashback con poca memoria), lo cual es muy útil para que los desarrolladores localicen problemas.
Si el dispositivo está cerca, puede conectarlo, abrir Xcode-Window-Organizer y seleccionar el registro del dispositivo en el panel izquierdo (puede seleccionar el registro del dispositivo de un dispositivo específico, o puede seleccione el registro de dispositivos de todos los dispositivos en la biblioteca) y vea los registros de fallas en el dispositivo en orden cronológico. 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 y el usuario la instaló, el desarrollador puede obtener el registro de fallas del usuario a través de iTunes Connect (Administrar su aplicación - Ver detalles - Informe de fallas). Pero esto no es 100% efectivo y la mayoría de los desarrolladores no confían en él porque requiere que el dispositivo del usuario acepte cargar información relevante. Para obtener más información, consulte Resumen de iOS: Proporcionar información de diagnóstico y uso para Apple.
Teniendo en cuenta que no todos los usuarios de iPhone pueden enviar automáticamente informes de diagnóstico (registros de fallos) y, para algunos registros de fallos enviados a Apple, los desarrolladores deben extraerlos manualmente y luego buscar los archivos de símbolos correspondientes. - Esto es algo muy tedioso de hacer. Por lo tanto, en el desarrollo de proyectos reales, generalmente nos conectamos a las herramientas de recopilación de fallas existentes (Referencia 1, Referencia 2) o escribimos una para la recopilación, el análisis y el resumen estadístico automático.
En segundo lugar, cómo analizar el registro de fallos
Al obtener el registro de fallos, debemos asignar la información original, como la dirección hexadecimal mostrada inicialmente, al nombre del método y al código en el Números de línea a nivel de código fuente para que los desarrolladores puedan leerlos. Este proceso se llama resolución de símbolos. Para analizar simbólicamente los registros de fallos con éxito, necesitamos los archivos binarios y de símbolos (.dSYM) de la aplicación correspondiente.
Si está 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 el evaluador instaló diferentes versiones durante la fase de prueba (como las versiones alfa y beta), entonces los archivos binarios y los archivos de símbolos de las versiones correspondientes deben guardarse para analizar el registro de fallas cuando el la aplicación falla. Para el registro de fallos generado en este escenario, simplemente cambie. archivo de bloqueo. archivos de aplicación y. dSYM, luego arrástrelo y suéltelo. Inserte el archivo en el registro del dispositivo en Bibliotecas en el panel izquierdo de Xcode-Window-Organizer y podrá analizarlo.
Si queremos enviar una versión, generalmente la limpiamos primero, luego la compilamos y finalmente la empaquetamos a través de Product-Archive. De esta manera, Xcode archivará los archivos binarios y los archivos de símbolos juntos, y se podrán explorar en el archivo en el Organizador.
Aquí analizamos cómo analizar los registros de fallos: /questions/1460892/symboling-iPhone-APP-crash-reports.
3. Cómo analizar los registros de fallos
Antes de analizar los registros de fallos, sería mejor si los desarrolladores comprendieran los tipos de errores comunes.
El registro de fallos proviene de dos problemas: morir en violación de las políticas de iOS y su propio error de código.
1. Estrategia de iOS
1.1 Flashback con poca memoria
Como se mencionó anteriormente, además de los registros de flashback con poca memoria, la mayoría de los registros de fallas contienen información de llamada de la pila de subprocesos de ejecución. . Primero echemos un vistazo a cómo se ve un registro de flashback con poca memoria.
Utilizamos dispositivos Xcode 5 e iOS 7 para simular un flashback con poca memoria y luego vemos el registro de fallas generado a través del Organizador. Podemos encontrar que el proceso y el tipo son desconocidos:
Registro específico El contenido es el siguiente:
La primera parte es información sobre fallas, incluida la identificación, información de software y hardware e información de tiempo.
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 es crashTypeDemo en la imagen de arriba.
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, podía ver las palabras "abandonado" después de algunos procesos, lo que indicaba que estos procesos finalizaron debido al uso excesivo de memoria, pero ahora vemos las palabras "falta de páginas de VM".
Cuando iOS detecta memoria insuficiente, (el sistema VM) emitirá una notificación de advertencia de falta de memoria e intentará recuperar algo de memoria; si la situación no mejora lo suficiente, iOS finalizará la aplicación en segundo plano; recuperar más memoria. Finalmente, si la memoria aún es insuficiente, las aplicaciones en ejecución pueden 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 recreados, y evitar problemas como pérdidas de memoria.
Los flashbacks con poca memoria están determinados por la política de iOS de finalizar la aplicación y también se basan en las políticas de iOS, los tiempos de espera de vigilancia y los cierres forzados del usuario.
1.2 Tiempo de espera de vigilancia
En el sitio web de la biblioteca para desarrolladores de iOS de Apple, el documento QA1693 describe el mecanismo de vigilancia, incluidos escenarios efectivos y rendimiento. Si nuestra aplicación no responde a ciertos eventos de la interfaz de usuario (como inicio, pausa, reanudación y finalización) de manera oportuna, Watchdog finalizará nuestra aplicación y generará el informe de falla correspondiente.
Lo interesante de este informe de fallo es el código de excepción: "0x8badf00d", que significa "comer comida en mal estado".
Si un evento de UI específico es abstracto, entonces si se describe directamente en el código, corresponde a varios métodos de UIApplicationDelegate (generado automáticamente por Xcode al crear el proyecto):
Entonces Cuando encuentre el registro de vigilancia, puede verificar si el método anterior tiene acciones importantes que bloquean la interfaz de usuario.
El ejemplo dado por QA1693 es una solicitud de red síncrona en el hilo principal. Si lo usamos en el entorno Wifi de la empresa, todo irá bien, pero cuando la aplicación se lance a una amplia gama de usuarios y se ejecute en varios entornos de red, inevitablemente se producirán informes de tiempo de espera de vigilancia.
Otro posible escenario problemático 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 es también el factor directo que me impulsó a escribir este resumen.
1.3 El usuario fuerza la salida
Tan pronto como vea "El usuario fuerza la salida", lo primero que se le ocurrirá es hacer doble clic en el botón Inicio y luego cerrar la aplicación. Sin embargo, no se generará ningún registro de fallos en este escenario, 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 ningún registro de fallos en este escenario.
Otro escenario es que el usuario presione el botón de encendido y el botón de inicio al mismo tiempo para reiniciar el iPhone. Esta situación genera un registro (verificado solo una vez), pero no es específico de una aplicación en particular.
El escenario "el usuario fuerza el cierre" aquí es una operación un poco más complicada: 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 eventos de fallas correspondiente.
Normalmente, los usuarios sólo deberían hacer esto si la aplicación se congela y la respuesta de iOS se ve afectada, pero esta operación parece demasiado avanzada, por lo que debería haber muy pocos registros de fallos.
2. Identificación de errores comunes
2.1 Código de excepción
El código de excepción en el registro de fallos de "Salida forzada por el usuario" anterior es "0xdeadfa11", y el arriba "consulte El código de excepción en el registro de fallos de "Watchdog Timeout" es "0x8badf00d", que es el único código de excepción.
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 "comer comida en mal estado".
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 la tecla Inicio y la tecla 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?).
0xc00010ff Código de error: Matado por estar demasiado caliente, lo que significa "enfriarse".
Código de error 0xdead10cc: debido a que todavía ocupaba recursos del sistema (como la libreta de direcciones) en segundo plano, se eliminó, lo que significa "punto muerto".
2.2 Tipos de excepción
Al observar nuestros correos electrónicos de informes de análisis de fallas, encontraremos que el tipo de error más común es SEGV (violación de segmentación), que indica un funcionamiento incorrecto de la memoria, como el acceso sin acceso. Dirección de memoria autorizada.
Cuando recibimos la señal SIGSEGV, podemos considerar los siguientes aspectos:
Acceder a direcciones de memoria no válidas, como acceder a objetos zombies
Intentar transferir datos; Escribir en un área de solo lectura;
Desreferenciar un puntero nulo;
Usar un puntero no inicializado;
Desbordamiento de pila;
En Además, hay otras señales comunes:
SIGABRT: después de recibir la señal de aborto, puede llamar a Abort() usted mismo o puede recibir señales desde el exterior
SIGBUS: Bus; error. 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 la alineación de direcciones);
SIGILL: intento de ejecutar instrucciones ilegales, que pueden no ser reconocidas o no tener permiso;
SIGFPE: error de punto flotante, problemas relacionados con cálculos matemáticos (puede no limitarse a cálculos de punto flotante), como 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 comunes se deben básicamente a errores de código, como matrices fuera de límites y matrices vacías, seguridad de subprocesos múltiples, acceso a punteros salvajes, envío de selectores no implementados, etc. Hay otras preguntas frecuentes si se introducen los datos básicos, pero ese es otro tema.
Al encontrar estos errores, hay explicaciones claras de los motivos del error, como "índice de matriz vacía 0 fuera de límites", etc. Algo que necesita un poco de atención es el subproceso múltiple. Cuando no pueda encontrar una solución por un tiempo, también podría considerar el uso de subprocesos múltiples.