ios開發之crash日誌收集，以及分析

在ios開發過程，當應用已經打包，iPhone設備經過ipa的包安裝應用後，在使用過程發現crash，那麼如何獲取crash日誌呢，現提供以下四種獲取crash日誌的方式:

一、打開iPhone設備的設置裏面的隱私中的「診斷與用量」，而後若是app崩潰了，設備會彈出提示框，用戶確認以後，crash log會自動發送到蘋果後臺，而後用開發者帳號登錄上去，能夠拿到crash log。

二、將設備連接到mac或者windows上，同步到iTunes後再從電腦的目錄下獲取crash log：

Mac OS X：~/Library/Logs/CrashReporter/MobileDevice

Windows XP：C:\Documents and Settings\Application Data\Apple computer\Logs\CrashReporter

Windows 7/Vista: C:\Users\計算機登陸名\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice

三、能夠經過itools工具獲取crash log，打開itools，鏈接iPhone設備，按照下圖提示，獲取crash log

四、經過xcode獲取crash log，打開xcode，鏈接iPhone設備，打開window下的device，能夠看到你鏈接的設備，能夠看到以下界面,點擊view device logs，能夠看到全部的日誌，選中日誌，點擊右鍵能夠處處日誌

2、解析crash logs

經網上搜索解析crash logs的三種，因爲未經測試，因此沒有記錄下，詳見能夠：http://www.cocoachina.com/industry/20140514/8418.html

經測試可用的方法爲atos -o XXX.app.dSYM/Contents/Resources/DWARF/XXX -l address0 targetAddress

其中：

a、XXX是appname

b、address0是當前進程在內存中加載的起始地址，至於爲何須要這個，那就有必要去了解下ASLR

獲取地址參下圖：

binary Images後面第一個即爲基地址（內存中加載的起始地址）

c、targetAddress就是你想要符號化的地址  ，此處通常選取以下

            3 appName 0x000f462a 0x4000 + 984618

            4 appName 0x00352aee 0x4000 + 3468014

以appName開頭的地址

2、常見的Crash類型

一、Watchdog timeout

Exception Code：0x8badf00d， 不太直觀，能夠讀成「eat bad food」，意思是don‘t block main thread

緊接着下面會有一段描述：

Application Specific Information：

com.xxx.yyy　　 failed to resume in time

對於此類Crash，咱們應該去審視本身App初始化時作的事情是否正確，是否在主線程請求了網絡，或者其餘耗時的事情卡住了正常初始化流程。

一般系統容許一個App從啓動到能夠相應用戶事件的時間最多爲5S，若是超過了5S，App就會被系統終止掉。在Launch，resume，suspend，quit時都會有相應的時間要求。在Highlight Thread裏面咱們能夠看到被終止時調用到的位置，xxxAppDelegate加上行號。 

PS. 在鏈接Xcode調試時爲了便於調試，系統會暫時禁用掉Watchdog，因此此類問題的發現須要使用正常的啓動模式。

二、User force-quit

Exception Codes: 0xdeadfa11, deadfall

這個強制退出跟咱們平時所說的kill掉後臺任務操做還不太同樣，一般在程序bug形成系統沒法響應時能夠採用長按電源鍵，當屏幕出現關機確認畫面時按下Home鍵便可關閉當前程序。

三、Low Memory termination

跟通常的Crash結構不太同樣，一般有Free pages，Wired Pages，Purgeable pages，largest process 組成，同事會列出當前時刻系統運行全部進程的信息。

關於Memory warning能夠參看我以前寫的一篇文章IOS 內存警告 Memory warning level。

App在運行過程當中，系統內存緊張時一般會先發警告，同時把後臺掛起的程序終止掉，最終若是仍是內存不夠的話就會終止掉當前前臺的進程。

當接受到內存警告的過後，咱們應該釋放盡量多的內存，Crash其實也能夠看作是對App的一種保護。

四、Crash due to bugs

由於程序bug致使的Crash一般千奇百怪，很難一律而論。大部分狀況經過Crash日誌就能夠定位出問題，固然也不排除部分疑難雜症看半天都不值問題出在哪兒。這個就只能看功底了，一點點找，老是能發現蛛絲馬跡。是在看不出來時還能夠求助於Google大神，總有人遇到和你同樣的Bug 

 

3、常見的Exception Type & Exception Code

一、Exception Type

1）EXC_BAD_ACCESS

此類型的Excpetion是咱們最長碰到的Crash，一般用於訪問了不改訪問的內存致使。通常EXC_BAD_ACCESS後面的"()"還會帶有補充信息。

SIGSEGV: 一般因爲重複釋放對象致使，這種類型在切換了ARC之後應該已經不多見到了。

SIGABRT:  收到Abort信號退出，一般Foundation庫中的容器爲了保護狀態正常會作一些檢測，例如插入nil到數組中等會遇到此類錯誤。

SEGV:（Segmentation  Violation），表明無效內存地址，好比空指針，未初始化指針，棧溢出等；

SIGBUS：總線錯誤，與 SIGSEGV 不一樣的是，SIGSEGV 訪問的是無效地址，而 SIGBUS 訪問的是有效地址，但總線訪問異常(如地址對齊問題)

SIGILL：嘗試執行非法的指令，可能不被識別或者沒有權限

2）EXC_BAD_INSTRUCTION

此類異常一般因爲線程執行非法指令致使

3）EXC_ARITHMETIC

除零錯誤會拋出此類異常