使用Xcode Instruments Leak解决内存泄漏问题

写于前：有很多写Leak教程的文章，当时在使用的时候一直卡在Step4，不能定位memory Leaks代码的位置，最后找到这篇文章的Step5说到dSYM文件。其他文章都没提及。

--->Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件

还有一个问题，之前在跑自己的demo的时候Cmd+I，一直闪退，具体原因没查出来。后来就先Cmd+R，之后通过下面的入口进去不会闪退~



啰嗦完了，下面看转载的正文吧~

----

iOS 5.0之后apple引入了Xcode编译器特性ARC（Automatic Reference Counting，自动引用计数）来帮助开发者管理内存，但为了追求app的高性能与减少安装包大小，工作中很多时候需要我们手动管理内存。再牛的开发者也不能保证自己写的code 100%没有内存泄露，出现内存泄露不可怕，可怕的是我们时间与精力花了大把，但内存泄露依旧没解决,即影响了工作效率也影响自己的心情。

　　下面就讲解xcode中的内存调试神器---Instruments Leak ，不管是ios开发菜鸟，还是有经验的开发者，使用Instruments Leak调试内存泄露是必备技能之一。

　　废话少说，下面开始摊大饼了！！!

step1:

　　 创建一个基于ARC的测试demo,部分测试代码如下：

　　 

　　以上几行代码作为app代理入口method，IOS开发者应该是最熟悉不过了，由于创建的是手动管理内存工程，内存泄露的code line一眼就可以定位。

step2：

　　使用Leaks开始动态分析，点击XCode的Product菜单Profile启动Instruments：

　　

　　 点击Profile Button编译，呵呵，报错了，如果你遇到这种情况也不要紧张，先看下报错信息: 

　　

　　MyViewController与MyNavigationController是我在.pch预编译文件中定义的宏：

　　

　　为什么正常编译就没问题，在Profile 中就编译通不过了，其实这里并不是你的代码写的有问题，问题出在Profile的一个编译选项上：

　　打开工程的Edit Scheme选项

  　　

　　选择Profile，将Build Configuration设置为Debug,这样在.pch文件中，#ifdef DEBUG 编译条件下定义的宏就生效 了。

  　　

　　再次选择Profile building，OK， Success ！！！

step3:

　　进入Instruments主页面，选择Leak Logo

　　

step4:

　　这时Demo程序也运行起来了,工具显示效果如下：

 　　红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?

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

　　　　　

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

　　

　　看到这里，你最想知道的应该是项目中哪里的code内存泄漏了，ok, 下面我们就来定位内存泄漏的code line .

step5:

　　看上图中红色框中的Symbol Name 列，如果你猜想0xedc00与0xedbda是内存地址，那么已经很接近正确答案了，可是这东西对我来说有卵用。其实玄机就隐藏在这里，Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件，关于dSYM更多的细节，我将在后面的blog中说明。回到上面的问题，显示0xedc00与0xedbda是因为我们的工程build settings 的问题，没有生成dSYM 文件，也就无法解析debug symbols。下面我们就来正确设置dSYM选项：

　　

　　设置好之后，重新 profile build一次，这时候内存泄露的具体代码找到了，下面的红色框框里指定了那个方法出现了内存泄露。（笔者注：开始卡在这里，总是定位不到内存泄漏的代码，后来将程序重新运行，重新打开instrument之后就OK了）

 　　

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

　　

step6:

　　解决内存泄漏问题，将创建的vc对象release掉就OK了，再用Instruments Leak工具分析看看，这时候再怎么操作，都没有内存泄露了。表明内存泄露被堵住了。

笔者通过Instrument检查到是由于AFNetworking这个库导致的内存泄漏，通过查阅资料得知，解决方法就是：

将AFHTTPSessionManager的实例使用单例模式获取。

原先在网络请求类中获取AFHTTPSessionManager是通过如下方法

AFHTTPSessionManager *manager = [[AFHTTPSessionManageralloc]initWithBaseURL:[NSURLURLWithString:URLHEAD]];

此方法就是导致内存泄漏的罪魁祸首，所以需要用单例获取AFHTTPSessionManager对象。

在AFHTTPSessionManager类中添加单例：

[objc] view plain copy

 

1. static AFHTTPSessionManager *manager;  
2.   
3. +(AFHTTPSessionManager *)sharedHttpSessionManager {  
4.     static dispatch_once_t onceToken;  
5.     dispatch_once(&onceToken, ^{  
6.         manager = [AFHTTPSessionManager manager];  
7.         manager.requestSerializer.timeoutInterval = 10.0;  
8.     });  
9.       
10.     return manager;  
11. }  

使用时用以下方法：

AFHTTPSessionManager *manager = [[AFHTTPSessionManagersharedHttpSessionManager]initWithBaseURL:[NSURLURLWithString:URLHEAD]];

再来观察Instrument内存占用情况会发现

全是小绿勾，没有内存泄露了，嘿嘿～

附带相关链接：http://www.cnblogs.com/qiutangfengmian/p/6117856.html