如果你的項目中已經內建了友盟的統計日志分析，那麼友盟會把你項目中沒有用 try catch 捕獲的異常進行上傳，我們可以再友盟官網的“我的産品->錯誤分析->錯誤清單”去檢視目前已經統計到的crash詳情。
第一步：從crash日志詳情中擷取目前版本的dSYM UUID
在crash詳情中可以檢視到目前版本的dSYM UUID,如下圖
第二步：擷取對應編譯檔案.xcarchive
這個檔案在哪呢？打開XCode->菜單Window->Organizer，在編譯成功的檔案上右鍵，就能打開了。 （當然使用該軟體必須保證.xcarchive的uuid和已釋出的App的uuid一緻）
我一般的做法是，釋出成功後，把這個檔案.xcarchive直接送出到代碼版本庫對應的版本分支裡，這樣就不會搞丢了。
第三步：使用可視化工具dSYM定位crash位置
當我們打開友盟應用統計分析後，打開錯誤清單，隻能看到一些這不全面的堆棧錯誤資訊，這時候，可視化工具:dSYM便可以很友善的幫我們找到錯誤的地方
dSYM檔案下載下傳位址：http://pan.baidu.com/s/1c0pwD2K
打開dSYM，把編譯檔案.xcarchive檔案拖進去（該檔案名不能攜帶空格和漢字等符号）,之後把友盟中錯誤的堆棧記憶體位址複制進去，點分析即可，如下圖：
那麼問題來了，如果是我們自己記錄的日志資訊，我們收集到的記憶體位址并不是像友盟一樣為我們轉換好的，我們需要自己去轉換。
随便舉個數組越界例子，錯誤資訊如下
0 CoreFoundation 0x2fc49f9b <redacted> + 154
1 libobjc.A.dylib 0x3a3faccf objc_exception_throw + 38
2 CoreFoundation 0x2fb83a3b <redacted> + 418
3 CoreFoundation 0x2fb8d341 <redacted> + 44
4 Test 0x0009cf4f Test + 163663
這個163663便是我們需要的，轉換方法如下：将163663由10進制轉換為16進制，即 0x27F4F, 然後加上0x4000，得到0x2bf4f，這個便是轉換後的記憶體位址。