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

一时失言乱红尘 2022-01-15 15:35 281阅读 0赞

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

发布于：2012-12-04 09:30阅读数：20336

虽然iOS 5.0版本之后加入了ARC机制，但由于相互引用关系比较复杂时，内存泄露还是可能存在。所以了解原理很重要。这里讲述在没有ARC的情况下，如何使用Instruments来查找程序中的内存

“ ”

阅读器

虽然iOS 5.0版本之后加入了ARC机制，但由于相互引用关系比较复杂时，内存泄露还是可能存在。所以了解原理很重要。

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

本文假设你已经比较熟悉Obj-C的内存管理机制。

实验的开发环境：XCode 4.5.2

**1、运行Demo。**

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

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

![4673_121204093240_1.png][]

在崩溃的地方断住了，知道crash的地方了，但是不知道具体crash的原因。

**2、设置NSZombieEnabled**

这是一个 “EXC\_BAD\_ACCESS”错误。我们打开XCode的选项：“NSZombieEnabled” 。在crash时可能会给你更多的一些提示信息。

设置步骤：1

![4673_121204094100_1.png][]

2：勾上红色框里的

![4673_121204094115_1.png][]

运行，按刚才的操作选中其中的cell。再次crash，这次在output窗口会看到多了一项错误信息：

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

大概意思是：向已释放的内存发送消息。也就是说使用了已释放的内存，在C语言相当于使用了“野指针”

![4673_121204094157_1.png][]

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

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

<span style="font-size:14px;"> \_lastSushiSelected = \[sushiString retain\];

</span>

运行，这时候不崩溃。

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

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

![4673_121204094431_1.png][]

分析之后可以看到：

![4673_121204094451_1.png][]

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

\[alertView release\];

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

**4、使用Instruments的leaks工具**

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

![4673_121204094527_1.png][]

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

![4673_121204094554_1.png][]

大家可能都能猜到，红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?

先在工具栏按下红色的圆形按钮，把工具监视内存的活动停下来。选择Leak，然后点中间十字交叉那，选择Call Tree

![4673_121204094630_1.png][]

这时候左下角的Call Tree的可选项可以选了。选中Invert Call Tree 和Hide System Libraries，显示如下：

![4673_121204094703_1.png][]

这时候内存泄露的具体代码找到了，在右边的红色框框里指定了哪个方法出现了内存泄露。

你只要在这些方法上双击，就会跳转到具体的代码，哈哈，是不是很方便。

![4673_121204094731_1.png][]

这里应该是提示100%内存会泄露。

**6、解决内存泄露问题**

问题找到了，那就解决吧。

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

sushiString变量通过autorelease创建，它的引用计数是1.

这行代码使得引用计数增加到2， \_lastSushiSelected = \[sushiString retain\];

这个方法结束时，sushiString的autorelease生效了，这个变量的引用计数减少为1

当再次执行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代码：

来源： [http://blog.csdn.net/totogo2010/article/details/8233565][http_blog.csdn.net_totogo2010_article_details_8233565]

转载于:https://blog.51cto.com/derkin2jessie/1175204

[4673_121204093240_1.png]: /images/20220115/e2052cd2a073466ca57812cf924fc422.png
[4673_121204094100_1.png]: /images/20220115/a5006f0b4fbf4f2daa25720e63bc1a10.png
[4673_121204094115_1.png]: /images/20220115/efd4f649ea5c42ffb10544624699940a.png
[4673_121204094157_1.png]: /images/20220115/be498f50eda84091971dd0ddca55bd29.png
[4673_121204094431_1.png]: /images/20220115/5f95faf8caad4e64abdeff9dbbfdb182.png
[4673_121204094451_1.png]: /images/20220115/3bf6c666f6624314a3a1437345d7262b.png
[4673_121204094527_1.png]: /images/20220115/85ebb6161c8b4b30984f33c4f6a7b44a.png
[4673_121204094554_1.png]: /images/20220115/dc5e786694634e64a3939d11e836c19c.png
[4673_121204094630_1.png]: /images/20220115/c551a3665d444345825b8703c9b14696.png
[4673_121204094703_1.png]: /images/20220115/44a9fd389278457c971ad01d86772bdf.png
[4673_121204094731_1.png]: /images/20220115/c2805b327a5b4e6aac40e1ec9088b7de.png
[http_blog.csdn.net_totogo2010_article_details_8233565]: http://blog.csdn.net/totogo2010/article/details/8233565