Instruments指南：如何调试内存泄露

开篇

现在，你应该使用的ARC，而不是原来我们使用的MRC或者其他。但是我们在使用ARC的时候也会出现内存泄露的情况。

幸运的是，苹果为我们提供了Instruments，他可以用来检测你的应用程序的内存泄露。可能刚学习iOS开发的开发者被这个工具给吓到了，里面有太多东西了。其实他们是非常了不起的，而且也非常容易使用。

在这篇文章里，你将会通过使用XCode和Instruments来调试和发现内存相关的问题（例如内存泄露）。

开始使用

我们这篇文章的目标就是用一个小demo应用程序检查和解决我们经常遇到的通常的内存相关的错误。demo下载地址：http://pan.baidu.com/s/1c0tvFGk （参考别人的，比较老）

打开Xcode，然后运行小demo,试着去点击几个cell，我们会发现它爆了，你得到的是一个可怕地EXC_BAD_ACCESS错误，调试器没有什么帮助去解决这个错误。

对于许多开发者来说这是很令人沮丧的。因为不清楚问题出在哪里。下面是给开发者的一些建议当你遇到EXC_BAD_ACCESS错误的时候：

设置Enable Zombie Objects参数，在可执行选项，这有时候有助于缩小问题原因。具体设置方法是点击运行右边的项目，然后选择Edit Scheme。在Run选项的Diagnositics中设置Enable Zombie Objects。然后Close。再次运行，可能会出现一些问题提示。
使用苹果的Instruments，例如Leaks来查看内存问题。
在你的代码中设置断点，然后一步一步执行直到接近crash的地方。
尝试注释掉相关的代码，然后直到它工作，然后回溯。

僵尸入侵

不幸的是，NSZombieEnabled选项没有对僵尸启示做任何事情，所以你可以抛弃这种方法了。当你使用ENable Zombie Objects时，我们再次运行APP,会发现有下列提示：

2015-08-08 21:37:28.657 PropMemFun[8190:3281809] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x7f8251c07890

这时候我们会定位到这句代码：

 NSString * message = [NSString stringWithFormat:@"Last sushi: %@.  Cur sushi: %@", _lastSushiSelected, sushiString];

Bingo！这时候我们知道问题在这行，一个消息发送给了一个已经释放的string。这行使用了_lastSushiSelected和sushiString。此时sushiString是正常的因为我们在上边定义了。那么问题就可能出现在_lastSushiSelected上。因为sushiString是自动释放变量，所以_lastSushiSelected指向他的时候已经被释放了。因此添加

   _lastSushiSelected = [sushiString retain];

即可解决问题。再次运行发现问题解决。

Build,Analyze 和Recognize

没有了Crash我们现在看一下是否有内存泄露。通过Product-->Analyze，我们可以看到有两处内存泄露。分别在

return cell;

和

- (void)viewDidUnload {

    [_sushiTypes release];

    _sushiTypes = nil;

}

泄露和水管工(Leaks and Plumbers)

现在我们就使用Instruments。

第一步：首先我们打开Instruments。(按着control+空格键，输入instruments即可打开（也可以Product-->Profile打开）我这边测试用Product-->Profile打开不能定位带具体内存泄露代码)。
第二步：选择Leaks,然后Choose。
第三步：通过暂停右边的选择我们可以选择正在运行的程序。然后点击Record（红色圆圈按钮）
第四步：观察，我们可以发现在Leaks里面有一个红色圆柱，这说明了我们的APP存在内存泄露。
第五步：点击暂停，然后我们开始分析。

在Instruments下方的控制台中，我们把Leaks(如果是Allocation就点击选择Leaks)右边的选项Statistics选择为Call Trees。然后点击右边Call Tree设置，勾选Invert Call Tree 和Hide System Libraries。我们会发现显示出来的是一个消息名称。它将会带你到内存泄露的地方。双击那个消息即可。然后你就可以检查一下那里的代码，然后思考一下，你应该能发现和解决这个问题。然后解决过后重新运行Leaks去检测是否还会有内存泄露。

总结

以上就是利用Instruments如何查找内存泄露。