Symbolicating Crash Reports（符號化崩潰報告）
符號化 是解決將樹結(jié)構(gòu)地址轉(zhuǎn)化Wie源碼的方法和函數(shù)的名字、可認(rèn)識的標(biāo)示符的進(jìn)程；如果沒有這個步驟很難找到崩潰出現(xiàn)在哪里。
1）當(dāng)編譯器將源碼轉(zhuǎn)化為機器碼時，它同樣產(chǎn)生調(diào)試的符號，這個符號集匹配每一個機器的介紹在被編譯為二進(jìn)制對應(yīng)到源碼的行。
依賴調(diào)試信息格式 (DEBUG_INFORMATION_FORMAT)的建立設(shè)置，這些調(diào)試符號被存儲在二進(jìn)制或在一個比較的調(diào)試符(dsym)文件中。
默認(rèn)，一個應(yīng)用（debug）調(diào)試配置的建立存儲了調(diào)試符號在被編譯好的二進(jìn)制文件中當(dāng) 而release方式建立程序應(yīng)用存儲調(diào)試符號在一個協(xié)同的dsym文件去減少字節(jié)大小。
調(diào)試符號文件和應(yīng)用的二進(jìn)制被綁定通過UUID（per-build-basis），一個新的UUID被生成每一個應(yīng)用的建立和唯一的標(biāo)示符。
甚至一個方法（標(biāo)識）執(zhí)行被重建從相同的源代碼中國，和相同的編譯器設(shè)置，它將有一個不同的建立UUID。
調(diào)試符號文件來自于隨后的簡歷，甚至從相同的源文件中，將不會和其他的簡歷程序進(jìn)行相互操作。
【即為：（1）編譯文件和描述符進(jìn)行綁定 ， （2）UUID是一一對應(yīng)，程序之間和dsym不會混淆】
2）當(dāng)你歸檔應(yīng)用用于發(fā)布時，xcode將會集合應(yīng)用二進(jìn)制和.dsym 文件并且存儲它們在一個位置在你的home文件夾下面。你能夠找到所有你的歸檔得應(yīng)用在xcode組織中在 "Archived” 字段下。 App Distribution Guide
【也就是打包的是偶，可以在這里會看到.dsym 文件進(jìn)行下載】
重點： 從測試、應(yīng)用預(yù)覽和自定義中符號化崩潰，你必須retain 歸檔對于你的每一次創(chuàng)建應(yīng)用。
3）發(fā)布應(yīng)用通過app store 或者構(gòu)架一個test fight 的test版本，你將給出的選擇包括dsym文件當(dāng)你上傳你的歸檔文件到iTunes Connect。在子類從test flight 中集合用戶和客戶當(dāng)他們有選擇分享診斷數(shù)據(jù)的時候。對于更多信息查看App Distribution Guide 。重點：崩潰日志從app預(yù)覽中收到地 信息不會被符號化，甚至包括你的的dsym文件當(dāng)你上傳你的歸檔文件到iTunes Connect上。你將需要符號化更多崩潰報告來自于應(yīng)用預(yù)覽使用xcode。可看：Symbolicating Crash Reports With Xcode.
4）當(dāng)應(yīng)用崩潰的時候，一個沒有符號的崩潰日志被創(chuàng)建和存儲在設(shè)備上。
5）用戶取回直接取回崩潰日志從設(shè)備中【Debugging Deployed iOS Apps 步驟】，如果你已經(jīng)發(fā)布你的應(yīng)用工通過 AdHoc or Enterprise distribution，這個只有一種方式就是通過用戶。
6）奔潰報告從設(shè)備上獲取沒有符號化的，將需要被符號化通過xcode。xcode使用dsym文件鏈接你的二進(jìn)制應(yīng)用去替代每一個地址在backtrace和原始的代碼。結(jié)果就是符號化崩潰報告。
7） 如果用戶有選擇分享診斷數(shù)據(jù)到蘋果，或者你的用戶已經(jīng)安裝你的應(yīng)用的測試版本通過testflight。崩潰日志被上傳到app Store上。
8）app store 符號化崩潰日志和組織類似的崩潰報告。這個的總數(shù)崩潰報告被調(diào)用在一個崩潰點。
9）符號化崩潰報告用于解決bug，在xcode的崩潰組織中。
