ios Instruments 內存泄露 – iPhone手機開發技術文章 iPhone軟體開發教學課程

雖然iOS 5.0版本之後加入瞭ARC機制,由於相互引用關系比較復雜時,內存泄露還是可能存在。所以瞭解原理很重要。

這裡講述在沒有ARC的情況下,如何使用Instruments來查找程序中的內存泄露,以及NSZombieEnabled設置的使用。

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

實驗的開發環境:XCode 4.5.2

1、運行Demo。

先下載一個實現準備好的內存泄露的Demo吧:leak
app

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

vcHLo6y1q8rHsrvWqrXAvt/M5WNyYXNotcTUrdLyoaM8L3A+CjxwPgo8YnI+CjwvcD4KPGgxPjKhosno1sNOU1pvbWJpZUVuYWJsZWQ8L2gxPgo8cD4K1eLKx9K7uPYgobBFWENfQkFEX0FDQ0VTU6GxtO3O86GjztLDx7Tyv6pYQ29kZbXE0aHP7qO6obBOU1pvbWJpZUVuYWJsZWShsSCho9TaY3Jhc2jKsb/JxNy74bj4xOO4/LbgtcTSu9CpzOHKvtDFz6KhozwvcD4KPHA+Csno1sOyvdboo7oxPC9wPgo8cD4KPGltZyBzcmM9″https://www.aiwalls.com/uploadfile/Collfiles/20140410/201404100931385.png” alt=”\”>

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保留一下,就可以用瞭。代碼修改如下:

[cpp] view
plaincopy

  1. _lastSushiSelected = [sushiString retain];

  2. 運行,這時候不崩潰。

    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 ,分析下它的內存過程:

    sushiString變量通過autorelease創建,它的引用計數是1. 這行代碼使得引用計數增加到2, _lastSushiSelected = [sushiString retain];這個方法結束時,sushiString的autorelease生效瞭,這個變量的引用計數減少為1當再次執行tableView:didSelectRowAtIndexPath這個方法時,_lastSushiSelected被賦值瞭新指針,老的_lastSushiSelected的引用計數還是1,沒有被釋放,產生瞭內存泄露。

    怎麼解決呢?

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

    [cpp] view
    plaincopy

    1. [_lastSushiSelected release];

    2. _lastSushiSelected = [sushiString retain];

      關於:tableView:cellForRowAtIndexPath

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

      [cpp] view
      plaincopy

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

        好瞭,泄露都fix瞭,再用工具分析看看,這時候你再點,再拖,再怎麼操作,都沒有內存泄露瞭。表明內存泄露被堵住瞭。

        這是本文修復好的app代碼:no
        LeakApp

        本文參考:https://www.raywenderlich.com/

發佈留言