雖然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"/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

         本文參考：http://www.raywenderlich.com/