iOS-xcode記憶體泄露 檢查靜態/動態

靜態：

在project-setting中找到 “Run Static Analyzer” 鍵，然後把值修改為“YES”.這樣在編碼的時候，xcode就可以自動為我們檢查記憶體泄露了.

動態：

Xcode 4.2找了半天，才找到Instruments在哪裡：Product-》profile 

EXC_BAD_ACCESS錯誤，我通常建議:

　　1.在可執行選項中設定NSZombieEnabled參數,這有時會幫縮小問題的範圍；

　　2.運行apple的記憶體偵查工具,如 Leaks ，以便尋找記憶體問題；

　　3設定一個斷點，單步運行代碼,直到你找到引起崩潰的位置；

　　4.注釋代碼，直到不崩潰為止，然後再從後往前尋找錯誤；

　　現在讓我們從第一條開始實驗

    NSZombieEnabled選項對於崩潰毫無辦法,所以你完全可以放棄抵抗。

 當你使用一個已經被銷毀的對象,NSZombieEnabled會標誌一個警告，所以NSZombieEnabled只是一個flag。這是一個良好的開端，因為大多數崩潰的原因都是使用了已經銷毀的對象。

　　按照以下設定：

點擊OK, 重新運行app，隨便操作下使程式崩潰。 查看下consolelog你就會看到類似如下資訊:

2011-02-03 12:07:44.778 XXXX ***-[XXXXX:]: message sent to deallocated instance ...2.記憶體流失最簡單的辦法就是：（快速鍵:command+shift+b）你會看到如：怎麼修改，自己慢慢按提示一步一步改不幸的是,你不能依靠以上方法找出一切問題。我們還得使用一個強大的自動化工具來協助你檢查程式是否有記憶體流失– the Leaks Instrument。接下來就是代開Leaks Instrument工具，如：選中Leaks，點擊Profile,出現以下試圖，點擊stop(紅色的那個)，設定調試參數：（選擇Leaks,選擇Call Tree, 選中如的的3個複選框），然後點擊(Record)按鈕 重啟，淡紅色那條就代表記憶體流失了，下面兩個不同的函數就表示存在記憶體流失的函數， 雙擊一個函數的名字,它會帶你直接到存在記憶體泄露的這行代碼。這可以給你一個很好的錯誤位置提示,如果你查看代碼並加以思考,你應該能夠找出問題所在並解決它。

　　所以,為什麼不看看代碼,並且看看你是否能找出問題所在並修正嗎?一旦你作出修改,並且能夠無錯誤提示的跑Leaks。如果通過，表示你完成了