友盟Crash分析-有关dSYM UUID与app Archives打包不一致的解决方案

有关友盟Crash的介绍文章已经不少了，在这里就不一一介绍了，你们能够自行百度，这边文章主要解决dSYM UUID与app Archives打包不一致的解决方案。

1、如何找到本身打包的 Archives文件

/Users/xxx/Library/Developer/Xcode/Archives/ xxx:为mac电脑的用户主目录

如上图所示找到你对应app打包的日期，展开文件夹就能找到对应的Archives文件，继续打开 Archives-显示包内容找到对应的 dSYM文件

如上图所示，看到了3个dSYM文件，前面2个是第三方崩溃日志所记录的dSYM文件，最后一个是苹果自带的崩溃日志所记录的dSYM文件，我们能够在Xcode中Crashes找到对应的崩溃信息，在这我们就不在累赘了。

2、dSYM文件分析工具

用过的都说好，使用方便简单（相对于命令来讲） 传送门：pan.baidu.com/s/11jJxPgrT… 提取码：n45g

压缩以后，看到Objective-C的文件夹请点开，看到能够运行的项目（DSYMTools.xcodeproj），点开运行便可，一个mac的项目。 运行以后是这样子的：

3、结合友盟后台的Crash与我们的dSYM定位具体的问题

关于如何在友盟后台找到相对应的crash，你们自行解决哈！ 笔者认为你们是知道的因此过程省略，直接上图：

笔者找到了一个友盟后台crash崩溃的截图，崩溃的缘由：数据下表越界，你们注意下红色方框的内容，前面2个小方框是崩溃的内存地址（经过该地址定位到具体的代码），最后的方框是sSYM UUID，你们仔细看好了，和下图的对比：

ps：CPU的类型选择根据友盟崩溃的crash显示CPU Type 你们能够参照上图，有关CPU Type的描述。

是否是瞬间懵逼了。。。本来就绪好的一切，竟然这个2个UUID不同，竟然不同的话，name若是我把崩溃的内存地址放到SDYMTools去分析，确定得不到结果啊，咱去试一试：

我勒个去，竟然有可能错误的地方，还指向一个类型的某一行代码，既然这样那就去看看呗，你们还记得以前我们说过这个崩溃的缘由是数组下标越界，根据上图的图示，去对应的代码行去找，发现这个地方竟然没有数组，是怎么越的界呢，这是跨界吧。。。 瞬间整我的很差了！

可是仔细分析下来：前面我们已经说过了，主要的缘由在于：友盟Crash的dSYM UUID和App Archives的 UUID不一致，工具默认帮助咱们选择了我们本地电脑打包的全部的Archives的，而这个Archives的文件真的就是对应的友盟Crash的UUID吗？ 答案是否认的，因此我们还须要去第二张图中去找，你们发现了没有？ 这个文件和友盟Crash的才是如出一辙的UUID啊！

好吧说了这么多废话，解决方案很简单了：将上图红色圈起来的文件，拷贝一份，随便修改了个名字，直接拖到DSYMTools中，再贴上崩溃的地址，就能够分析定位到具体的代码了，很少说，直接上图：

结语

哎呀第一次写，感受思路比较乱啊，若是有不明白的地方欢迎私聊！ 请你们谅解啦！