xcode怎么样分析检测内存泄露(iOS)

即使iOS
5.0版本之后参与了ARC机制,由于互动引用关系相比较复杂时,内存泄露还是可能存在。所以领会原理很要紧。

此间讲述在一直不ARC的状态下,怎么着利用Instruments来搜寻程序中的内存泄露,以及NSZombieEnabled设置的使用。

本文假如你早就相比较熟知Obj-C的内存管理机制。

试行的开销条件:XCode 4.5.2

1、运行Demo

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

下载下来,打开运行,程序是一个寿司的列表,列出各种寿司卷。试着选拔其中的几行,应该是选第二行的时候就崩溃了。崩溃截图:

图片 1

在崩溃的地点断住了,知道crash的地点了,然而不了解具体crash的因由。

2、设置NSZombieEnabled

那是一个 “EXC_BAD_ACCESS”错误。咱们开辟XCode的选项:“NSZombieEnabled” 。在crash时或许会给你更多的片段指示音讯。

图片 2

运行,按刚才的操作选中内部的cell。再一次crash,这一次在output窗口会师到多了一项错误消息:

1

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

 

大致意思是:向已出狱的内存发送信息。也就是说使用了已放出的内存,在C语言相当于接纳了“野指针”

图片 3

看了下crash的这多少个讲话,sushiString应该是没问题的,它是从stringWithFormat起初化出来的。这就是_lastSushiSelected的问题。

_lastSushiSelected指向了sushiString,sushiString是一个autorelease变量。 在第二次点击时,使用的是sushiString已经被放走,所以crash了。那为_lastSushiSelected保留一下,就足以用了。代码修改如下:

1

 _lastSushiSelected = [sushiString retain];

运作,那时候不崩溃。

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

 

app不crash了,那看看有没有内存泄露。用XCode的Analyze就能分析到什么地方有内存泄露

图片 4

分析将来可以阅览:

图片 5

这边提醒alertView没被释放,有内存泄露,这我们释放

1

[alertView release];

再分析,那一个题材解决了。

4、使用Instruments的leaks工具

 

分析内存泄露不可能把所有的内存泄露查出来,有的内存泄露是在运行时,用户操作时才发出的。这就需要用到Instruments了。

图片 6

按下面操作,build成功后跳出Instruments工具,选取Leaks选项,这时候寿司程序也运行起来了,选中list中的项,拖动等操作后,工具显示效果如下:

图片 7

我们或许都能猜到,藏绿色的柱子表示内存泄露了。怎么通过这些工具看到在哪泄露了吗?

 

先在工具栏按下红色的圆形按钮,把工具监视内存的活动停下来。拔取Leak,然后点中间十字交叉这,采取Call
Tree.

图片 8

此刻左下角的Call Tree的可选项可以选了。选中Invert Call Tree 和Hide
System Libraries,展现如下:

图片 9

此时内存泄露的切实可行代码找到了,在左侧的藏灰色框框里指定了哪位方法出现了内存泄露。你只要在那个办法上双击,就会跳转到具体的代码,哈哈,是不是很有益。

图片 10

这边应该是抛砖引玉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

 

相关文章