來源:http://blog.csdn.net/totogo2010/article/details/8233565
為曹妃甸等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務,及曹妃甸網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都網(wǎng)站建設、網(wǎng)站建設、曹妃甸網(wǎng)站設計,以傳統(tǒng)方式定制建設網(wǎng)站,并提供域名空間備案等一條龍服務,秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求,就會得到認可,從而選擇與我們長期合作。這樣,我們也可以走得更遠!
雖然iOS 5.0版本之后加入了ARC機制,由于相互引用關系比較復雜時,內(nèi)存泄露還是可能存在。所以了解原理很重要。
這里講述在沒有ARC的情況下,如何使用Instruments來查找程序中的內(nèi)存泄露,以及NSZombieEnabled設置的使用。
本文假設你已經(jīng)比較熟悉Obj-C的內(nèi)存管理機制。
實驗的開發(fā)環(huán)境:XCode 4.5.2
先下載一個實現(xiàn)準備好的內(nèi)存泄露的Demo吧:leak app
下載下來,打開運行,程序是一個壽司的列表,列出各種壽司卷。試著選擇里面的幾行,應該是選第二行的時候就崩潰了。崩潰截圖:
在崩潰的地方斷住了,知道crash的地方了,但是不知道具體crash的原因。
這是一個 “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
大概意思是:向已釋放的內(nèi)存發(fā)送消息。也就是說使用了已釋放的內(nèi)存,在C語言相當于使用了“野指針”
看了下crash的這個語句,sushiString應該是沒問題的,它是從stringWithFormat初始化出來的。那就是_lastSushiSelected的問題。
_lastSushiSelected指向了sushiString,sushiString是一個autorelease變量。 在第二次點擊時,使用的是sushiString已經(jīng)被釋放,所以crash了。那為_lastSushiSelected保留一下,就可以用了。代碼修改如下:
運行,這時候不崩潰。
app不crash了,那看看有沒有內(nèi)存泄露。用XCode的Analyze就能分析到哪里有內(nèi)存泄露
分析之后可以看到:
這里提示alertView沒被釋放,有內(nèi)存泄露,那我們釋放
[alertView release];
再分析,這個問題解決了。
怎么解決呢?
在_lastSushiSelected = [sushiString retain];之前把原來的release就ok了:
這個比較明顯,sushiString被alloc和init之后就沒有釋放,可以用stringWithFormat來調用autorelease,代碼如下:
好了,泄露都fix了,再用工具分析看看,這時候你再點,再拖,再怎么操作,都沒有內(nèi)存泄露了。表明內(nèi)存泄露被堵住了。
這是本文修復好的app代碼:no LeakApp
本文參考:http://www.raywenderlich.com/
新聞標題:使用Xcode和Instruments調試解決iOS內(nèi)存泄露
分享URL:http://jinyejixie.com/article2/jopcoc.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供外貿(mào)建站、網(wǎng)站策劃、品牌網(wǎng)站建設、做網(wǎng)站、企業(yè)網(wǎng)站制作、標簽優(yōu)化
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)