项目开发过程中，使用了友盟统计，就能在友盟给出的错误信息统计中，能比较方便的找出客户端异常的信息，但是很多像数组越界却只给出了 *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39]' 这类错误信息，如下图所示：
遇到这种问题的话，如果通过 objectAtIndex 去检索错误的地方，那将会是一个巨大的工作量，那么怎么办才能减轻工作量呢，那就是下面要介绍的情况了。
一、dSYM 文件
Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件，位于 /Users/<电脑用户名>/Library/Developer/Xcode/Archives 目录下，对于每一个发布版本我们都很有必要保存对应的 Archives 文件 。
二、dSYM 文件的作用
当我们应用程序release 模式打包或上线后，不会像在Xcode中那样直观的看到用崩溃的错误，这个时候就需要分析 crash report 文件了，iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址，通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件，这样就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。但是前提是我们需要有软件版本对应的 dSYM 文件，这也是为什么很有必要保存每个发布版本的 Archives 文件了。
三、如何把文件一一对应
每一个 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。
四、dSYM文件分析工具的使用
1.将打包发布程序时的xcarchive文件，拖入到软件窗口内的任意位置(这里支持多个文件同时拖入，特别注意：文件名不要包含空格)
2.选中任意一个版本的xcarchive文件，右边会列出该xcarchive文件支持的CPU类型，选中错误对应的CPU类型。
3.对比错误给出的UUID和工具界面中给出的UUID是否一致。
4.将错误地址输入工具的文本框中，点击分析。
尤其是上架应用的时候，有些时候苹果反馈的信息里面也会给具体的错误日志，你可以通过dSYM工具直接可以找到具体报错位置，百试百灵。如果你觉得我写的内容对你有帮助请点赞，如果想和我更进一步交流探讨，也可以关注我的微信公众号，那里面同样有更多使用的方法技巧等着你！
