使用MsLeak以及Instument调试解决iOS内存泄露

使用MsLeak以及Instument调试解决iOS内存泄露

---

工具和描述参考网络内容整理，http://www.raywenderlich.com/
补充MSleakHunter demo说明
rodman整理

虽然iOS 5.0版本之后加入了ARC机制，由于相互引用关系比较复杂时，内存泄露还是可能存在。你要相信我，做一个app终归是会比较复杂的。

这里收集传统常用的Xcode和Instruments定位方法，以及新秀内存泄露定位工具MSleakHunter。

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

运行Demo

先下载一个实现准备好的内存泄露的Demo吧：leakapp
下载下来，打开运行，程序是一个寿司的列表，列出各种寿司卷。试着选择里面的几行，应该是选第二行的时候就崩溃了。崩溃截图：

此处输入图片的描述

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

设置NSZombieEnabled

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

1. 设置步骤：1 edit scheme

   
   
   此处输入图片的描述

2. 勾上红色框里的

   
   
   此处输入图片的描述
   
   

   运行，按刚才的操作选中其中的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了。

   
   
   此处输入图片的描述
   
   

   大家可能都能猜到，红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?
   先在工具栏按下红色的圆形按钮，把工具监视内存的活动停下来。选择Leak，然后点中间十字交叉那，选择Call Tree.

   
   
   此处输入图片的描述
   
   这时候左下角的Call Tree的可选项可以选了。选中Invert Call Tree 和Hide System Libraries,显示如下：
   
   此处输入图片的描述
   
   这时候内存泄露的具体代码找到了，在右边的红色框框里指定了哪个方法出现了内存泄露。
   

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

   
   
   此处输入图片的描述
   
   这里应该是提示100%内存会泄露。
5. 解决内存泄露问题
   问题找到了，那就解决吧
   关于：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了，再用工具分析看看，这时候你再点，再拖，再怎么操作，都没有内存泄露了。表明内存泄露被堵住了。

MSLeakHuntery用于定位内存泄露

通过埋入代码做跟踪，可以考虑使用一个叫MSleakHunter的开源工具。下载地址

MSLeakHunter可以帮你定位和调试你的ios程序，以找到潜在的内存泄露隐患。

常常会出现这样的状况，你的ios声明的对象存在内存泄露的风险（如一些没有被释放的对象）而你的instruments却没有定位到。比如如下一种特别的例子，程序中循环使用一些blocks，很难正确的意识到内存已经被正确的释放掉。

msleakhunter提供了一个通用的接口来构建“leak hunter”对象，这是在监测一个特定的对象资源分配以及回收。在这一过程中，提供两个特定的实施例：msviewcontrollerleakhunter和msviewleakhunter（用于分别处理UIViewController和UIView的实例）。

当然，只要你愿意，你可以创造尽可能多的leakhunter以达到测试目的。对象唯一需要关注的就是他们要释放有一定的方法，在使用后需要调用对应的方式做释放。例如，通过UIViewController 得到一个viewdiddisappear实例：在释放它之前总会需要存在一些时间。msleakhunter所能支持你做的，就是跟踪对象，一段时间都未被使用也没有调用dealloc释放此对象，这将被认为是潜在的泄露可能，并打印日志再控制台。

msleakhunter的安装是相当轻量的，所以它不会明显伤害任何应用程序的性能，但是仍旧建议当发布应用时，把这个代码禁用（通过msleakhunter_enabled宏）。

安装方法

• 解压Leakhunter下载地址内容，引入你的工程下。添加 MSLeakHunter.{h,m} 到Xcode项目中.
  

  

• 在build Phases中修改leaker hunter相关的M文件不使用arc

  
  
  

• 在AppDelegate文件中引用leakHunter，并做初始化

参考代码：

#import "MSLeakHunter.h"
#import "MSViewControllerLeakHunter.h"
#import "MSViewLeakHunter.h"
#import “MSZombieHunter.h"
 
#if MSLeakHunter_ENABLED
        [MSLeakHunter installLeakHunter:[MSViewControllerLeakHunter class]];
    #endif
    
#if MSViewLeakHunter_ENABLED
        [MSLeakHunter installLeakHunter:[MSViewLeakHunter class]];
    #endif

确保MSVCLeakHunter.h中，MSVCLeakHunter_ENABLED 被设置为1

参考范例如下

辅助问题分析和定位

• 启动app并配合xCode查看运行状况，如下图一能看到内存的使用数值和走势，下图二会打印可能存在内存泄露的嫌疑内容。

• 内存有持续增长，且提示有泄露时，可以考虑使用LeakHunter提供的方法打断点

一旦你知道它的存在泄露，这个工具可以让你调试泄漏。可以考虑使用LeakHunter打断点提供了一个非常简单的方法使调试器停止在你关注的对象上。在msleakhunterretainbreakpointshelper.H中，用此方法监视你要的对象。可以帮助你找出额外的-retain调用，或谁在保留对象但不释放它.

ms_enablememorymanagementmethodbreakpointsonobject（object）在调用-retain, -release, -autorelease, 或者-dealloc释放该对象后，调试器将停止应用监控。此时如果查看堆栈，可以看到在你的应用程序中谁造成调用这些方法，这能帮助你调试内存管理的问题。

注：msleakhunterretainbreakpointshelper已经被编译non arc。如果您的项目ARC，请参阅本指南点击查看，以了解如何禁用该文件。

MSZombieHunter的使用

MSZombieHunter默认是nszombieenabled，你可以通过以下方法启用他

    +[MSZombieHunter enable];

开启之后，一旦被监控的对象释放，MSZombieHunter会抛出exception，方便你立即捕获。

重要说明
使mszombiehunter使所有对象收到dealloc消息仍旧保持存活，成倍增加了应用程序的内存使用情况。因为这个原因，只是建议在模拟器上启用它，或者当你试图调试一个exc_bad_access崩溃时使用。