有关友盟Crash的介绍文章已经很多了，在这里就不一一介绍了，大家可以自行百度，这边文章主要解决dSYM UUID与app Archives打包不一致的解决方案。
一、如何找到自己打包的 Archives文件
/Users/xxx/Library/Developer/Xcode/Archives/ xxx:为mac电脑的用户主目录
如上图所示，看到了3个dSYM文件，前面2个是第三方崩溃日志所记录的dSYM文件，最后一个是苹果自带的崩溃日志所记录的dSYM文件，咱们可以在Xcode中Crashes找到对应的崩溃信息，在这咱们就不在累赘了。
二、dSYM文件分析工具
用过的都说好，使用方便简单（相对于命令来说） 传送门：pan.baidu.com/s/11jJxPgrT… 提取码：n45g
压缩之后，看到Objective-C的文件夹请点开，看到可以运行的项目（DSYMTools.xcodeproj），点开运行即可，一个mac的项目。 运行之后是这样子的：
三、结合友盟后台的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中，再贴上崩溃的地址，就可以分析定位到具体的代码了，不多说，直接上图：
结语
哎呀第一次写，感觉思路比较乱啊，如果有不明白的地方欢迎私聊！ 请大家谅解啦！
