崩潰日志記錄

1、在執(zhí)行NSString *result = [[NSString alloc] initWithData:response? encoding:NSUTF8StringEncoding];的時候引起的崩潰,后臺沒有將數據加密直接發(fā)過來的,所以會引起崩潰

崩潰日志信息:*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSDictionaryM bytes]: unrecognized selector sent to instance 0x7f8625194d30'

崩潰截圖


1、 進程信息

第一部分是閃退進程的相關信息。

Incident Identifier : 是崩潰報告的唯一標識符。

CrashReporter Key: 是與設備標識相對應的唯一鍵值。雖然它不是真正的設備標識符,但也是一個非常有用的情報:如果你看到100個崩潰日志的CrashReporter Key值都是相同的,或者只有少數幾個不同的CrashReport值,說明這不是一個普遍的問題,只發(fā)生在一個或少數幾個設備上。

Hardware Model :標識設備類型。 如果很多崩潰日志都是來自相同的設備類型,說明應用只在某特定類型的設備上有問題。上面的日志里,崩潰日志產生的設備是iPhone 4s。

接下來幾行不言自明,無需贅述。

(2) 基本信息

這部分給出了一些基本信息,包括閃退發(fā)生的日期和時間,設備的iOS版本。

(3) 異常

Exception Type:異常的類型。

Exception Codes :異常錯誤碼

Termination Reason:閃退的原因,比如常見的數組越界啊,什么的。

Triggered by Thread:出現問題在哪個線程,這個比較重要,首先確定在哪個線程中出了問題,然后再去定位。

(4) 線程回溯

這部分提供應用中所有線程的回溯日志。 線程調用的一些,堆棧信息,壓根看不懂,所有需要進行符號化處理。

用Xcode自帶的 symbolicatecrash 工具來解析的.crash文件

1、獲取crash文件:

a、直接從設備中獲取方法如下圖


b、蘋果審核那邊發(fā)給你的(我的就是)

2、找到app包所對應的.dSYM文件,強調要對應

.dSYM 是保存 16 進制函數地址映射信息的中轉文件,我們調試的 symbols 都會包含在這個文件中,并且每次編譯項目的時候都會生成一個新的 dSYM 文件。測試給過來的.crash文件中,關于崩潰的確切語句和函數部分只有16進制地址符號,并不是我們在xcode調試時看到的xxx.cpp(xxfunction xx行)這樣的。一般發(fā)布一個版本需要保存好對應的.dSYM和.app包,方便分析crash


3、就是找到Xcode中的symbolicatecrash工具咯,

我用的Xcode8,路徑為

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

其他版本的xcode,自己百度咯,反正都差不多。把我們需要的工具直接復制到桌面上來(方便用)。

4、.crash文件的分析

a、.配置環(huán)境變量DEVELOPER_DIR,(配置好了就不再需要)

exportDEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

b、新建一個文件夾,將第二步中獲取的兩個文件放在同一個文件夾中


注意:上面指的是其所在的路徑。

經過上面的簡單幾步我們就能得到格式化好的crash日志,這樣就方便我們定位bug的位置了。

注:本文系轉載 ,作者:為誰而鳴

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容