使用Xcode Instruments Leak解決內存泄漏問題

　　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程序也運行起來了,工具顯示效果以下：

 　　紅色的柱子表示內存泄露了。怎麼經過這個工具看到在哪泄露了呢?

　　 先在工具欄按下紅色的圓形按鈕，把工具監視內存的活動停下來。選擇Leak，而後點中間十字交叉那，

　　選擇Call Tree　　　

　　 　　　

　　這時候右下角的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中其餘工具的用法。