我还以为你不会搜我呢~
前言
在app开发中，我坚信，总会有小伙伴会用到友盟统计的，我也是（废话）。但是在友盟的错误日志分析这块，小白用的话可能会有点小麻烦。最近有个小伙伴问我这点，于是我就整理一下，小白们参考，大神们绕行。
Crash日志统计
- 集成友盟SDK
这点我就不再过多的赘述了，详细看 友盟集成文档。 -
收集Crash日志
友盟上的文案
这点友盟上说的很清楚，错误统计这个接口默认是开启的，只要你成功集成，它就会自动统计日志。如果你省事，啥都不做，那你就错了，至少你得有这点代码意思一下：
#ifdef DEBUG
[MobClick setCrashReportEnabled:NO]; //关闭错误统计
#else
[MobClick setCrashReportEnabled:YES]; //打开错误统计
#endif
最后，查看的地方，如下图
当你看到错误日志的时候，别急着高兴，因为还有坑等着你呢。
Crash日志分析
当你查看日志，点击某一个查看详情的时候，你会看到：
乍一看，哦~原来是数组越界了啊，小case！仔细一想，卧槽，怎么改！在哪改！
不着急，且看：
日志分析方法（一）
用 umcrashtool 解析友盟错误日志，怎么用？
按照官方文档--2.2.3 错误分析工具的使用的方法，三步走。
注意：友盟上的.csv要用Numbers打开，不然可能会有乱码。
虽然只有三步，但是有的小伙伴可能走的并不是很悠然，不急，反手给你一个教学视频，有超清哦~
到这，如果你已经成功了，那么恭喜你，下面的你可以选择性的不看了，如果没有成功，咱继续
注：如果错误分析没有成功，请先确保对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。（对于每一个产品发布时archive操作会将dsym文件存放到~/Library/Developer/Xcode/Archives路径下，因此建议保留该路径下的文件，以便后续用工具分析错误。）
上面的是官方文档上的提示，我再补充一下。在你找到该路径情况下，你会看到
然后你要右键
在这个包里面你会看到有关自己app 的dsym文件，然后将对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。
注意：解析的时候要保证版本号一致。
日志分析方法（二）
用dsym解析工具
查看 xx.app 文件的 UUID，terminal 中输入命令 ：
dwarfdump --uuid xx.app/xx (xx代表你的项目名)
查看 xx.app.dSYM 文件的 UUID ，在 terminal 中输入命令：
dwarfdump --uuid xx.app.dSYM
crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。
工具呢，是一个大神写的，下载地址
在使用的时候是这个样子的
这种方法，解析有时会有一些出入，不过也能解决大部分问题。
日志分析方法（三）
个人觉得是最省事的方法。
在友盟上查看错误详情的时候，点击app后面对应的堆栈地址
打开terminal，把黑框内分号以前的完整复制，然后回车，再把分号以后的完整复制，然后回车，你就可以看到错误详情了。
- 优点：很快很方便。
- 缺点：不能像umcrashtool一样可以批量解析。
日志分析方法（四）
1、找到.dSYM文件，把xxx.app和.dSYM文件放到同一个目录，推荐把该目录放在桌面。
xxx.app在分析方法（一）图“显示包内容”操作之后，在下图中
2、cd到这个目录。
3、执行下面的代码
xcrun atos -arch arm64 -o 'xxx.app/xxx' 0x0004af6f
arm64是CPU架构，有的时候是armv7,这个在友盟crash最下面有，xxx是app的bundle名，0x0004af6f是错误的内存地址。
日志分析方法（五）更新于2020-08-20
最近的几个版本的包里面的.dsym的UUID和crash的UUID老是不一致，导致解析的有问题。为啥不一致？我给友盟的工作人员发了邮件，人家说，我在打包之后，没有立刻保存dsym文件，修改了代码后dsym文件的UUID会变化。用来用去还是觉得命令行最舒服。下面的是命令行的具体的用法：
- 把错误版本的dsym文件（这个文件一定要是打包后就立刻保存下来的）放到某个文件夹，cd到这个文件夹。
-
dwarfdump --lookup 0xb86f7 -arch arm64 xxx.app.dSYM
同样，0xb86f7是堆栈地址，arm64是CPU架构，xxx是Boundle名。
后记
有啥问题，可以留言，互相交流，共同进步。
