轉(zhuǎn)自:http://www.cocoachina.com/ios/20141203/10519.html
雖然iOS 5.0版本之后加入了ARC機(jī)制,由于相互引用關(guān)系比較復(fù)雜時馁启,內(nèi)存泄露還是可能存在惯疙。所以了解原理很重要。
這里講述在沒有ARC的情況下对碌,如何使用Instruments來查找程序中的內(nèi)存泄露蒿偎,以及NSZombieEnabled設(shè)置的使用。
本文假設(shè)你已經(jīng)比較熟悉Obj-C的內(nèi)存管理機(jī)制骑脱。
實(shí)驗(yàn)的開發(fā)環(huán)境:XCode 4.5.2
1苍糠、運(yùn)行Demo
先下載一個實(shí)現(xiàn)準(zhǔn)備好的內(nèi)存泄露的Demo吧:leak app
下載下來,打開運(yùn)行拥娄,程序是一個壽司的列表瞳筏,列出各種壽司卷。試著選擇里面的幾行孟抗,應(yīng)該是選第二行的時候就崩潰了钻心。崩潰截圖:
在崩潰的地方斷住了捷沸,知道crash的地方了,但是不知道具體crash的原因说墨。
2苍柏、設(shè)置NSZombieEnabled
這是一個 “EXC_BAD_ACCESS”錯誤。我們打開XCode的選項(xiàng):“NSZombieEnabled” 棺棵。在crash時可能會給你更多的一些提示信息熄捍。
設(shè)置步驟:
運(yùn)行余耽,按剛才的操作選中其中的cell。再次crash币喧,這次在output窗口會看到多了一項(xiàng)錯誤信息:
2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0
大概意思是:向已釋放的內(nèi)存發(fā)送消息缕陕。也就是說使用了已釋放的內(nèi)存,在C語言相當(dāng)于使用了“野指針”
看了下crash的這個語句怜浅,sushiString應(yīng)該是沒問題的恶座,它是從stringWithFormat初始化出來的沥阳。那就是_lastSushiSelected的問題。
_lastSushiSelected指向了sushiString脉让,sushiString是一個autorelease變量。 在第二次點(diǎn)擊時溅潜,使用的是sushiString已經(jīng)被釋放滚澜,所以crash了。那為_lastSushiSelected保留一下借浊,就可以用了萝招。代碼修改如下:
1
_lastSushiSelected = [sushiString retain];
運(yùn)行,這時候不崩潰橡淆。
3母赵、分析內(nèi)存泄露(shift+command+b)
app不crash了,那看看有沒有內(nèi)存泄露师倔。用XCode的Analyze就能分析到哪里有內(nèi)存泄露
5e8b764f9f77f614057cd02723a58f67.jpg
分析之后可以看到:
這里提示alertView沒被釋放趋艘,有內(nèi)存泄露凶朗,那我們釋放
再分析,這個問題解決了搓萧。
4宛畦、使用Instruments的leaks工具
分析內(nèi)存泄露不能把所有的內(nèi)存泄露查出來,有的內(nèi)存泄露是在運(yùn)行時反肋,用戶操作時才產(chǎn)生的踏施。那就需要用到Instruments了罕邀。
按上面操作燃少,build成功后跳出Instruments工具铃在,選擇Leaks選項(xiàng)定铜,這時候壽司程序也運(yùn)行起來了怕敬,選中l(wèi)ist中的項(xiàng),拖動等操作后畸陡,工具顯示效果如下:
大家可能都能猜到虽填,紅色的柱子表示內(nèi)存泄露了。怎么通過這個工具看到在哪泄露了呢?
先在工具欄按下紅色的圓形按鈕牲览,把工具監(jiān)視內(nèi)存的活動停下來恶守。選擇Leak,然后點(diǎn)中間十字交叉那庸毫,選擇Call Tree.
這時候左下角的Call Tree的可選項(xiàng)可以選了衫樊。選中Invert Call Tree 和Hide System Libraries,顯示如下:
這時候內(nèi)存泄露的具體代碼找到了科侈,在右邊的紅色框框里指定了哪個方法出現(xiàn)了內(nèi)存泄露。
你只要在這些方法上雙擊刚盈,就會跳轉(zhuǎn)到具體的代碼挂脑,哈哈欲侮,是不是很方便威蕉。
這里應(yīng)該是提示100%內(nèi)存會泄露橄仍。
6侮繁、解決內(nèi)存泄露問題
問題找到了,那就解決吧
關(guān)于:tableView:didSelectRowAtIndexPath 宪哩,分析下它的內(nèi)存過程:
sushiString變量通過autorelease創(chuàng)建锁孟,它的引用計(jì)數(shù)是1.
這行代碼使得引用計(jì)數(shù)增加到2, _lastSushiSelected = [sushiString retain];
這個方法結(jié)束時储笑,sushiString的autorelease生效了圆恤,這個變量的引用計(jì)數(shù)減少為1
當(dāng)再次執(zhí)行tableView:didSelectRowAtIndexPath這個方法時,_lastSushiSelected被賦值了新指針赘方,老的_lastSushiSelected的引用計(jì)數(shù)還是1弱左,沒有被釋放拆火,產(chǎn)生了內(nèi)存泄露。
怎么解決呢?
在_lastSushiSelected = [sushiString retain];之前把原來的release就ok了:
[_lastSushiSelected release];
_lastSushiSelected = [sushiString retain];
關(guān)于:tableView:cellForRowAtIndexPath
這個比較明顯们镜,sushiString被alloc和init之后就沒有釋放,可以用stringWithFormat來調(diào)用autorelease颈抚,代碼如下:
NSString *sushiString = [NSString stringWithFormat:@"%d: %@", indexPath.row, sushiName];
好了嚼鹉,泄露都fix了驱富,再用工具分析看看褐鸥,這時候你再點(diǎn)赐稽,再拖,再怎么操作晰绎,都沒有內(nèi)存泄露了蠢莺。表明內(nèi)存泄露被堵住了零如。