本文為投稿文章
鏈接：http://www.yangshebing.com/2016/10/27/iOS開發(fā)之Xcode常用調(diào)試（Debug）技巧總結(jié)/
一、Xcode調(diào)試技巧之：NSLog
上面也提到了,在我們?nèi)粘５拈_發(fā)過程中最常見的Debug方式就是打Log。而在OC語言中，打Log是采用NSLog方法。但是NSLog效率低下，具體原因可以看這篇博客（《NSLog效率低下的原因及嘗試lldb斷點打印Log》）。所以在平時的開發(fā)過程中，能不打Log就不打Log。實在想打Log網(wǎng)上也有對NSLog的一些優(yōu)化方法，可以閱讀王巍的《宏定義的黑魔法 - 宏菜鳥起飛手冊》如下代碼便出自其中：
另外在使用NSLog的時候應(yīng)當注意，release版本中應(yīng)該要去掉NSLog。
二、Xcode調(diào)試技巧之：LLDB
1、po：print object的縮寫，表示顯示對象的文本描述，如果對象不存在則打印nil。
簡單的打印一個對象我們就不說了，我們來說說特殊的應(yīng)用場景吧！
應(yīng)用場景：你想知道一個視圖包含了哪些子視圖。當然你可以循環(huán)打印子視圖，但是下面只需要一個命令即可解決。
輸出視圖層級關(guān)系（這是一個被隱藏的命令）:po [[self view] recursiveDescription]
還有個常見的調(diào)試場景，比如你要打印一個model。你直接用NSLog或po對象處理的結(jié)果是model的地址，這并不是我們想要的。怎么辦？有沒有解決方法呢？
答案是有的。你可以重寫model里面的description方法。但是，如果model里屬性非常多，這樣就不適用了。你不可能說在description方法里面拼接屬性返回。這樣不僅麻煩，而且可讀性非常差。到這里，我們可以利用runtime動態(tài)獲取屬性并返回。不過我并不建議你重寫description方法，我推薦你重寫debugDescription方法（至于詳細的介紹以及如何重寫請點擊此處），因為debugDescription方法和description方法效果一樣，區(qū)別在于debugDescription方法是在你使用po命令時調(diào)用的，實際上也是調(diào)用了description方法。
2、p:可以用來打印基本數(shù)據(jù)類型。
3、call:執(zhí)行一段代碼
call NSLog(@"%@", @"yang")
4、expr:動態(tài)執(zhí)行指定表達式
expr i = 101
輸出：(int)$0 = 101
5、bt:打印當前線程堆棧信息
如果要打印所以線程堆棧信息，使用:bt all即可。
6、image:常用來尋找棧地址對應(yīng)代碼位置：
舉個栗子：
應(yīng)用場景（數(shù)組越界）模擬代碼：
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
這個時候我們?nèi)绻麘岩沙鲥e的地址是0x0000000104c25550，那么我們可以使用下面命令來找出錯誤代碼的位置：
image lookup --address 0x0000000104c25550
執(zhí)行命令后輸出結(jié)果如下：
Address: BGMultimediaDemo[0x0000000100001550] (BGMultimediaDemo.__TEXT.__text + 192)
Summary: BGMultimediaDemo`-[ViewController viewDidLoad] + 192 at ViewController.m:30
從上面輸出結(jié)果中可以看出，錯誤位置應(yīng)該是ViewController.m文件中的30行。是不是超級好用？反正我覺得好用。
三、Xcode調(diào)試技巧之：斷點（Breakpoint）
斷點就不多說了，相信基本上都知道。
四、Xcode調(diào)試技巧之：EXC_BAD_ACCESS
1、開啟僵尸對象
開啟Zombie模式之后會導致內(nèi)存上升，因為所以已經(jīng)被釋放（引用計數(shù)為0）的對象被僵尸對象取代，并未真的釋放掉。這個時候再給僵尸對象發(fā)送消息，就會拋出異常，并打印出異常信息，你可以輕松的找到錯誤代碼位置，結(jié)束Zombies時會釋放。它的主要功能是檢測野指針調(diào)用。
使用方法：
“Edit Scheme…” —> “Run” —> “Diagnostics” —> “Zombie Objects”
打開”Edit Scheme…”窗口：
開啟Zombie模式：
注意：Zombie模式不能再真機上使用，只能在模擬器上使用。
2、Address Sanitizer（地址消毒劑）
在Xcode7之后新增了AddressSanitizer工具，為我們調(diào)試EXC_BAD_ACCESS錯誤提供了便利。當程序創(chuàng)建變量分配一段內(nèi)存時，將此內(nèi)存后面的一段內(nèi)存也凍結(jié)住，標識為中毒內(nèi)存。程序訪問到中毒內(nèi)存時（訪問越界），立即中斷程序，拋出異常并打印異常信息。你可以根據(jù)中斷位置及輸出的Log信息來解決錯誤。當然，如果變量已經(jīng)釋放了，它所占用的內(nèi)存也會被標識為中毒內(nèi)存，這個時候訪問這片內(nèi)存空間同樣會拋出異常。
使用方法：
“Edit Scheme…” —> “Run” —> “Diagnostics” —> “Zombie Objects”
開啟AddressSanitizer之后，在調(diào)試程序的過程中，如果有遇到EXC_BAD_ACCESS錯誤，程序則會自動終端，拋出異常。
