iOS 第三方dSYM定位BUG

iOS 如何找到或生成 .dSYM 文件
系统崩溃日志或者手机奔溃日志

第三方日志包含：友盟日志，talkingdata日志....

我这里以 talkingdata日志 举例：

reason: -[NSTaggedPointerString stringValue]: unrecognized selector sent to instance 0xa000038363133355
callStackSymbols: (
    0   CoreFoundation                      0x000000018f2caff0 <redacted> + 148
    1   libobjc.A.dylib                     0x000000018dd2c538 objc_exception_throw + 56
    2   CoreFoundation                      0x000000018f2d1ef4 <redacted> + 0
    3   CoreFoundation                      0x000000018f2cef4c <redacted> + 916
    4   CoreFoundation                      0x000000018f1cad2c _CF_forwarding_prep_0 + 92
    5   XFKD                                0x000000010011e614 XFKD + 1074708 // 崩溃地址
    6   XFKD                                0x000000010011ed64 XFKD + 1076580 // 崩溃地址
    7   XFKD                                0x000000010011de2c XFKD + 1072684 // 崩溃地址
    8   libdispatch.dylib                   0x000000018e1829e0 <redacted> + 24
    9   libdispatch.dylib                   0x000000018e1829a0 <redacted> + 16
    10  libdispatch.dylib                   0x000000018e1910d4 <redacted> + 644
    11  libdispatch.dylib                   0x000000018e192a50 <redacted> + 540
    12  libdispatch.dylib                   0x000000018e1927d0 <redacted> + 124
    13  libsystem_pthread.dylib             0x000000018e38b1d0 _pthread_wqthread + 1096
    14  libsystem_pthread.dylib             0x000000018e38ad7c start_wqthread + 4
)

Process name: XFKD // App包名
dSYM UUID: B2707119-9ED6-35CB-B3B4-A9902B5CE8C0 // 当前 dSYM UUID
Architecture: arm64 // 当前的手机环境
Start Address: 0x100018000 // 起始地址
Slide Address: 0x18000 // 偏移地址

我们得到这个之后，那么久需要去找对应的. xcarchive文件，也就是你发布的时候留下的包，这个包的位置就在 Xcode->Window->Organizer，到了 Organizer 之后找到你对应的版本，也就是你这个BUG出现在哪个版本的包里，找到它之后 Show In Finder, 进入 . xcarchive 文件，在继续右键 显示包内容，找到：

0A020789-06B3-4E49-972F-B3E2B8F338D3.png

如果，你不能确定这个BUG是这个包产生的，那么可以通过比较 dSYM UUID 来确定：

BUG的 dSYM UUID ：B2707119-9ED6-35CB-B3B4-A9902B5CE8C0 
BUG的 Architecture ：arm64

我们可以将 xxxx.app.dSYM 文件拷贝出来放到一个新建的文件夹里面，这样方便我们操作。打开命令行工具 cd 到这个存放了 xxxx.app.dSYM 文件目录下，
比方我创建了一个 Test 文件夹存放 xxxx.app.dSYM， 那么我只需要 cd 到 Test 文件里面即可，好了，下一步我们打印这个 xxxx.app.dSYM 的 dSYM UUID，看看是否跟BUG的 dSYM UUID 是否一致

dwarfdump --uuid /Test/XFKD.app.dSYM

这行命令之后就会输入

UUID: F83F652E-4525-3052-A2E3-A74E7EC32E58 (armv7)
UUID: B2707119-9ED6-35CB-B3B4-A9902B5CE8C0 (arm64)

我们只需要比较BUG的 arm64 状态下的 UUID，那么它们是一致的。那么我们下面就开始来定位日志闪退位置。

atos -o XFKD.app.dSYM/Contents/Resources/DWARF/XFKD -arch arm64 -l 0x100018000 0x000000010011e614

其中 0x100018000：起始地址 0x000000010011e614：崩溃地址
崩溃地址一般为 崩溃信息中首行与你的App包名相关的地址 就是该例子中首行与 AppName 相关的地址信息（也就是崩溃信息中带有 XFKD 的567行）。
最后输出：

closure #1 in static KTTLog.insert(_:_:_:_:_:_:_:_:_:) (in XFKD) (KTTLog+Version.swift:30)

就是说crash的位置在 KTTLog+Version 文件中的 第30行。

最后我也还告诉一下大家在使用第三方工具定位日志的时候 dSYMTools 这个工具，不知道是不是我不会用还是使用有问题，我这边发现 dSYMTools 自己扫描出来的 dSYM UUID 始终无法跟正确的 xxxx.app.dSYM 文件里面或者是BUG的 dSYM UUID 对应上，也就是说工具上的 dSYM UUID 跟 文件或者BUG的 dSYM UUID 对应不上，就导致定位不了，很郁闷，不知道是不是我使用有问题，如果有会使用 dSYMTools 请告诉我下原因。