原文出處：wu大維 php
NSLog,po命令和普通斷點調試相信每一個iOS開發者都會，這裏就不做介紹了。html 1、Memory Graph Xcode8新增：Memory Graph解決閉包引用循環問題ios 
這個時候就進入了斷點模式，能夠查看issue面板，注意選擇右邊Runtime：c++
有不少歎號說明就有問題了。看內存中object的名字，有一條是Closure captures leaked。展開後點擊就能夠看到這個issue對應的內存圖形展現在中間的面板中。固然了，咱們更多的時候是在debug頁面下查看：程序員
因此，這裏面引用循環了。點擊紫色的歎號會出現Xcode分析出來的內存引用圖形：數組
有了這個圖就很容易看出來了：這裏有個引用循環xcode 順便提一下，經過在Arguments中設置參數，打印出App加載的時長，包括總體加載時長，動態庫加載時長等。閉包 在Environment Variables中添加DYLD_PRINT_STATISTICS字段，並設置爲YES，在控制檯就會打印加載時長。app
2、Xcode調試技巧之：LLDB
一、po：print object的縮寫，表示顯示對象的文本描述，若是對象不存在則打印nil。
簡單的打印一個對象咱們就不說了，咱們來講說特殊的應用場景吧！
應用場景：你想知道一個視圖包含了哪些子視圖。固然你能夠循環打印子視圖，可是下面只須要一個命令便可解決。
輸出視圖層級關係（這是一個被隱藏的命令）:異步
| 1 |
po [[self view] recursiveDescription]
|
還有個常見的調試場景，好比你要打印一個model。你直接用NSLog或po對象處理的結果是model的地址，這並非咱們想要的。怎麼辦？有沒有解決方法呢？
答案是有的。你能夠重寫model裏面的description方法。可是，若是model裏屬性很是多，這樣就不適用了。你不可能說在description方法裏面拼接屬性返回。這樣不只麻煩，並且可讀性很是差。到這裏，咱們能夠利用runtime動態獲取屬性並返回。不過我並不建議你重寫description方法，我推薦你重寫debugDescription方法（至於詳細的介紹以及如何重寫請點擊此處），由於debugDescription方法和description方法效果同樣，區別在於debugDescription方法是在你使用po命令時調用的，實際上也是調用了description方法。
二、p:能夠用來打印基本數據類型。
三、call:執行一段代碼
| 1 2 3 4 5 |
call NSLog(@
"%@"
, @
"yang"
)
|
四、expr:動態執行指定表達式
| 1 2 |
expr i = 101
輸出：(int)$0 = 101
|
五、bt:打印當前線程堆棧信息
若是要打印因此線程堆棧信息，使用:bt all便可。
六、image:經常使用來尋找棧地址對應代碼位置：
舉個栗子：
應用場景（數組越界）模擬代碼：
| 1 2 |
NSArray *array = @[@"yang",@"she",@"bing"];
NSLog(@"%@",array[3]);
|
錯誤信息以下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
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，那麼咱們可使用下面命令來找出錯誤代碼的位置：
| 1 |
image lookup --address 0x0000000104c25550
|
執行命令後輸出結果以下：
| 1 2 |
Address: BGMultimediaDemo[0x0000000100001550] (BGMultimediaDemo.TEXT.text + 192)
Summary: BGMultimediaDemo`-[ViewController viewDidLoad] + 192 at ViewController.m:30
|
從上面輸出結果中能夠看出，錯誤位置應該是ViewController.m文件中的30行。是否是超級好用？反正我以爲好用。 3、Xcode調試技巧之：斷點（Breakpoint）
斷點，程序員Debug必備技之一。
一、條件斷點
打上斷點以後，對斷點進行編輯，設置相應過濾條件。下面簡單的介紹一下條件設置：
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選項)：選中後，表示斷點不會終止程序的運行。
二、異常斷點
異常斷點能夠快速定位不知足特定條件的異常，好比常見的數組越界，這時候很難經過異常信息定位到錯誤所在位置。這個時候異常斷點就能夠發揮做用了。
添加異常斷點：
編輯異常斷點：
Exception：能夠選擇拋出異常對象類型：OC或C++。
Break：選擇斷點接收的拋出異常來源是Throw仍是Catch語句。
三、符號斷點
符號斷點的建立方式和異常斷點同樣同樣的，在符號斷點中能夠指定要中斷執行的方法：
舉個例子，常見的場景，我想讓它執行到ViewController類中的viewWillAppear方法就中斷執行：
Symbol:[ViewController viewWillAppear:]即[類名 方法名]能夠執行到指定類的指定方法中開始斷點。若是隻有viewWillAppear:即方法名，它會執行到因此類中的viewWillAppear:方法中開始斷點。
四、監控斷點
咱們調試程序的大部分時候都是爲了監控某個變量的變化，在代碼中變量出現的地方添加斷點不只累並且還可能漏掉，過後還得一個一個刪掉，實在很累。
咱們能夠經過爲變量添加監控斷點來簡單地作到這一點。找到變量第一次出現的地方，添加一個普通斷點，進入 debug 模式後在 Variables View 中右鍵變量，選擇 Watch 變量名。這樣，每一次該變量被改變都會觸發斷點告知咱們。 4、Xcode調試技巧之：EXC_BAD_ACCESS
一、開啓殭屍對象
開啓Zombie模式以後會致使內存上升，由於因此已經被釋放（引用計數爲0）的對象被殭屍對象取代，並未真的釋放掉。這個時候再給殭屍對象發送消息，就會拋出異常，並打印出異常信息，你能夠輕鬆的找到錯誤代碼位置，結束Zombies時會釋放。它的主要功能是檢測野指針調用。
使用方法：
「Edit Scheme…」 —> 「Run」 —> 「Diagnostics」 —> 「Zombie Objects」
打開」Edit Scheme…」窗口：
開啓Zombie模式：
注意：Zombie模式不能再真機上使用，只能在模擬器上使用。
二、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的界面層次和佈局，最快的方法就是用到視圖調試。
當項目運行到某一個界面（能夠是模擬器或真機）時，開啓視圖調試，點擊按鈕如圖：
這樣就會進入試圖調試，你能夠很方便的查看這個界面。這裏能夠看到控件之間的層次關係。 6、參考博客地址：
instruments這裏不作介紹，請參考：
instruments來檢驗你的app
Memory Graph
iOS 開發調試技巧 在Xcode 7上直接使用Clang Address Sanitizer Xcode 調試技巧 Xcode Debug技巧 原文http://bbs.520it.com/forum.php?mod=viewthread&tid=2793 |