ACCESSxcode怎样分析检测内存泄露(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时说不定会见受您重新多的有的提示信息。

运作,按刚才的操作选中中的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工具

 

剖析内存泄露不克管持有的内存泄露查出来,有的内存泄露是在运行时,用户操作时才发的。那即便需要用到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了:

1

2

[_lastSushiSelected release];

    _lastSushiSelected = [sushiString retain];

关于:tableView:cellForRowAtIndexPath

以此比较显然,sushiString被alloc和init之后便不曾放,可以就此stringWithFormat来调用autorelease,代码如下:

1

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

 

哼了,泄露都fix了,再用工具分析看,这时候若还接触,再拖,再怎么操作,都尚未内存泄露了。表明内存泄露为阻碍了。

上述原文链接:http://www.cocoachina.com/ios/20141203/10519.html

本来有时就是设置了地方的兼具为说不定检测不起些许内存泄露问题,可以当debug模式下,把代码放在你展望或者会见出现内存泄露的近乎中,下面的此针对:respondsToSelector
被release了,定位不顶的时刻。

#ifdef _FOR_DEBUG_

-(BOOL) respondsToSelector:(SEL)aSelector {

    printf(“SELECTOR: %s\n”, [NSStringFromSelector(aSelector)
UTF8String]);

    return [super respondsToSelector:aSelector];

}

 

#endif

 

相关文章