一、背景

最近梳理了公司的Crash管理流程，感覺這個過程可以作為一款較大業務量App的參考流程，調研了其他，基本都是大同小異。

二、Crash文件的產生與符號化

1、符號表

符號化的3種方法，不多說，前兩種不是本文討論的，直接略過，說第三種。

每一個可執行程序都有一個build UUID來唯一標識（這個UUID不同于用戶設備的那個唯一UUID，這個是標示應用的），在Xcode項目編譯后，在編譯生成的二進制文件.app的同級目錄下生成的同名的.dSYM文件（符號表文件）。.dSYM文件其實是一個目錄，在子目錄中包含了一個16進制的保存函數地址映射信息的中轉文件，所有Debug的symbols都在這個文件中(包括文件名、函數名、行號等)，所以也稱之為調試符號信息文件。

2、3個文件的一致性

這3個文件是：符號表（.dSYM文件）、應用二進制文件（.app文件）、崩潰日志（.crash文件）， 通過比較三者的uuid是一致的，只有在這三者一致的情況下，才能正確的把函數地址符號化出來。集齊這三個文件，我們再借助atos工具（實際是一個可以把地址轉換為函數名（包括行號）的工具）就可以得到符號化后的crash信息了。

三、自動化系統的搭建

.dsym符號化文件是xcode編譯階段的產物，在打包編譯時就要保留好。因為我們用戶安裝的ipa包里是沒有這個文件的。所以需要每次打包完成都要save一份。如果要做到整個過程自動化，當然需要部署到機器上，創建一個符號化的服務，這個服務的大致過程如下：

1、.dsym與.app文件的上傳

前面說了，符號化前提是集齊三個文件，其中.crash是用戶提供，那么.dsym與.app就是發布者提供了。記住xcode打包不一定會自動創建符號化文件如果你xcode設置錯誤的話（Build Settings -> Build Options -> Debug Information Format 設置為DWARF with dSYM File），xcode打包完成時，啟動對應的上傳模塊，將.dsym和.app壓縮之后上傳到遠端服務。

2、用戶.crash文件的獲取

蘋果的app每次crash都會產生一個.crash文件，不可能奢望用戶給你提供設備去獲取.crash文件，所以App首先需要擁有獲取.crash文件并上傳的能力，如果上傳成功，推薦及時清理掉.crash文件（為了App的瘦身，也真是夠拼了）。

3、符號化與Crash分類

經過上面2步之后，就集齊了Crash符號化的3個必需文件，獲取到具體的代碼文件信息后，可以根據代碼的歸屬類，進行進一步的分類，找到對應代碼的責任人，通過郵件或者其他方式通知責任人。

4、有沒有其他的方案

從上面的過程中，需要你去啟服務管理這個過程，如果你沒有服務支持人員，僅靠客戶端人員，也是有妥協方案的。例如，你可以將

.dsym文件打包一起進入ipa安裝包（或者采取懶加載方式download，這個文件大小也是客觀的），在App客戶端集齊這三個文件，然后進行符號化（蛋疼的性能問題）。當然，這種也只適合小型App用。

四、參考文獻：

1、https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/ConfiguringYourApp/ConfiguringYourApp.html

2、http://www.cocoachina.com/industry/20140514/8418.html

3、http://blog.csdn.net/longzs/article/details/51272980