71.iOS 錯誤堆疊查詢崩潰原因的方法---根據崩潰資訊，找到對應的崩潰程式碼
-
已標記錯誤位置的:3 FIR 0x000000010bfddd8c -[FIRViewController viewDidLoad] + 8588 -
未標記錯誤位置，有基地址的情況：
3 FIR 0x000e3e92 0xd3000 + 69266這條呼叫棧包括下面四部分:
- 模組號: 這裡是3
- 二進位制庫名: 這裡是 FIR.im
- 呼叫方法的地址: 這裡是 0x000e3e92
- 第四部分分為兩列，基地址和偏移地址。此處基地址為 0xd3000，偏移地址為 69266。
使用下面的命令符號化：
atos -arch armv7 -o FIR -l 0xd3000 0x000e3e92 然後準確命令為atos -arch armv7 -o Taobao4iPhone -l 0x66000 0x012c03e1 前提條件是本機編譯過該版本的dSYM檔案（切版本號必須一致）結果：
-[FIRViewController viewDidLoad] (FIRViewController.m:156)可以看到崩潰的類為 FIRViewController，函式為 viewDidLoad，檔名是 FIRViewController.m，行數是 156 行。
-
未標記錯誤位置，無基地址的情況：
3 FIR 0x000f0e97 FIR + 69271基地址的計算方法:
－load address ＝ 0x000f0e97 － 69271 ＝0xe0000前面為16進位制資訊轉換為10進位制減去後面10進位制數 再轉成16進位制數字使用下面的命令符號化：
atos -arch armv7 -o FIR -l 0xe0000 0x000f0e97結果：
-[FIRViewController viewDidLoad] (FIRViewController.m:156)可以看到崩潰的類為
FIRViewController，函式為viewDidLoad，檔名是FIRViewController.m，行數是156行。這裡我們簡單我們看一下 atos 用法：
atos -o dysm檔案路徑 -l 模組load地址 -arch cpu 指令集種類 呼叫方法的地址- dysm 檔案路徑：可以在 Xcode Organizer 的 Archives 標籤欄下找到所有已歸檔的應用檔案。它儲存了編譯過程的詳細資訊，其中包括符號資訊。
- 模組 load 地址：模組載入的基地址，可以在日誌的動態庫資訊中找到對應模組的基地址。這裡為 0xd3000
- cpu 指令集種類：可以為 armv6 armv7 armv7s arm64。具體用哪個，可以參考對應模組的動態庫資訊中確定。
-
如
0x66000 - 0x19cdfff +Taobao4iPhone armv7 <43ebe409980f31fd9be165a64b002af5> /var/mobile/Applications/E3B51E77-D44D-4B3E-8767-B7DC2008D138/Taobao4iPhone.app/Taobao4iPhone那麼Taobao4iPhone模組的cpu指令集為armv7
2.打包程式，並安裝到手機上
選單欄->product->Archive。
如圖，在這一步的時候，show in Finder把剛剛生成的最新的xcarchive檔案儲存一份。
然後打包成功，安裝到手機上去（如果是釋出，就上傳到AppStore上去）
3.檢視崩潰資訊，並查詢原因
當有使用者使用此APP崩潰的時候會在bughd後臺收到崩潰資訊。如圖所示：
看這個頭都大了吧，下面我教大家解碼！
把剛才儲存的xcarchive檔案開啟，顯示包內容，將裡面的“Products->Applications->檔案”和”dSYMs->檔案->顯示包內容->Contents->Resources->DWARF->檔案“儲存到一個新的資料夾中，這裡我的資料夾是CrashReport。
我們來看崩潰資訊，具體應該看哪條資訊，fir給出了教程已經很清楚了。我們就要序號為3的這種“未標記錯誤位置，無基地址的情況”
將0x000fdf7f轉換為10進位制是1040255
1040255-20351 = 1019904
再轉為16進製為 0xf9000，這個就是基地址了。
我們開啟終端，進入CrashReport資料夾，輸入如下命令就可以得到崩潰資訊
Objective-C
atos -arch armv7 -o mengmengdai -l 0xf9000 0x000fdf7f如圖所示：