日常的开发排查crash问题时多半是xcode在线调试，这样可以通过断点及时定位到问题；但是发布之后，或者断线测试时，就只能借助一些第三方的工具去统计crash信息，如：友盟，bugly等，下面以友盟统计为例子
正常的情况下是这样：
从3到11行可以清晰的看到堆栈调用的过程（TTLoveCar是工程名），其他都是系统库的调用线程，这样可以快速的定位到问题代码
然后是比较含蓄的情况：
我可以看到是数组越界的，第4行可以看到堆栈调用信息，但是并没有定位到具体的代码信息，这样定位问题就比较困难
甚至是这样的：
这特么都是啥？？？
既然这样，接下来当然是怎么定位到具体的问题代码：
首先介绍一个比较好用的dSYM解析工具，https://github.com/answer-huang/dSYMTools ，使用起来比较简单只需要dSYM文件和一个错误信息内存地址即可：
1、首先怎么获取dSYM路径文件
我们工程每次手动发布之前都会Archive，Archive完成之后会在/Users/<用户名>/Library/Developer/Xcode/Archives目录下生成xcachive文件，查看该文件的包内容即可获取dSYM文件
如果是自动打包的同学，可以通过修改脚本，在打包机器上储存xcachive文件，给大家参考一下，我们的大数据大神的脚本配置：
~/Desktop/build/TTLoveCar.${CI_PIPELINE_ID}_${CI_JOB_ID}是目标路径，自动打包完成后，该路径可以找到dSYM文件。
2、怎么获取错误信息内存地址
用第三方库的做崩溃信息统计的，以友盟为例，内存地址如下：
上面的每个地址对应一条线程信息，或者说时对应代码的一个方法函数
没有使用第三方统计的小伙帮咋弄呢，当然是通过xcode查看问题设备上的crash日志，手机连接到xcode，Window->Devices->选择设备->View Device Logs,可以看到所有的crash日志，只需要关注对应的crash log
关于上面的log日志分析，怎么找到错误信息的内存地址可以参考下面这篇文章 http://blog.csdn.net/diyagoanyhacker/article/details/41247411
3、使用上面的分析工具，定位问题
接下来以上面提到的数组越界的那个崩溃信息为例子，dSYM文件可以直接拖拽到窗口下，然后粘贴错误信息内存地址，利用工具分析结果如下：
可以看到定位到工程内MineViewController.m文件的第68行代码，ViewDidLoad方法下。接下来你就可以fixbug过程了
