prefacio
Para la mayoría de los usuarios de iOS, el problema más grave que encuentran es el bloqueo en línea, porque para los usuarios, la peor experiencia es el bloqueo repentino al usar la aplicación, y lo que es peor que esto es abrir e intentar nuevamente y aún así colapsar. Si no se puede usar normalmente o la experiencia del usuario es extremadamente mala, la aplicación no es insustituible y el usuario puede optar por desinstalarla. Por lo tanto, mantener una tasa de fallas baja es muy necesario para el desarrollo de iOS.
La generación y clasificación de accidentes.
El bloqueo es un comportamiento de protección del sistema. Generalmente se divide en dos tipos. Uno son los bloqueos anormales del código, como una matriz fuera de los límites y un mal acceso a la memoria, y el otro son los problemas de rendimiento. El más común es OOM ( sin memoria). ¿Por qué está tan clasificado, porque los registros generados por las excepciones del código pertenecen al nivel de la aplicación, que se puede obtener a través del código, se puede cargar en su propio servidor y luego analizar y procesar, mientras que el nivel del sistema es el sistema (Jestems mecanismo) que elimina la aplicación. El registro de errores se encuentra en el nivel del sistema y los usuarios pueden encontrarlo en Configuración->Privacidad->Análisis->Análisis y datos, pero los desarrolladores no tienen forma de obtenerlo.
excepción de código
La mayoría de estos bloqueos son bastante fáciles de solucionar. Lo más problemático en el proceso de solución debe ser el código de posicionamiento. Si la herramienta de informes de fallas de terceros (Bugle) está conectada y el archivo dsym está cargado, nos ayudará a analizar la pila. Además, Xcode también viene con una herramienta para encontrar errores.
Archivo DSYM
El archivo dsym es un archivo de tabla de símbolos, que es una tabla de asignación de direcciones de memoria y nombres de funciones, nombres de archivos y números de línea. Si generarlo se puede configurar en la configuración del proyecto.
Si desea compilar el proyecto más rápido durante la depuración, puede cancelar la generación del archivo dsym. En el modo de depuración, el directorio generado está en el mismo directorio que el Producto de la aplicación y el archivo dsym tiene uuid, que se puede ver con la ayuda del comando dwarfdump.
dwarfdump --uuid xxx.app.dSYM
Restaurar una pila usando un archivo DSYM
Si el proyecto utiliza algunas bibliotecas de código abierto de terceros de KSCrash para recopilar registros de fallas y cargarlos en su propio servidor, debe analizarse por sí mismo. O el usuario encuentra un bloqueo y envía el registro de bloqueo en el teléfono móvil al desarrollador. También puede ser analizado por dwarfdump.
dwarfdump xxx.app.dSYM --lookup <需要解析的相对地址>
Antes de analizar, asegúrese de confirmar que el uuid de la imagen binaria del programa en el registro de fallas es consistente con el uuid en el archivo dsym.
日志捕获的堆栈一般有4列信息，库名称、远行时堆栈地址、运行时起始地址、偏移地址。
有用的信息只有+号后面的。将其转化为二进制，然后再加上符号表 TEXT 段的起始地址，就可以解析了，TEXT 段的起始地址使用otool可以获取：
otool -l xxx.app.dSYM/Contents/Resources/DWARF/<项目名> | grep __TEXT -C 5
所以得到相对地址就是0x0000000100000000 + 0x000FDBB54（16628564）= 0x100FDBB54，使用dwarfdump尝试还原：
如图所示，已经还原到的具体的方法。在使用KSCrash的时候，KSCrash已经帮我们把偏移地址计算好了。
可以看到日志里面都0x100fdbb54就是，之前计算的。
系统级的crash
除了应用代码的crash，还有一些系统讲app杀死的情况，如果app在前台，这时候这种表现就和闪退一样。
OOM
OS、iPadOS、watchOS和tvOS都有一个虚拟内存系统，当操作系统遇到内存压力时，它依赖于所有应用程序释放内存，此时可用内存很低，系统无法满足所有运行的应用程序的需求。在内存压力下，应用程序会在收到内存不足的通知后释放内存。如果所有正在运行的应用程序释放足够的总内存来缓解内存压力，你的应用程序将继续运行。但是，如果由于应用程序没有释放足够的内存而导致内存压力继续存在，系统会通过终止应用程序来回收内存来释放内存。这是一个jetsam事件，系统会创建一个jetsam事件报告，其中包含为什么选择抛弃应用程序的信息。
Jetsam事件报告不同于崩溃报告，因为它们包含了设备上所有应用程序和系统进程的总体内存使用情况，它们是JSON格式的，并且它们不包含应用程序中任何线程的回溯。如果系统由于内存压力而抛弃了你的应用程序，而应用程序是可见的，它会看起来像你的应用程序崩溃了。使用jetsam事件报告来识别你的应用在jetsam事件中的角色，即使你的应用没有被抛弃。
其他
Recientemente, la aplicación del lado B de la compañía tiene comentarios de los usuarios que fallan, pero en la plataforma de estadísticas de fallas, no se encuentran registros en sus dispositivos móviles. Ni sistema ni aplicación. Este tipo de búsqueda de fallas requiere la intervención de los estudiantes de prueba, intentar reproducirlo tanto como sea posible y luego ubicar y rastrear el problema.