一步步除錯解決iOS記憶體洩漏

容芳志的部落格發表於2014-12-03

雖然iOS 5.0版本之後加入了ARC機制,由於相互引用關係比較複雜時,記憶體洩露還是可能存在。所以瞭解原理很重要。

這裡講述在沒有ARC的情況下,如何使用Instruments來查詢程式中的記憶體洩露,以及NSZombieEnabled設定的使用。

本文假設你已經比較熟悉Obj-C的記憶體管理機制。

實驗的開發環境:XCode 4.5.2

1、執行Demo

先下載一個實現準備好的記憶體洩露的Demo吧:leak app

下載下來,開啟執行,程式是一個壽司的列表,列出各種壽司卷。試著選擇裡面的幾行,應該是選第二行的時候就崩潰了。崩潰截圖:

在崩潰的地方斷住了,知道crash的地方了,但是不知道具體crash的原因。

2、設定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保留一下,就可以用了。程式碼修改如下:

 _lastSushiSelected = [sushiString retain];

執行,這時候不崩潰。

3、分析記憶體洩露(shift+command+b)

app不crash了,那看看有沒有記憶體洩露。用XCode的Analyze就能分析到哪裡有記憶體洩露

分析之後可以看到:

這裡提示alertView沒被釋放,有記憶體洩露,那我們釋放

[alertView release];

再分析,這個問題解決了。

4、使用Instruments的leaks工具

分析記憶體洩露不能把所有的記憶體洩露查出來,有的記憶體洩露是在執行時,使用者操作時才產生的。那就需要用到Instruments了。
按上面操作,build成功後跳出Instruments工具,選擇Leaks選項,這時候壽司程式也執行起來了,選中list中的項,拖動等操作後,工具顯示效果如下:
大家可能都能猜到,紅色的柱子表示記憶體洩露了。怎麼通過這個工具看到在哪洩露了呢?
先在工具欄按下紅色的圓形按鈕,把工具監視記憶體的活動停下來。選擇Leak,然後點中間十字交叉那,選擇Call Tree.
這時候左下角的Call Tree的可選項可以選了。選中Invert Call Tree 和Hide System Libraries,顯示如下:
這時候記憶體洩露的具體程式碼找到了,在右邊的紅色框框裡指定了哪個方法出現了記憶體洩露。
你只要在這些方法上雙擊,就會跳轉到具體的程式碼,哈哈,是不是很方便。
這裡應該是提示100%記憶體會洩露。

6、解決記憶體洩露問題

問題找到了,那就解決吧

關於:tableView:didSelectRowAtIndexPath ,分析下它的記憶體過程:

  1. sushiString變數通過autorelease建立,它的引用計數是1.
  2. 這行程式碼使得引用計數增加到2, _lastSushiSelected = [sushiString retain];
  3. 這個方法結束時,sushiString的autorelease生效了,這個變數的引用計數減少為1
  4. 當再次執行tableView:didSelectRowAtIndexPath這個方法時,_lastSushiSelected被賦值了新指標,老的_lastSushiSelected的引用計數還是1,沒有被釋放,產生了記憶體洩露。

怎麼解決呢?

在_lastSushiSelected = [sushiString retain];之前把原來的release就ok了:

[_lastSushiSelected release];
    _lastSushiSelected = [sushiString retain];

關於:tableView:cellForRowAtIndexPath

這個比較明顯,sushiString被alloc和init之後就沒有釋放,可以用stringWithFormat來呼叫autorelease,程式碼如下:

NSString *sushiString = [NSString stringWithFormat:@"%d: %@", indexPath.row, sushiName];

好了,洩露都fix了,再用工具分析看看,這時候你再點,再拖,再怎麼操作,都沒有記憶體洩露了。表明記憶體洩露被堵住了。

相關文章