Crash Symbolicate Methods

1. .symbolicatecrash .app .dSYM .crash 放在一个文件夹 设置好DEVELOPER_DIR = “ xxx" 然后terminal执行 ./symbolicatecrash Teenker.crash Teenker.dSYM > cc.crash 。
2. $ dwarfdump --uuid XX.app.dSYM
   $ dwarfdump --uuid XX.app/XX 分别得到uuid。
   2.1 设置 export DEVELOPER_DIR=“Applications/Xcode7.2.app/Contents/Developer"
3. xcrun atos -o executable -arch architecture -l loadAddress address ...

说明：
loadAddress 表示函数的动态加载地址，对应崩溃地址堆栈中 + 号前面的地址，即0x000ef000
address 表示运行时地址、对应崩溃地址堆栈中第一个地址，即0x0010143b
实际上，崩溃地址堆栈中+号前后的地址相加即是运行时地址，即0x000ef000 + 74808 = 0x0010143b
例如：
xcrun atos -o Teenker.dSYM/Contents/Resources/DWARF/Teenker -arch arm64 -l 0x100054000 0x10010ee30
警告： 不要写xcrun，第一次写，出来了，后来一直 就没出来了，直接用atos很好。

5. (很叼的一个方法，但是没有成功）
   6.(很完整详细的一个方法）
6. [stackOverFlow]
   7.1 ()
   7.2 ()
7. [(高级设置可以在编译后自动上传）。
   8.1
   问题：
8. 第三方是如何根据崩溃信息得到UUID的。
9. 官方格式的crash，如何得到UUID，进而找到匹配的dSYM文件。
10. 对比：
    9.1 symbolicateCrash ：
    1. 只能使用官方格式
    2. 一对一
    3. 可定位到具体的代码行号
       9.2 atos:
    4. 只要dSYM和slide address 以及crash address
    5. 可批量处理（？？）
    6. 可定位到具体的代码行号
    7. 可以一对多，针对一个load address 可以一次输入crash address，前提是针对相同的uuid，如果是不同的uuid还是要一次次处理的，其实和上面的方法一样。（现在的理解，是否可以使用批处理来实现多个处理）
       9.3 umcrashtool：
    8. dSYM文件在xcode对应的位置
    9. 下载csv文件和umcrashTool
    10. 只能定位到函数的行号。
    11. 应该是并不是每次的crash都有上传记录。