最近一段時間，在跟開發者溝通過程中，蘿莉發覺有些開發者對ios的應用符號表還不是很清楚，除了諮詢關於符號表生成、配置的問題以外，對bugly崩潰分析需要配置符號表也存在疑問。
在這裡，蘿莉就給大家分享下關於ios符號表的一些內容。
首先，進行常識「腦補」。
注意：
和.dsym成對出現，並且二者有相同的uuid值，以標識是同一次編譯的產物。
uuid值可以使用dwarfdump—uuid來檢查：
那麼，問題就來了！
實際上，使用xcode的organizer檢視崩潰日誌時，也自動根據本地儲存的.dsym檔案進行了符號化的操作。
並且，崩潰日誌也有uuid資訊，這個uuid和對應的.dsym檔案是一致的，即只有當三者的uuid一致時，才可以正確的把函式位址符號化。
3.
符號表怎麼生成？
一般地，xcode專案預設的配置是會在編譯後生成.dsym，開發者無需額外修改配置。
專案的buildsettings
generate debug symbols = yes
debug information format = dwarf with dsym file
採用不同的編譯打包方式，產生的.dsym檔案的路徑也不相同。
下面是幾種常用的編譯打包方式：
在xcode中編譯專案後，會在工程目錄下的build/configurationname
如果使用xcodebuild
一般地，我們推薦打包發布時，使用xcodebuild
如果開發者使用xcode
如果開發團隊不使用xcode編譯打包，而是使用make編譯生成.o檔案，然後打包發布。此時，編譯過程不會有.dsym檔案生成。開發者可以使用dsymutil工具從.o檔案中提取符號資訊。
在前面的內容可以知道，符號表的作用是把崩潰中的函式位址解析為函式名等資訊。
如果開發者能夠獲取到崩潰的函式位址資訊，就可以利用符號表分析出具體的出錯位置。
xcode提供了幾個工具來幫助開發者執行函式位址符號化的操作。
例如，崩潰問題的函式位址堆疊如下：
·
錯誤位址堆疊
3 corefoundation 0x254b5949 0x253aa000 + 1096008
4 corefoundation 0x253e6b68 _cf_forwarding_prep_0 + 24
5 supersdktest 0x0010143b 0x000ef000 + 74808
·
符號化堆疊
3 corefoundation 0x254b5949 + 712
4 corefoundation 0x253e6b68 _cf_forwarding_prep_0 + 24
5 supersdktest 0x0010143b -[viewcontroller didtriggerclick:] + 58
說明：
1.
大部分情況下，開發者能獲取到的都是錯誤位址堆疊，需要利用符號表進一步符號化才能分析定位問題。
2.
部分情況下，開發者也可以利用backtrace看到符號化堆疊，可以大概定位出錯的函式、但卻不知道具體的位置。通過利用符號表資訊，也是可以進一步得到具體的出錯位置的。
3.
目前，許多崩潰監控服務都顯示backtrace符號化堆疊，增加了可讀性，但分析定位問題時，仍然要進一步符號化處理。
·
崩潰資訊的uuid
下面，利用兩個工具來進行一下符號化的嘗試：
1、symbolicatecrash
symbolicatecrash是乙個將堆疊位址符號化的指令碼，輸入引數是蘋果官方格式的崩潰日誌及本地的.dsym檔案，執行方式如下：
使用symbolicatecrash工具的限制就在於只能分析官方格式的崩潰日誌，需要從具體的裝置中匯出，獲取和操作都不是很方便，而且，符號化的結果也是沒有具體的行號資訊的，也經常會出現符號化失敗的情況。
實際上xcode的organizer內建了symbolicatecrash工具，所以開發者才可以直接看到符號化的錯誤日誌。
2、atos
更普遍的情況是，開發者能獲取到錯誤堆疊資訊，而使用atos
$ xcrun atos -o executable -arch architecture -l loadaddress
address ...
說明：·
loadaddress
表示函式的動態載入位址，對應崩潰位址堆疊中 + 號前面的位址，即0x000ef000
·
address
表示執行時位址、對應崩潰位址堆疊中第乙個位址，即0x0010143b
·
實際上，崩潰位址堆疊中+號前後的位址相加即是執行時位址，即0x000ef000 + 74808 = 0x0010143b
執行命令查詢位址的符號，可以看到如下結果：
0x0010143b
-[viewcontroller didtriggerclick:] (in supersdktest) (viewcontroller.m:35)
開發者在具體的運用中，是可以通過編寫乙個指令碼來實現符號化錯誤位址堆疊的。
在實際的專案開發中，崩潰問題的分析定位都不是採用這種方式，因為它依賴於系統記錄的崩潰日誌或錯誤堆疊，在本地開發除錯階段，是沒有問題的。
），實現線上版本崩潰問題的記錄和跟蹤。
目前，國內外提供崩潰監控服務的產品有好多個，在崩潰問題的統計上可能不分伯仲。但提供自動符號化功能的產品卻基本沒有，大部分崩潰問題的堆疊只是簡單符號化以增強可讀性，沒有可以快速定位問題的行號資訊。
提供了位址堆疊符號化功能的崩潰分析服務，只要開發者配置了對應的符號表資訊，bugly服務會自動對錯誤位址堆疊進行符號化，出錯位置清晰可見，分分鐘定位和解決崩潰問題。
Xcode 崩潰堆疊符號化,定位崩潰
首先，進行常識 腦補 1.符號表是什麼？dsym檔案其實是乙個目錄，在子目錄中包含了乙個16進製制的儲存函式位址對映資訊的中轉檔案，所有debug的symbols都在這個檔案中 包括檔名 函式名 行號等 所以也稱之為除錯符號資訊檔案。注意 來檢查 那麼，問題就來了！2.符號表有什麼用？實際上，使用x...
iOS崩潰堆疊符號化，定位問題分分鐘搞定！
最近一段時間，在跟開發者溝通過程中，蘿莉發覺大家對ios的應用符號表還不是很清楚，除了諮詢關於符號表生成 配置的問題以外，對bugly崩潰分析需要配置符號表也存在疑問。在這裡，蘿莉就給大家分享下關於ios符號表的一些內容。首先，進行常識 腦補 1.符號表是什麼？dsym檔案其實是乙個目錄，在子目錄中...
iOS 崩潰符號化
1.符號表是什麼？dsym檔案其實是乙個目錄，在子目錄中包含了乙個16進製制的儲存函式位址對映資訊的中轉檔案，所有debug的symbols都在這個檔案中 包括檔名 函式名 行號等 所以也稱之為除錯符號資訊檔案。注意 來檢查 那如何知道crash檔案的uuid呢？可以用 grep 那麼，問題就來了！...