如何使用xcode配合instruments分析iOS内存泄露

Question

如题所述

Answer 1

尽管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时可能会给你很多其它的一些提示信息。
设置步骤：1

2：勾上红色框里的2：勾上红色框里的

执行。按刚才的操作选中当中的cell。再次crash，这次在output窗体会看到多了一项错误信息：
2012-11-28 13:22:08.911 PropMemFun[2132:11303] *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0
大概意思是：向已释放的内存发送消息。
也就是说使用了已释放的内存。在C语言相当于使用了“野指针”
执行。按刚才的操作选中当中的cell。再次crash，这次在output窗体会看到多了一项错误信息：
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保留一下。就能够用了。
代码改动例如以下：
_lastSushiSelected = [sushiString retain];
执行，这时候不崩溃。
3、分析内存泄露(shift+command+b)
app不crash了。那看看有没有内存泄露。用XCode的Analyze就能分析到哪里有内存泄露

分析之后能够看到：
这里提示alertView没被释放。有内存泄露，那我们释放
[alertView release];
再分析，这个问题攻克了。
4、使用Instruments的leaks工具
分析内存泄露不能把全部的内存泄露查出来。有的内存泄露是在执行时。用户操作时才产生的。那就须要用到Instruments了。
按上面操作，build成功后跳出Instruments工具。选择Leaks选项，这时候寿司程序也执行起来了，选中list中的项，拖动等操作后，工具显示效果例如以下：
大家可能都能猜到，红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢? 先在工具栏按下红色的圆形button，把工具监视内存的活动停下来。
选择Leak，然后点中间十字交叉那，选择Call Tree.
这时候的Call Tree的可选项能够选了。选中Invert Call Tree 和Hide System Libraries,显演示样例如以下：
这时候内存泄露的详细代码找到了，在右边的红色框框里指定了哪个方法出现了内存泄露。
你仅仅要在这些方法上双击。就会跳转到详细的代码。，是不是非常方便。这里应该是提示100%内存会泄露。
6、解决内存泄露问题
问题找到了，那就解决吧