1、前言
在iOS开发过程的时候,在遇到报错的时候抛出的报错异常,需要快速定位到具体报错位置,有时候通过常规的代码排查方法可以解决,但是有些时候通过常规的方式不能很好的定位到报错位置,尤其是遇到一些隐性的报错信息,不能快速的定位到报错原因信息,这样就要借助第三方的错误信息分析来解决了。
那么本文就来分享一下在iOS开发过程中借助第三方工具来分析解决报错异常的处理方法,本文案例使用的友盟U-APM来做使用案例。通过在项目中集成友盟分析工具,使用友盟U-APM来分析报错异常信息,就能在友盟给出的错误信息中,很方便的找出客户端异常的信息,比如很多像数组越界却只给出了 *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39]' 这类错误信息,这种很难定位具体报错位置的信息,如下图所示:
![](https://img-blog.csdnimg.cn/img_convert/19c45a109b3d32a568e0bb2c957286bb.webp?x-oss-process=image/format,png)
遇到这种问题的话,如果通过 objectAtIndex 去检索错误的地方,那将会是一个巨大的工作量,那么怎么办才能减轻工作量呢,那就是下面要介绍的情况了。
2、dSYM 文件
Xcode编译项目后,我们会看到一个同名的dSYM文件,dSYM是保存 16 进制函数地址映射信息的中转文件,我们调试的symbols都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的dSYM文件,位于 /Users/<电脑用户名>/Library/Developer/Xcode/Archives目录下,对于每一个发布版本我们都很有必要保存对应的Archives 文件 。
3、dSYM 文件的作用
当我们应用程序release 模式打包或上线后,不会像在Xcode中那样直观的看到用崩溃的错误,这个时候就需要分析 crash report 文件了,iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址,通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件,这样就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。但是前提是我们需要有软件版本对应的 dSYM 文件,这也是为什么很有必要保存每个发布版本的 Archives 文件了。
4、如何把文件一一对应
每一个 xxx.app 和 xxx.app.dSYM 文件都有对应的 UUID,crash文件也有自己的UUID,只要这三个文件的UUID一致,我们就可以通过它们解析出正确的错误函数信息了。
1.查看 xxx.app 文件的 UUID,terminal 中输入命令 :dwarfdump --uuid xxx.app/xxx (xxx是你的项目名称)
2.查看 xxx.app.dSYM 文件的 UUID ,在terminal中输入命令:dwarfdump --uuid xxx.app.dSYM
3.crash 文件内第一行 Incident Identifier 就是该crash文件的 UUID。