iOS開發之Xcode常用調試技巧總結

標籤：ccf   apple   call   解決   ras   符號   html   load   point   

兩種最常見最普通的方法：
1、NSLog，最簡單的方法，查看變結
中是否有值，有什麼值，是不是自己需要的值，然後找到bug。
2、po命令，在程式進入斷點處，在控制台中輸入po 變數名，也可以像NSLog一樣查看變數是否有值，有什麼值。

今天主要介紹點高大上的方法。

一、Memory Graph

Xcode8新增：Memory Graph解決閉包引用迴圈問題

這個時候就進入了斷點模式，可以查看issue面板，注意選擇右邊Runtime：

有很多歎號說明就有問題了。看記憶體中object的名字，有一條是Closure captures leaked。展開後點擊就可以看到這個issue對應的記憶體配置圖形展示在中間的面板中。當然了，我們更多的時候是在debug頁面下查看：

所以，這裡面引用迴圈了。點擊紫色的歎號會出現Xcode分析出來的記憶體引用圖形：

有了這個圖就很容易看出來了：這裡有個引用迴圈

順便提一下，通過在Arguments中設定參數，列印出App載入的時間長度，包括整體載入時間長度，動態庫載入時間長度等。

在Environment Variables中添加DYLD_PRINT_STATISTICS欄位，並設定為YES，在控制台就會列印載入時間長度。

二、Xcode調試技巧之：LLDB

1、po：print object的縮寫，表示顯示對象的文本描述，如果對象不存在則列印nil。
簡單的列印一個對象我們就不說了，我們來說說特殊的應用情境吧！
應用情境：你想知道一個視圖包含了哪些子視圖。當然你可以迴圈列印子視圖，但是下面只需要一個命令即可解決。
輸出視圖層級關係（這是一個被隱藏的命令）:

po [[self view] recursiveDescription]

還有個常見的調試情境，比如你要列印一個model。你直接用NSLog或po對象處理的結果是model的地址，這並不是我們想要的。怎麼辦？有沒有解決方案呢？
答案是有的。你可以重寫model裡面的description方法。但是，如果model裡屬性非常多，這樣就不適用了。你不可能說在description方法裡面拼接屬性返回。這樣不僅麻煩，而且可讀性非常差。到這裡，我們可以利用runtime動態擷取屬性並返回。不過我並不建議你重寫description方法，我推薦你重寫debugDescription方法（至於詳細的介紹以及如何重寫請點擊此處），因為debugDescription方法和description方法效果一樣，區別在於debugDescription方法是在你使用po命令時調用的，實際上也是調用了description方法。
2、p:可以用來列印基礎資料型別 (Elementary Data Type)。
3、call:執行一段代碼

call NSLog(@"%@", @"yang")

4、expr:動態執行指定運算式

expr i = 101輸出：(int)$0 = 101

5、bt:列印當前線程堆棧資訊
如果要列印所以線程堆棧資訊，使用:bt all即可。
6、image:常用來尋找棧地址對應代碼位置：
舉個栗子：
應用情境（數組越界）類比代碼：

NSArray *array = @[@"yang",@"she",@"bing"];NSLog(@"%@",array[3]);

錯誤資訊如下：

Terminating app due to uncaught exception‘NSRangeException‘, reason:‘ -[NSArrayI objectAtIndex:]: index 3 beyond bounds [0 .. 2]‘* Firstthrowcall stack:(0 CoreFoundation 0x000000010579734b exceptionPreprocess + 1711 libobjc.A.dylib 0x00000001051f821e objc_exception_throw + 482 CoreFoundation 0x00000001056d1eeb -[__NSArrayI objectAtIndex:] + 1553 BGMultimediaDemo 0x0000000104c25550 -[ViewController viewDidLoad] + 1924 UIKit 0x0000000105d5c06d -[UIViewController loadViewIfRequired] + 1258..................21 BGMultimediaDemo 0x0000000104c25adf main + 11122 libdyld.dylib 0x000000010857268d start + 123 ??? 0x0000000000000001 0x0 + 1)libc++abi.dylib: terminatingwithuncaught exception of type NSException

這個時候我們如果懷疑出錯的地址是0x0000000104c25550，那麼我們可以使用下面命令來找出錯誤碼的位置：

image lookup --address 0x0000000104c25550

執行命令後輸出結果如下：

Address: BGMultimediaDemo[0x0000000100001550] (BGMultimediaDemo.TEXT.text + 192)Summary: BGMultimediaDemo`-[ViewController viewDidLoad] + 192 at ViewController.m:30

從上面輸出結果中可以看出，錯誤位置應該是ViewController.m檔案中的30行。是不是超級好用？反正我覺得好用。

三、Xcode調試技巧之：斷點（Breakpoint）

斷點，程式員Debug必備技之一。
1、條件斷點
打上斷點之後，對斷點進行編輯，設定相應過濾條件。下面簡單的介紹一下條件設定：
Condition：返回一個布爾值，當布爾值為真觸發斷點，一般裡面我們可以寫一個運算式。
Ignore：忽略前N次斷點，到N+1次再觸發斷點。
Action：斷點觸發事件，分為六種：
AppleScript：執行指令碼。

Capture GPU Frame：用於OpenGL ES調試，捕獲斷點處GPU當前繪製幀。

Debugger Command：和控制台中輸入LLDB調試命令一致。

Log Message：輸出自訂格式資訊至控制台。

Shell Command：接收命令檔案及相應參數列表，Shell Command是非同步執行的，只有勾選“Wait until done”才會等待Shell命令執行完在執行調試。

Sound：斷點觸發時播放聲音。

這些功能平時在偵錯工具的過程中都可以進行嘗試，說實話我用的設定Condition項會較多些。
Options(Automatically continue after evaluating actions選項)：選中後，表示斷點不會終止程式的運行。

2、異常斷點
異常斷點可以快速定位不滿足特定條件的異常，比如常見的數組越界，這時候很難通過異常資訊定位到錯誤所在位置。這個時候異常斷點就可以發揮作用了。
添加異常斷點：

編輯異常斷點：

Exception：可以選擇拋出異常物件類型：OC或C++。
Break：選擇斷點接收的拋出異常來源是Throw還是Catch語句。

3、符號斷點
符號斷點的建立方式和異常斷點一樣一樣的，在符號斷點中可以指定要中斷執行的方法：
舉個例子，常見的情境，我想讓它執行到ViewController類中的viewWillAppear方法就中斷執行：

Symbol:[ViewController viewWillAppear:]即[類名 方法名]可以執行到指定類的指定方法中開始斷點。如果只有viewWillAppear:即方法名，它會執行到所以類中的viewWillAppear:方法中開始斷點。

4、監控斷點
我們偵錯工具的大部分時候都是為了監控某個變數的變化，在代碼中變數出現的地方添加斷點不僅累而且還可能漏掉，事後還得一個一個刪掉，實在很累。
我們可以通過為變數添加監控斷點來簡單地做到這一點。找到變數第一次出現的地方，添加一個普通斷點，進入 debug 模式後在 Variables View 中右鍵變數，選擇 Watch 變數名。這樣，每一次該變數被改變都會觸發斷點告知我們。

四、Xcode調試技巧之：EXC_BAD_ACCESS

1、開啟殭屍對象
開啟Zombie模式之後會導致記憶體上升，因為所以已經被釋放（引用計數為0）的對象被殭屍對象取代，並未真的釋放掉。這個時候再給殭屍對象發送訊息，就會拋出異常，並列印出異常資訊，你可以輕鬆的找到錯誤碼位置，結束Zombies時會釋放。它的主要功能是檢測野指標調用。
使用方法：
“Edit Scheme…” —> “Run” —> “Diagnostics” —> “Zombie Objects”
開啟”Edit Scheme…”視窗：

開啟Zombie模式：

注意：Zombie模式不能再真機上使用，只能在模擬器上使用。
2、Address Sanitizer（地址消毒劑）
在Xcode7之後新增了AddressSanitizer工具，為我們調試EXC_BAD_ACCESS錯誤提供了便利。當程式建立變數分配一段記憶體時，將此記憶體後面的一段記憶體也凍結住，標識為中毒記憶體。程式訪問到中毒記憶體時（訪問越界），立即中斷程式，拋出異常並列印異常資訊。你可以根據中斷位置及輸出的Log資訊來解決錯誤。當然，如果變數已經釋放了，它所佔用的記憶體也會被標識為中毒記憶體，這個時候訪問這片記憶體空間同樣會拋出異常。
使用方法：
“Edit Scheme…” —> “Run” —> “Diagnostics” —> “Address Sanitizer”

開啟AddressSanitizer之後，在偵錯工具的過程中，如果有遇到EXC_BAD_ACCESS錯誤，程式則會自動終端，拋出異常。

3.Analyze分析器
Analyze分析器是一種靜態工具，可以對我們的程式進行分析，找出我們未使用的變數，或一些死儲存。執行Analyze如下：Product–>Analyze. 如下藍色的標記就是靜態分析的結果。

當然，我們可以設定在編譯器的時候同時Analyze，把下列選項設為Yes即可。

五、視圖調試

如今iOS開發的UI設計有很多種方式，比如storyboard，xib，代碼實現。對於stoayboard,xib可視化實現是比較簡單的，但是對於一些“iOS老程式員”而言，都喜歡使用代碼實現UI，並且可能UI層次還比較複雜。這樣就給我們新接手項目的開發人員帶來很多困擾。如何快速查看一個複雜UI的介面層次和布局，最快的方法就是用到視圖調試。
當項目運行到某一個介面（可以是模擬器或真機）時，開啟視圖調試，點擊按鈕

這樣就會進入試圖調試，你可以很方便的查看這個介面。這裡可以看到控制項之間的層次關係。

六、參考部落格地址：

instruments這裡不做介紹，請參考：
instruments來檢驗你的app
Memory Graph
iOS 開發調試技巧

在Xcode 7上直接使用Clang Address Sanitizer

Xcode 調試技巧

Xcode Debug技巧

iOS開發之Xcode常用調試技巧總結