[iOS]使用symbolicatecrash分析crash檔案

時間 2014-12-0323:39:00  部落格園-原創精華區

原文  http://www.cnblogs.com/ningxu-ios/p/4141783.html

主題 iOS APP iOS開發

對於我們iOS開發人員來說，最心碎的事莫過於蘋果審核一個星期後上架app store，而第二天就報出閃退bug。一周前我剛經曆過，而且最坑的是由於第一次做個人開發，經驗不足，沒有整合友盟的分析SDK，還好有幾個好心同事下載了，然後果然有兩台機器上出現了閃退。真是天無絕人之路，最重要的crash檔案有了。下面我就來詳細描述一下具體的心路曆程以及分析方法。

iOS app的所有崩潰記錄都會記錄在裝置上，所以對於和我一樣沒有整合讓使用者發送崩潰報告功能的iOS開發人員來說，要獲得crash檔案就必須先連上崩潰過的機器，然後開啟Xcode，選擇Window -> Devices（如果是Xcode6以下，則是Window -> Organizer -> Devices），選擇你自己的機器，然後點擊View Device Logs，這時候會開啟一個小視窗，這就是你機器上至目前為止存的所有app的崩潰資訊了。如果是好久沒看過這個資訊，開啟後還要讀取好久才能完全讀完，總之，找到你的app最後一次崩潰記錄，右鍵匯出。（先不要在意下圖的資訊，我只是隨便找了一個）

我們先看一眼匯出來的.crash檔案，上半部分都是一些基本資料（基本沒用），重點看下崩潰部分的記錄，如下圖（是下圖，不是上圖。）

看紅框裡的，隱隱有種不翔的預感，很像是數組越界之類的問題啊，可下邊幾行寫的都是啥，這怎麼定位問題啊。先不管了，先在案頭上建個檔案夾，就叫crash吧，然後把這個匯出的.crash檔案扔進去。想要再詳細點的記錄還缺幾樣東西呢。。。

找到你上次發布的ipa（如果實在沒有了就再從Archives裡匯出來一個，但一定要保證是你上次發布用的那個），右鍵 -> 開啟檔案 -> 歸檔工具 + 生產力(就是解壓縮)，然後把Payload檔案夾下的.app檔案也扔到剛剛的crash檔案夾裡。

接下來還需要dSYM檔案，還是在Archives裡，找到發布用的那個，右鍵Show in Finder，如圖

然後對檔案夾中的這個.xcarchive檔案右鍵，顯示包內容，就可以看到一個名為dSYMs的檔案夾，把裡面的.dSYM檔案拷出來，還是放到案頭的crash檔案夾裡。好了，還剩一個重頭了，就是標題上說的symbolicatecrash工具。

symbolicatecrash是一個隱藏工具，它在我的Mac中的具體路徑如下(Xcode6.1.app請換成你的Xcode名稱)

/Applications/Xcode6.1.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

你也可以在終端中輸入命令搜尋：

find /Applications/Xcode6.1.app -name symbolicatecrash -typef

把這個路徑拷貝一下，然後粘到Finder的“前往檔案夾”下，前往，就可以看到symbolicatecrash工具了，現在把它也拷到案頭的crash檔案夾裡。至此，crash檔案夾裡現在有4個檔案了，分別是.app, .crash,.dSYM, symbolicatecrash。接下來就是用終端敲命令，產生更易分析的crash。

首先用cd命令進入到crash檔案夾下，然後輸入以下命令

./symbolicatecrash /Users/xxxx/Desktop/crash/InOrder.crash /Users/xxxx/Desktop/crash/InOrder.app.dSYM >Control_symbol.crash

上述命令中，"xxxx"和"InOrder"請自行替換成對應的名稱。運行，這時候終端可能會報錯Error:"DEVELOPER_DIR" is not defined at /usr/local/bin/symbolicatecrashline 53. 這時候在終端中再輸入如下（Xcode6.1.app依然是要替換成實際名稱）

export DEVELOPER_DIR="/Applications/Xcode6.1.app/Contents/Developer"

然後再跑一下剛剛的那個命令，這時候看一下案頭的crash檔案夾下就會多出一個名為“Control_symbol.crash”的檔案，這就是可定位問題的crash檔案了，我們開啟看一下。 現在紅框裡原來的那些亂七八糟的東西已經 “ 翻譯 ” 成了崩潰在具體的哪一個 .m 檔案的哪一行。下面就是進行合理的猜想和調試了，比如我的崩潰就是因為這個第三方時間選擇控制項使用截取字串的形式來獲得時間，像 09:23 PM 就被固定的拆成了時、分、上下午標識 3 段，結果使用者使用 24 小時制的時候，時間就成了 21:23 ，沒了上下午標識， array[2] 超出下標妥妥的閃退。想想我腦洞也是蠻大的，這種問題原因都被猜到了。。。