如果你的项目中已经集成了友盟的统计日志分析，那么友盟会把你项目中没有用 try catch 捕获的异常进行上传，我们可以再友盟官网的“我的产品->错误分析->错误列表”去查看当前已经统计到的crash详情。
第一步：从crash日志详情中获取当前版本的dSYM UUID
在crash详情中可以查看到当前版本的dSYM UUID,如下图
第二步：获取对应编译文件.xcarchive
这个文件在哪呢？打开XCode->菜单Window->Organizer，在编译成功的文件上右键，就能打开了。 （当然使用该软件必须保证.xcarchive的uuid和已发布的App的uuid一致）
我一般的做法是，发布成功后，把这个文件.xcarchive直接提交到代码版本库对应的版本分支里，这样就不会搞丢了。
第三步：使用可视化工具dSYM定位crash位置
当我们打开友盟应用统计分析后，打开错误列表，只能看到一些这不全面的堆栈错误信息，这时候，可视化工具:dSYM便可以很方便的帮我们找到错误的地方
dSYM文件下载地址：http://pan.baidu.com/s/1c0pwD2K
打开dSYM，把编译文件.xcarchive文件拖进去（该文件名不能携带空格和汉字等符号）,之后把友盟中错误的堆栈内存地址复制进去，点分析即可，如下图：
那么问题来了，如果是我们自己记录的日志信息，我们收集到的内存地址并不是像友盟一样为我们转换好的，我们需要自己去转换。
随便举个数组越界例子，错误信息如下
0 CoreFoundation 0x2fc49f9b <redacted> + 154
1 libobjc.A.dylib 0x3a3faccf objc_exception_throw + 38
2 CoreFoundation 0x2fb83a3b <redacted> + 418
3 CoreFoundation 0x2fb8d341 <redacted> + 44
4 Test 0x0009cf4f Test + 163663
这个163663便是我们需要的，转换方法如下：将163663由10进制转换为16进制，即 0x27F4F, 然后加上0x4000，得到0x2bf4f，这个便是转换后的内存地址。