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一次，這時候記憶體洩露的具體程式碼找到了，下面的紅色框框裡指定了那個方法出現了記憶體洩露。