dSYM 檔案
什麼是 dSYM 檔案
Xcode編譯項目後，我們會看到一個同名的 dSYM 檔案，dSYM 是儲存 16 進制函數位址映射資訊的中轉檔案，我們調試的 symbols 都會包含在這個檔案中，
并且每次編譯項目的時候都會生成一個新的 dSYM 檔案，位于 /Users/beyond/Library/Developer/Xcode/Archives 目錄下，
對于每一個釋出版本我們都很有必要儲存對應的 Archives 檔案 。
dSYM 檔案有什麼作用
當我們軟體 release 模式打包或上線後，不會像我們在 Xcode 中那樣直覺的看到用崩潰的錯誤，這個時候我們就需要分析 crash report 檔案了，
iOS 裝置中會有日志檔案儲存我們每個應用出錯的函數記憶體位址，
通過 Xcode 的 Organizer 可以将 iOS 裝置中的 DeviceLog 導出成 crash 檔案，這個時候我們就可以通過出錯的函數位址去查詢 dSYM 檔案中程式對應的函數名和檔案名。
大前提是我們需要有軟體版本對應的 dSYM 檔案，這也是為什麼我們很有必要儲存每個釋出版本的 Archives 檔案了。
如何将檔案一一對應
每一個 xx.app 和 xx.app.dSYM 檔案都有對應的 UUID，crash 檔案也有自己的 UUID，隻要這三個檔案的 UUID 一緻，我們就可以通過他們解析出正确的錯誤函數資訊了。
1.檢視 xx.app 檔案的 UUID，terminal 中輸入指令 ：
dwarfdump --uuid xx.app/xx (xx代表你的項目名)
2.檢視 xx.app.dSYM 檔案的 UUID ，在 terminal 中輸入指令：
dwarfdump --uuid xx.app.dSYM
3.crash 檔案内第一行 Incident Identifier 就是該 crash 檔案的 UUID。
要分析崩潰日志，首先需要保留釋出時的編譯出來的.xcarchive檔案。這個檔案包含了.DSYM檔案。
我一般的做法是，釋出成功後，把這個檔案.xcarchive直接送出到代碼版本庫對應的版本分支裡，這樣就不會搞丢了。
這個檔案在哪呢？打開XCode->菜單Window->Organizer，在編譯成功的檔案上右鍵，就能打開了。
兩種比較麻煩的方法。
第一種方法：
使用dwarfdump指令
dwarfdump --uuid xx.app.dSYM 用來得到app的UUID。
dwarfdump --lookup 0x100445290 -arch armv7 xx.app.dSYM 使錯誤的日志能看懂，把相應的記憶體位址對應到正确的地方。
如果一開始dwarfdump指令不能用的話，要先裝Command Line Tools,這個在設定裡面能下載下傳（cmd+“，”打開設定）。另外還必須在進入.DSYM所在檔案夾。
使用dwarfdump需要安裝Command Line Tools,XCode裡設定下載下傳。而且需要進入.DSYM所在檔案夾裡進行操作。
第二種方法：
使用xcrun atos指令
指令：atos -o YourApp.app.dSYM/Contents/Resources/DWARF/YourApp 0x出錯位址
Application received signal SIGSEGV
(null)
(
0 CoreFoundation 0x00000001848270b8+ 160
1 libobjc.A.dylib 0x00000001907a5d78 objc_exception_throw + 60
2 CoreFoundation 0x0000000184826fdc+ 0
3 JZH 0x1001d12f8 JZH + 1905400
4 libsystem_platform.dylib 0x0000000190f07b0c _sigtramp + 56
5 JZH 0x100445290 _ZN12CAXExceptionC2EPKci + 187764
6 libsystem_pthread.dylib 0x0000000190f0c1b0+ 168
7 libsystem_pthread.dylib 0x0000000190f0c108+ 0
8 libsystem_pthread.dylib 0x0000000190f097b0 thread_start + 4
)
dSYM UUID: 981FC7CB-FC3F-351F-9C8E-88248232294B
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: JZH
Base Address: 0x00000001000d4000
指令：atos -o JZH.app.dSYM/Contents/Resources/DWARF/JZH 0x100445290
CheckPrivateCloud(void*) (in JZH) (CCPClient.cpp:488)
指令：dwarfdump --lookup 0x100445290 -arch arm64 JZH.app.dSYM
指令：atos -o JZH.app.dSYM/Contents/Resources/DWARF/JZH 0x1001d12f8
UmengSignalHandler (in JZH) + 144
指令：dwarfdump --lookup 0x1001d12f8 -arch arm64 JZH.app.dSYM
Application received signal SIGSEGV
(null)
(
0 CoreFoundation 0x255af0ef+ 150
1 libobjc.A.dylib 0x33a41c77 objc_exception_throw + 38
2 CoreFoundation 0x255af01d+ 0
3 JZH 0x1a4711 JZH + 1705745
4 libsystem_platform.dylib 0x3415109b _sigtramp + 34
5 libstdc++.6.dylib 0x33e3461b _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag + 70
6 libsystem_pthread.dylib 0x34155ddf+ 138
7 libsystem_pthread.dylib 0x34155d53 _pthread_start + 118
8 libsystem_pthread.dylib 0x34153afc thread_start + 8
)
dSYM UUID: 53B95E22-1D47-31C8-9452-41875FFC7F89
CPU Type: armv7
Slide Address: 0x00004000
Binary Image: JZH
Base Address: 0x00004000
指令：atos -o JZH.app.dSYM/Contents/Resources/DWARF/JZH 0x1a4711
UmengSignalHandler (in JZH) + 137
指令：dwarfdump --lookup 0x1a4711 -arch armv7 JZH.app.dSYM
目錄下一定要包含MyApp.app 和MyApp.app.dSYM兩個檔案。
在控制台使用dwarfdump指令，解析出記憶體位址，如：
dwarfdump –lookup 0x000036d2 –arch armv6 MyApp.app.dSYM
つづく