iOS 5.0之后apple引入了Xcode編譯器特性ARC（Automatic Reference Counting，自動引用計數）來幫助開發者管理內存，但為了追求app的高性能與減少安裝包大小，工作中很多時候需要我們手動管理內存。再牛的開發者也不能保證自己寫的code 100%沒有內存泄露，出現內存泄露不可怕，可怕的是我們時間與精力花了大把，但內存泄露依舊沒解決,即影響了工作效率也影響自己的心情。
下面就講解xcode中的內存調試神器---Instruments Leak ，不管是ios開發菜鳥，還是有經驗的開發者，使用Instruments Leak調試內存泄露是必備技能之一。
廢話少說，下面開始攤大餅了！！!
step1:
創建一個基於ARC的測試demo,部分測試代碼如下：
以上幾行代碼作為app代理入口method，IOS開發者應該是最熟悉不過了，由於創建的是手動管理內存工程，內存泄露的code line一眼就可以定位。
step2：
使用Leaks開始動態分析，點擊XCode的Product菜單Profile啟動Instruments：
點擊Profile Button編譯，呵呵，報錯了，如果你遇到這種情況也不要緊張，先看下報錯信息:
MyViewController與MyNavigationController是我在.pch預編譯文件中定義的宏：
為什么正常編譯就沒問題，在Profile 中就編譯通不過了，其實這里並不是你的代碼寫的有問題，問題出在Profile的一個編譯選項上：打開工
程的Edit Scheme選項
選擇Profile，將Build Configuration設置為Debug,這樣在.pch文件中，#ifdef DEBUG 編譯條件下定義的宏就生效 了。
再次選擇Profile building，OK， Success ！！！
step3:
進入Instruments主頁面，選擇Leak Logo
step4:
這時Demo程序也運行起來了,工具顯示效果如下：
紅色的柱子表示內存泄露了。怎么通過這個工具看到在哪泄露了呢?
這時候右下角的Call Tree的可選項可以選了。選中Invert Call Tree 和Hide System Libraries,顯示如下：
看到這里，你最想知道的應該是項目中哪里的code內存泄漏了，ok, 下面我們就來定位內存泄漏的code line .
step5:
看上圖中紅色框中的Symbol Name 列，如果你猜想0xedc00與0xedbda是內存地址，那么已經很接近正確答案了，可是這東西對我來說有卵用。其實玄機就隱藏在這里，Xcode編譯項目后，我們會看到一個同名的 dSYM文件，dSYM 是保存 16 進制函數地址映射信息的中轉文件，我們調試的 symbols 都會包含在這個文件中，並且每次編譯項目的時候都會生成一個新的 dSYM 文件，關於dSYM更多的細節，我將在后面的blog中說明。回到上面的問題，顯示0xedc00與0xedbda是因為我們的工程build settings 的問題，沒有生成dSYM 文件，也就無法解析debug symbols。下面我們就來正確設置dSYM選項：
設置好之后，重新 profile build一次，這時候內存泄露的具體代碼找到了，下面的紅色框框里指定了那個方法出現了內存泄露。
step6:
解決內存泄漏問題，將創建的vc對象release掉就OK了，再用Instruments Leak工具分析看看，這時候再怎么操作，都沒有內存泄露了。表明內存泄露被堵住了。
大餅攤完了，最后附上《Instruments 用戶指南》有興趣的同學可以研究一下Instruments中其他工具的用法。