一步步调试解决iOS内存泄漏

虽然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窗口会看到多了一项错误信息：

1	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保留一下，就可以用了。代码修改如下：

1	_lastSushiSelected = [sushiString retain];

运行，这时候不崩溃。

3、分析内存泄露(shift+command+b)

app不crash了，那看看有没有内存泄露。用XCode的Analyze就能分析到哪里有内存泄露

分析之后可以看到：

这里提示alertView没被释放，有内存泄露，那我们释放

1	[alertView release];

再分析，这个问题解决了。

4、使用Instruments的leaks工具

第一步:打开Xcode7自带的Instruments

或者:

按上面操作，build成功后跳出Instruments工具，选择Leaks选项

选择之后界面如下图:

到这里之后,我们前期的准备工作做完啦，下面开始正式的测试!

1.选中Xcode先把程序（command + R）运行起来

2.再选中Xcode，按快捷键（command + control + i）运行起来,此时Leaks已经跑起来了

3.由于Leaks是动态监测，所以我们需要手动操作APP,一边操作，一边观察Leaks的变化，当出现红色叉时，就监测到了内存泄露，点击右上角的第二个，进行暂停检测(也可继续检测，当多个时暂停，一次处理了多个).如图所示:

4.下面就是定位修改了,此时选中有红色柱子的Leaks，下面有个"田"字方格，点开，选中Call Tree

显示如下图界面

5.下面就是最关键的一步，在这个界面的右下角有若干选框，选中Invert Call Tree 和Hide System Libraries,（红圈范围内）显示如下：

到这里就算基本完成啦，这里显示的就是内存泄露代码部分，那么现在还差一步：定位!

6.选中显示的若干条中的一条，双击，会自动跳到内存泄露代码处，如图所示

7.找到了内存泄露的地方，那么我们就可以修改即可