雖然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保留一下,就可以用了。代碼修改如下:
- <span style="font-size:14px;"> _lastSushiSelected = [sushiString retain];
- </span>
運行,這時候不崩潰。
3、分析內存泄露(shift+command+b)
app不crash了,那看看有沒有內存泄露。用XCode的Analyze就能分析到哪裏有內存泄露
分析之後可以看到:
這裏提示alertView沒被釋放,有內存泄露,那我們釋放
[alertView release];
再分析,這個問題解決了。
4、使用Instruments的leaks工具
6、解決內存泄露問題
關於:tableView:didSelectRowAtIndexPath ,分析下它的內存過程:
- sushiString變量通過autorelease創建,它的引用計數是1.
- 這行代碼使得引用計數增加到2, _lastSushiSelected = [sushiString retain];
- 這個方法結束時,sushiString的autorelease生效了,這個變量的引用計數減少爲1
- 當再次執行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了,再用工具分析看看,這時候你再點,再拖,再怎麼操作,都沒有內存泄露了。表明內存泄露被堵住了。
這是本文修復好的app代碼:no LeakApp