本文為投稿文章，作者：楊社兵

最近在面試，面試過程中問到了一些Xcode常用的調試技巧問題。平常開發過程中用的還挺順手的，但你要突然讓我說，確實一臉懵逼。Debug的技巧很多，比如最常見的方式是打個Log，在一些工程中處處可見NSLog。還有就是打斷點的Debug方式等。諸如此類，下面就自己在開發過程中常用的Xcode調試技巧簡單的做個總結。

一、Xcode調試技巧之：NSLog

上面也提到了,在我們日常的開發過程中最常見的Debug方式就是打Log。而在OC語言中，打Log是采用NSLog方法。但是NSLog效率低下，具體原因可以看這篇博客（《NSLog效率低下的原因及嘗試lldb斷點打印Log》）。所以在平時的開發過程中，能不打Log就不打Log。實在想打Log網上也有對NSLog的一些優化方法，可以閱讀王巍的《宏定義的黑魔法 - 宏菜鳥起飛手冊》如下代碼便出自其中：

#define NSLog(format, ...) do {                                             \
fprintf(stderr, " %s\n",                                           \
[[[NSString stringWithUTF8String:__FILE__] lastPathComponent] UTF8String],  \
__LINE__, __func__);                                                        \
(NSLog)((format), ##__VA_ARGS__);                                           \
fprintf(stderr, "-------\n");                                               \
} while (0)

另外在使用NSLog的時候應當注意，release版本中應該要去掉NSLog。

二、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:可以用來打印基本數據類型。

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]'
*** First throw call stack:
(
0   CoreFoundation                      0x000000010579734b __exceptionPreprocess + 171
1   libobjc.A.dylib                     0x00000001051f821e objc_exception_throw + 48
2   CoreFoundation                      0x00000001056d1eeb -[__NSArrayI objectAtIndex:] + 155
3   BGMultimediaDemo                    0x0000000104c25550 -[ViewController viewDidLoad] + 192
4   UIKit                               0x0000000105d5c06d -[UIViewController loadViewIfRequired] + 1258
......
......
......
21  BGMultimediaDemo                    0x0000000104c25adf main + 111
22  libdyld.dylib                       0x000000010857268d start + 1
23  ???                                 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught 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:方法中開始斷點。

四、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” —> “Zombie Objects”

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

五、結語

文中提到的這些只是iOS開發過程中比較常見的一部分Debug方式。其他的還有比如說：Profile，Analyze分析，View Hierarchy（在調試視圖顯示異常時用的比較多）等，有興趣的可以自行了解。

本文內容中部分來自網絡，後續會不斷更新完善。歡迎一起學習交流！

六、參考博客地址：

• iOS 開發調試技巧

• 與調試器共舞 - LLDB 的華爾茲

• Xcode7新特性AddressSanitizer

• 在Xcode 7上直接使用Clang Address Sanitizer

• Xcode 調試技巧

• Xcode Debug技巧