使用Xcode和Instruments调试解决iOS内存泄漏

尽管iOS 5.0加入版本号之后ARC机制,由于相互引用关系是复杂的。内存泄漏可能仍然存在。于是,懂原理是非常重要的。

这里讲述在没有ARC的情况下,怎样使用Instruments来查找程序中的内存泄露。以及NSZombieEnabled设置的使用。

本文如果你已经比較熟悉Obj-C的内存管理机制。

实验的开发环境:XCode 4.5.2

1、执行Demo。

先下载一个实现准备好的内存泄露的Demo吧:leak app

下载下来。打开执行,程序是一个寿司的列表,列出各种寿司卷。试着选择里面的几行,应该是选第二行的时候就崩溃了。

崩溃截图:

使用Xcode和Instruments调试解决iOS内存泄漏

在崩溃的地方断住了,知道crash的地方了,可是不知道详细crash的原因。

2、设置NSZombieEnabled

这是一个 “EXC_BAD_ACCESS”错误。

我们打开XCode的选项:“NSZombieEnabled” 。在crash时可能会给你很多其它的一些提示信息。

设置步骤:1

使用Xcode和Instruments调试解决iOS内存泄漏

2:勾上红色框里的

使用Xcode和Instruments调试解决iOS内存泄漏

执行。按刚才的操作选中当中的cell。再次crash,这次在output窗体会看到多了一项错误信息:

2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0

大概意思是:向已释放的内存发送消息。

也就是说使用了已释放的内存。在C语言相当于使用了“野指针”

使用Xcode和Instruments调试解决iOS内存泄漏

看了下crash的这个语句,sushiString应该是没问题的,它是从stringWithFormat初始化出来的。那就是_lastSushiSelected的问题。

_lastSushiSelected指向了sushiString。sushiString是一个autorelease变量。 在第二次点击时。使用的是sushiString已经被释放,所以crash了。

那为_lastSushiSelected保留一下。就能够用了。

代码改动例如以下:

    _lastSushiSelected = [sushiString retain];

执行,这时候不崩溃。

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

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

使用Xcode和Instruments调试解决iOS内存泄漏

分析之后能够看到:

使用Xcode和Instruments调试解决iOS内存泄漏

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

[alertView release];

再分析,这个问题攻克了。

4、使用Instruments的leaks工具

分析内存泄露不能把全部的内存泄露查出来。有的内存泄露是在执行时。用户操作时才产生的。那就须要用到Instruments了。
使用Xcode和Instruments调试解决iOS内存泄漏 
按上面操作,build成功后跳出Instruments工具。选择Leaks选项,这时候寿司程序也执行起来了,选中list中的项,拖动等操作后,工具显示效果例如以下:
使用Xcode和Instruments调试解决iOS内存泄漏
大家可能都能猜到,红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?
先在工具栏按下红色的圆形button,把工具监视内存的活动停下来。

选择Leak,然后点中间十字交叉那,选择Call Tree.使用Xcode和Instruments调试解决iOS内存泄漏

这时候左下角的Call Tree的可选项能够选了。选中Invert Call Tree 和Hide System Libraries,显演示样例如以下:
使用Xcode和Instruments调试解决iOS内存泄漏
这时候内存泄露的详细代码找到了,在右边的红色框框里指定了哪个方法出现了内存泄露。
你仅仅要在这些方法上双击。就会跳转到详细的代码。哈哈,是不是非常方便。
使用Xcode和Instruments调试解决iOS内存泄漏
这里应该是提示100%内存会泄露。

6、解决内存泄露问题

问题找到了,那就解决吧

关于:tableView:didSelectRowAtIndexPath ,分析下它的内存过程:

  1. sushiString变量通过autorelease创建,它的引用计数是1.
  2. 这行代码使得引用计数添加到2, _lastSushiSelected = [sushiString retain];
  3. 这种方法结束时,sushiString的autorelease生效了,这个变量的引用计数降低为1
  4. 当再次执行tableView:didSelectRowAtIndexPath这种方法时,_lastSushiSelected被赋值了新指针,老的_lastSushiSelected的引用计数还是1,没有被释放。产生了内存泄露。

怎么解决呢?

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

[_lastSushiSelected release];
_lastSushiSelected = [sushiString retain];

关于:tableView:cellForRowAtIndexPath

这个比較明显。sushiString被alloc和init之后就没有释放。能够用stringWithFormat来调用autorelease,代码例如以下:

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

好了,泄露都fix了。再用工具分析看看。这时候你再点。再拖,再怎么操作。都没有内存泄露了。

表明内存泄露被堵住了。

这是本文修复好的app代码:no LeakApp

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

容芳志 (http://blog.csdn.net/totogo2010)

本文遵循“签名-非商业用途-一贯”创作共用协议

上一篇:一步步调试解决iOS内存泄漏


下一篇:linux环境下安装sphinx中文支持分词搜索(coreseek+mmseg)