使用Xcode和Instruments調試解決iOS內存泄露

雖然iOS 5.0版本以後加入了ARC機制，因爲相互引用關係比較複雜時，內存泄露仍是可能存在。因此瞭解原理很重要。 這裏講述在沒有ARC的狀況下，如何使用Instruments來查找程序中的內存泄露，以及NSZombieEnabled設置的使用。 本文假設你已經比較熟悉Obj-C的內存管理機制。 實驗的開發環境：XCode 4.5.2 一、運行Demo。 先下載一個實現準備好的內存泄露的Demo吧：leak app 下載下來，打開運行，程序是一個壽司的列表，列出各類壽司卷。試着選擇裏面的幾行，應該是選第二行的時候就崩潰了。崩潰截圖： 在崩潰的地方斷住了，知道crash的地方了，可是不知道具體crash的緣由。 二、設置NSZombieEnabled 這是一個 「EXC_BAD_ACCESS」錯誤。咱們打開XCode的選項：「NSZombieEnabled」 。在crash時可能會給你更多的一些提示信息。 設置步驟：1 2：勾上紅色框裏的 運行，按剛纔的操做選中其中的cell。再次crash，此次在output窗口會看到多了一項錯誤信息： 2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0 大概意思是：向已釋放的內存發送消息。也就是說使用了已釋放的內存，在C語言至關於使用了「野指針」 看了下crash的這個語句，sushiString應該是沒問題的，它是從stringWithFormat初始化出來的。那就是_lastSushiSelected的問題。 _lastSushiSelected指向了sushiString，sushiString是一個autorelease變量。 在第二次點擊時，使用的是sushiString已經被釋放，因此crash了。那爲_lastSushiSelected保留一下，就能夠用了。代碼修改以下： 01.<span style="font-size: 14px;"> _lastSushiSelected = [sushiString retain];  02.</span>  運行，這時候不崩潰。 三、分析內存泄露(shift+command+b) app不crash了，那看看有沒有內存泄露。用XCode的Analyze就能分析到哪裏有內存泄露 分析以後能夠看到： 這裏提示alertView沒被釋放，有內存泄露，那咱們釋放 [alertView release]; 再分析，這個問題解決了。 四、使用Instruments的leaks工具 分析內存泄露不能把全部的內存泄露查出來，有的內存泄露是在運行時，用戶操做時才產生的。那就須要用到Instruments了。 按上面操做，build成功後跳出Instruments工具，選擇Leaks選項，這時候壽司程序也運行起來了，選中list中的項，拖動等操做後，工具顯示效果以下： 你們可能都能猜到，紅色的柱子表示內存泄露了。怎麼經過這個工具看到在哪泄露了呢? 先在工具欄按下紅色的圓形按鈕，把工具監視內存的活動停下來。選擇Leak，而後點中間十字交叉那，選擇Call Tree. 這時候左下角的Call Tree的可選項能夠選了。選中Invert Call Tree 和Hide System Libraries,顯示以下： 這時候內存泄露的具體代碼找到了，在右邊的紅色框框裏指定了哪一個方法出現了內存泄露。 你只要在這些方法上雙擊，就會跳轉到具體的代碼，哈哈，是否是很方便。 這裏應該是提示100%內存會泄露。 六、解決內存泄露問題 問題找到了，那就解決吧 關於：tableView:didSelectRowAtIndexPath ，分析下它的內存過程： sushiString變量經過autorelease建立，它的引用計數是1.  這行代碼使得引用計數增長到2， _lastSushiSelected = [sushiString retain]; 這個方法結束時，sushiString的autorelease生效了，這個變量的引用計數減小爲1 當再次執行tableView:didSelectRowAtIndexPath這個方法時，_lastSushiSelected被賦值了新指針，老的_lastSushiSelected的引用計數仍是1，沒有被釋放，產生了內存泄露。 怎麼解決呢? 在_lastSushiSelected = [sushiString retain];以前把原來的release就ok了: 01.[_lastSushiSelected release];  02. _lastSushiSelected = [sushiString retain];  關於：tableView:cellForRowAtIndexPath 這個比較明顯，sushiString被alloc和init以後就沒有釋放，能夠用stringWithFormat來調用autorelease，代碼以下： 01.NSString *sushiString = [NSString stringWithFormat:@"%d: %@", indexPath.row, sushiName];  好了，泄露都fix了，再用工具分析看看，這時候你再點，再拖，再怎麼操做，都沒有內存泄露了。代表內存泄露被堵住了。