調試程序-斷點,Debug,崩潰日誌分析，友盟崩潰日誌

一.設置和查看斷點

斷點能夠分爲如下3種類型。

1. 文件行斷點設置

添加斷點->右鍵選擇Edit Breakpoint

 

Condition:指的是條件表達式，該項容許咱們對斷點生效設置條件，表示當知足某一特定條件的前提下，該斷點才生效。（該條件的錄入，不可以識別預處理的宏定義，也不能識別斷點做用域以外的變量和方法）。eg：i == 1 ; (i == 1 || i == 2)

 

Ignore：忽略次數。它指定了在斷點生效，應用暫停以前，代碼忽略斷點的次數。你若是但願應用運行一段時間後斷點才生效，那麼就可使用這個選項。好比說在調試某一循環體的時候。eg:Ignore 2 == 前兩次執行此處的代碼不會觸發該斷點，從第三次開始觸發該斷點。若是數字爲n,則從第n次開始觸發該斷點。

 

Action:動做。它表示當斷點生效時，Xcode做出反應後的行爲動做。點擊右邊的Add Action選項會彈出如圖

 

圖中所示紅色方框中的選項，可讓你指定那一種動做。默認的是Debugger Command。還有如下幾種動做供選擇，下面逐一介紹。

(1).AppleScript

它是蘋果提供的一種腳本語言，用來執行一些預先指定的行爲。選中該選項，將會出現如圖所示的AppleScript語言的輸入框。

 

你們可能看到了，我在輸入框中輸入了本門至高無上的心法祕訣，它的意思是彈出一個顯示「Hello World！」的對話框。點擊Compile按鈕後，若是沒有錯誤，會顯示成功信息。而點擊Test按鈕，會測試運行效果，以下圖

至於紅色方框中的內容是三種特殊符號相對應的定義。

符號標記	定義
@expression@	LLDB表達式
%B	斷點的名稱
%H	遇到該斷點的次數

 

(2).Capture GPU Frame

這個功能用於當斷點生效時，捕獲GPU當前所繪製的幀。該功能是輔助圖形調試的。

 

(3).Debugger Command

默認的選項，可讓斷點執行LLDB調試命令。

po _imageArray 打印該斷點上面用到的數組內容

 

(4).Log Message

使用Log命令能夠生成消息隊列，將相關的消息輸出到控制檯上，還有一個Speak Message選項，能夠播報消息。

 

(5).Shell Command

該動做接收一個命令文件和參數列表。以下圖所示

 

命令文件必須是一個可執行的二進制程序或者腳本。能夠複製粘貼輸入路徑，也能夠點擊Choose按鈕選擇具體文件。
參數經過空格表示分割，也能夠在兩個@字符之間包含LLDB表達式。
通常狀況下，Xcode會異步執行Shell Command，也就是說，Shell Command 和調試器將會同步執行。若是但願調試器在Shell Command命令完成後運行，則能夠勾選下面的Wait until done選項。

 

(6).Sound

動做會在斷點被觸發時，彈出聲音提示。

 

 

Options: 在執行完事件以後自動繼續執行。選中該選項以後，程序不會止步於該斷點，遇到該斷點也會繼續執行，可是會響應action中的調試信息。

 

2. 符號斷點設置

設置符號斷點與設置文件行斷點不一樣，須要點擊導航面板中的按鈕打開斷點導航面板，如圖15-10所示。
在斷點導航面板中，能夠看到全部的斷點。

 

其中有兩項——Add Symbolic Breakpoint和Add Exception Breakpoint，前者能夠建立符號斷點，後者能夠建立異常斷點。這裏咱們選擇Add Symbolic Breakpoint菜單項，此時能夠彈出建立符號斷點對話框，如圖

Symbol：後面能夠是

1. 方法名稱：會對全部具備此方法名稱的類方法生效。例如 initWithFrame: 。 

2. 特定類的方法：OC類和C++類都適用，例如 ，[UIView initWithFrame:]或者 Shap::draw()。 

3. 函數名稱。例如普通C函數。

 

Module：是模組的意思，用來限制知足符號的方法，編譯器將只會在斷點知足這個模組的符號的時候纔回暫停

 

其他的選項同上。

 

3. 異常斷點設置

 

Exception選項可讓你選擇響應Objective－C對象拋出的異常，也能夠選擇響應C++對象拋出的異常。

Break則是選擇斷點所接收的異常，是接收「Throw」語句拋出的異常仍是Catch語句的。

 

3.OpenGL ES錯誤斷點(OpenGl ES Error Breakpoint)

這個斷點的做用和異常斷點相似，只不過這個斷點只有在openGL ES錯誤發生的時候纔會觸發。

 

4.測試失敗斷點 Test Failure Breakpoint

僅在測試斷點失敗的時候纔會執行，這個時候，應用將會暫停在引起測試失敗的代碼處，而不是中止在測試代碼處。

 

2、調試工具欄

模擬位置按鈕左邊的爲圖層查看按鈕，點擊能夠查看界面的各個圖層

變量查看窗口

Auto。查看常用的變量。
 Local Variables。查看本地變量。
 Variables, Registers, Globals and Statics。查看所有變量，包括寄存器和全局變量等，如圖15-25所示，

其中圖標A是自動變量、S是靜態變量、R是寄存器、L是本地變量。

Print Description of 「i」  打印變量信息

Edit Value…    編輯變量的值

 

3、日誌與斷言輸出

1. 使用NSLog函數

2. 使用NSAssert宏

NSLog函數是無條件輸出，即程序運行到該語句，就會輸出結果。若是想有條件輸出結果，可使用NSAssert
宏。注意，NSAssert並非函數，它的定義以下：
#define NSAssert(condition, desc, ...)
其中第一個參數condition是布爾表達式，第二個參數desc是描述信息，參數後面的...是格式化desc描述信息
的。若是condition爲NO，則輸出desc描述信息，並拋出異常NSInternalInconsistencyException；若是

condition爲YES，則不輸出信息。

 

2. 移除項目中的打印信息

 

 

(1)移除NSAssert

NS_BLOCK_ASSERTIONS是Foundation框架中定義好的預處理宏，若是在編譯環境中設置NS_BLOCK_ASSERTIONS，在編譯的時候NSAssert宏將被移

(2) 移除NSLog

 

擴展： 

1.本身在pch文件中預約義以下宏

#ifdef MY_MACRO
#define NAME @"測試版本"
#else
#define NAME @"上線版本"

#endif

2.

設置preprocessor Macros—>Debug(添加MY_MACRO=1)

3.在項目中使用NAME宏

若是項目Scheme編譯模式爲Debug  輸出：name = 測試版本

若是項目Scheme編譯模式爲release 輸出：name = 上線版本

 

 

4、LLDB調試工具

p和po就是調試工具的命令，調試工具的編譯器相對獨立於Xcode。咱們進行Objective-C程序開發時，用過3種編譯器——GCC、LLVM GCC和Apple LLVM，其中GCC是比較古老的編譯器，如今咱們主要使用LLVM GCC和Apple LLVM。GCC的調試工具是GDB，是GCC Debug工具的縮寫，LLVM GCC和Apple LLVM的調試工具是LLDB（或lldb）。進入LLDB調試工具的一種方式是從終端進入，另一種是從Xcode進入。Xcode工具咱們比較熟悉，這裏主要介紹這種方式。具體作法很簡單，就是在程序中設置斷點，當程序掛起時，在輸出窗口中選擇Debugger Output，這時輸出窗口有(lldb)

命令提示符，這就進入了LLDB調試工具了。

經常使用命令：po

5、異常堆棧報告分析

[exception reason] 異常產生的緣由

[exception callStackSymbols] 符號化打印

 

查看設備的崩潰日誌

 

Window—>Devices—>View Device Logs

點擊Re-Symbolicate Log 符號化日誌信息

紅色標註部分指出崩潰代碼在ViewController0.m的第60行代碼

 

6、符號化設備的崩潰日誌

1.手動符號化設備的崩潰日誌

咱們在ios開發中會碰到的不少crash問題，若是Debug調試模式的話，咱們能夠每每很容易的根據log的輸出定位到致使crash的緣由，但對於已經上線的應用，或者是release環境包致使的crash，咱們就須要一些特殊的手段來經過crash log進行分析定位了。

經過參考網上的一些資料，總結了一下，下面介紹一下經過dSYM文件以及crash log分析定位的方法。

1.導出crash log

經過Xcode的Organizer查看某臺iphone設備的DeviceLog，選擇須要的crash log，導出XXX.crash文件。

2.找到對應的app文件

找到當前iphone設備上安裝的ipa文件，更改文件後綴名爲zip，解壓後獲得Payload文件夾，你須要的app文件就在其中了。

3.找到對應build版本的dSYM文件

dSYM文件是iOS編譯後保存16進制函數地址映射信息的文件，每次應用程序build後，都會生成對應的xxx.app, xxx.app.dSYM文件。

 

4.肯定dSYM、app以及crash文件的關係

 

首先將dSYM、app以及crash放入同一個文件夾中，經過終端進入該文件夾。

每個xx.app, xxx.app.dSYM文件都擁有相應的uuid，crash文件也有uuid,只有三者uuid一至才代表之三者能夠解析出正確的日誌文件。
查看xx.app文件的uuid的方法，在terminal中輸入命令：

dwarfdump --uuid xxx.app/xxx (xxx工程名)

查看xx.app.dSYM文件的uuid的方法，在terminal中輸入命令：

dwarfdump --uuid xxx.app.dSYM (xxx工程名)

而.crash的uuid位於，crash日誌中的Binary Images:中的第一行尖括號內。如：

armv7 <8bdeaf1a0b233ac199728c2a0ebb4165>

5.經過symbolicatecrash分析crash文件

Xcode有自帶的symbolicatecrash工具,能夠經過dSYM文件將crash文件中的16進制地址轉換成可讀的函數地址。該文件是隱藏文件，能夠經過以下命令查找並拷貝到系統目錄下，並創建快捷方式。

1)打開終端，進入到symbolicatecrash工具所在的文件夾目錄

第一步:找到symbolicatecrash工具所在的文件夾目錄

find /Applications/Xcode.app -name symbolicatecrash（速度快）

或者

find /Applications/Xcode.app -name symbolicatecrash -type f

運行結果

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

 

第二步:進入該目錄

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

 

2)查找確認是否存在symbolicatecrash(可省略)

ls -al | grep symbolicatecrash

 

bogon:Resources bang$ ls -al | grep symbolicatecrash

-rwxr-xr-x   1 root  wheel    37893  2 26 10:22 symbolicatecrash

 

3)將symbolicatecrash工具拷貝到dSYM、app以及crash所在的文件夾

bogon:Crash bang$ cp symbolicatecrash /Users/bang/Desktop/Crash

4)執行以下命令，便可正確解析crash文件

./symbolicatecrash xxx.crash xxx.app.dSYM > test.txt

./symbolicatecrash DemoModel.crash CA3ACCD1-F63D-3A37-9773-82B155C02DA6.dSYM >crash2.txt

 

5)打開crash2.txt就能夠看到符號化的崩潰日誌了

 

 

2.經過友盟符號化設備的崩潰日誌

 

若是出現bug的構建版本是在本身的電腦上打包的，那麼直接打開終端輸入黑色部分的代碼就能定位到崩潰的代碼位置；

 

若是出現bug的構建版本不是在本身電腦上打包的，那麼須要找到對應的構建版本拷貝到本身項目中構建版本的目錄中