轉載至搜狗測試

日誌主要分為六個部分：進程信息、基本信息、異常信息、線程回溯、線程狀態和二進制映像。

我們在進行iPhone應用測試時必然會在“隱私”中找到不少應用的崩潰日誌，但是不會閱讀對於很多人來說簡直頭疼。在此為大家詳細介紹一下具體的閱讀方法，希望大家可以更快的定位BUG。首先我們先看一下從iPhone中隨機抽出的一個Crash日誌：

   //1. 進程信息
Hardware Model:      iPhone9,1
Process:             com.sogou.sogouinput.BaseKeyboard[4447]
Path:               /private/var/containers/Bundle/Application/D121D4D7-C3EE-4861-B5AF-10C367749E24/SogouInput.app/PlugIns/com.sogou.sogouinput.BaseKeyboard.appex/com.sogou.sogouinput.BaseKeyboard
Identifier:          com.sogou.sogouinput-.basekeyboard
Version:             79794 (4.1.0)
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           com.sogou.sogouinput-.basekeyboard[4557]
 
//2. 基本信息
Date/Time:           2016-11-22 18:55:46.2041 +0800
Launch Time:         2016-11-22 18:55:45.4011 +0800
OS Version:          iPhone OS 10.0.2 (14A456)
Report Version:      104
 
//3. 異常信息
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype:KERN_INVALID_ADDRESS at 0x006e006e00000010
Triggered byThread:  7
 
//4. 線程回溯（顯示發生crash線程的信息）
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib         0x0000000185fa016cmach_msg_trap + 8
1   libsystem_kernel.dylib         0x0000000185f9ffdcmach_msg + 72
2   CoreFoundation                    0x0000000186f9dcec __CFRunLoopServiceMachPort + 192
3   CoreFoundation                    0x0000000186f9b908 __CFRunLoopRun + 1132
4   CoreFoundation                    0x0000000186eca048 CFRunLoopRunSpecific + 444
5   GraphicsServices                    0x000000018894d198GSEventRunModal + 180
6   UIKit                          0x000000018cea4628 -[UIApplication _run] + 684
Thread 7 name:  SGInputThread
Thread 7 Crashed:
0   libsystem_c.dylib              0x0000000185eda77cfclose + 40
1   libsystem_c.dylib              0x0000000185eda778fclose + 36
2   ...gou.sogouinput.BaseKeyboard    0x000000010034e420 t_fileRead::Close()(t_file.cpp:251)
3   ...gou.sogouinput.BaseKeyboard    0x000000010034e49c t_fileRead::Open(unsignedshort const*) (t_file.cpp:221)
4   ...gou.sogouinput.BaseKeyboard    0x00000001002ac8f4t_lbsDict::AddSCD(unsigned short const*, int) (t_lbsDict.cpp:218)
5   ...gou.sogouinput.BaseKeyboard    0x00000001003f718ct_convertInterface::AddSCD(unsigned short const*, int)(t_convertInterface.cpp:544)
6   ...gou.sogouinput.BaseKeyboard    0x0000000100362478t_pyDictInterface::BuildExtDict(unsigned short const*, s_cellDictInput*,s_cellDictOutput*) (Dict.cpp:961)
 
//5. 進程狀態
Thread 7 crashedwith ARM Thread State (64-bit):
    x0: 0x0000000000000000            x1:0x0000000185f1b89c         x2: 0x0000000000000000        x3:0x00000001080e422c
    x4: 0x0000000100000001            x5:0x0000000000000001        x6: 0x0000000000000000        x7: 0x0000000000000000
    x8: 0x000000004f4e4345             x9:0x0000000000000038        x10: 0x0000000000000010      x11:0x000000000000001f
   x12: 0x000000000000000d            fp:0x000000016e399d50         lr: 0x0000000185eda778          sp:0x000000016e399d40
pc:0x0000000185eda77c                cpsr:0x20000000
 
//6. 二進制映像
Binary Images:
0x100fa8000 -0x100fd7fff dyld arm64 
 
<fc8715469f7b30228b67a5ae12cadf10> /usr/lib/dyld
0x102a88000 -0x102a8ffff sdk.dylib arm64 <5d710be25db4309d8b5e344066a9cb29>/System/Library/Caches/com.apple.xpc/sdk.dylib
0x1859a4000 -0x1859a5fff libSystem.B.dylib arm64 <8788325e11bc31a39b075a3497d26ebd> /usr/lib/libSystem.B.dylib
0x1859a6000 -0x1859fbfff libc++.1.dylib arm64 
 
<95f6dd603b933208ba95cc2d84613c54> /usr/lib/libc++.1.dylib
0x1859fc000 -0x185a1cfff libc++abi.dylib arm64 <286b3adc78d1308eaa0d6f10914b1fa7> 

日誌組成分析：

在上述六個部分中，我們最需要關註的是異常信息和線程回溯的內容。

1. 進程信息：發生crash進程的相關信息

Hardware Model: 標識設備類型

Process：應用名稱

Path：所在路徑

Identifier：程序ID

Version：版本號

Code Type：處理器架構

2.

3. 異常信息：崩潰時拋出的異常類型，還能看到異常編碼和拋出異常的線程。

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Subtype: KERN_INVALID_ADDRESS at0x006e006e00000010

Triggered by Thread: 7

Exception Type異常類型：通常包含Signal信號 和 EXC_BAD_ACCESS等。

Exception Codes：異常編碼：

Crashed Thread：發生Crash的線程id

註：

具體信號說明參見iOS異常捕獲

詳細的異常編碼代表的含義請參考：Hexspeak

因此我們可以確定本次崩潰原因是內存訪問錯誤

4. 線程回溯：回溯是閃退發生時所有活動幀清單。它包含閃退發生時調用函數的清單。

實際上我們直接從iPhone中導出的崩潰日誌應該是一串地址表示的，如下：

AppName 0x0000000100205280 0x0000000100028000 + 1954432

AppName 0x00000001002ae59c 0x0000000100028000 + 2647440

大家可以通過symbolicatecrash命令和dSYM文件將最後的兩列解析為具體的方法名和行數。（具體使用方法大家可以自行查找）

在這裏我們就可以看到詳細的方法名，這樣就能幫助開發同學定位到具體位置。

5. 線程狀態：閃退時寄存器中的值。一般不需要這部分的信息，因為回溯部分的信息已經足夠讓你找出問題所在。

6. 二進制映像：閃退時已經加載的二進制文件。

低內存崩潰：

因為低內存崩潰日誌與普通崩潰日誌略有不同，所以分開說明一下。

iOS設備檢測到低內存時，虛擬內存系統發出通知請求應用釋放內存。這些通知發送到所有正在運行的應用和進程，試圖收回一些內存。

如果內存使用依然居高不下，系統將會終止後臺線程以緩解內存壓力。如果可用內存足夠，應用將能夠繼續運行而不會產生崩潰報告。否則，應用將被iOS終止，並產生低內存崩潰報告。低內存崩潰日誌上沒有應用線程的堆棧回溯。相反，上面顯示的是以內存頁數為單位的各進程內存使用量。被iOS因釋放內存頁終止的進程名稱後面你會看到jettisoned 字樣。如果看到它出現在你的應用名稱後面，說明你的應用因使用太多內存而被終止了。

低內存崩潰日誌看起來像這樣：

當應用發生低內存閃退時，你必需看看應用中內存使用的方式，以及是如何處理低內存警告的。你可以使用Instruments工具中使用Allocations 和 Leaks來發現內存分配問題和內存泄漏問題。如果你不知道如何利用Instruments 檢查內存問題。

iOS崩潰日誌 如何看