虽然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:勾上红色框里的
运行,按刚才的操作选中其中的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保留一下,就可以用了。代码修改如下:
- <span style="font-size:14px;"> _lastSushiSelected = [sushiString retain];
- </span>
运行,这时候不崩溃。
3、分析内存泄露(shift+command+b)
app不crash了,那看看有没有内存泄露。用XCode的Analyze就能分析到哪里有内存泄露
分析之后可以看到:
这里提示alertView没被释放,有内存泄露,那我们释放
[alertView release];
再分析,这个问题解决了。
相关推荐
不用 instruments 检测 app 内的内存泄露.zip,Find memory issues & leaks in your iOS app without instruments
虽然iOS5.0版本之后加入了ARC机制,由于相互引用关系比较复杂时,内存泄露还是可能存在。所以了解原理很重要。这里讲述在没有ARC的情况下,如何使用Instruments来查找程序中的内存泄露,以及NSZombieEnabled设置的...
本篇文章主要介绍使用Xcode7的Instruments检测解决iOS内存泄露(最新)的相关资料,需要的朋友可以参考下
iOS-Performance-Optimization:iOS 性能优化专题合集.zip,关于iOS 性能优化梳理、内存泄露、卡顿、网络、GPU、电量、 App 包体积瘦身、启动速度优化等、Instruments 高级技巧、常见的优化技能- Get — Edit
关于iOS 性能优化梳理、内存泄露、卡顿、网络、GPU、电量、 App 包体积瘦身、启动速度优化等、Instruments 高级技巧、常见的优化技能- Get — Edit
源码HeapInspector-for-iOS,HeapInspector是一个模拟了app中内存堆的iOS调试工具,通过该工具你可以直接在设备上发现app内存泄露等诸多问题,无需启动Instruments. 通过HeapInspector和heap截图,你可以确认泄露...
1.检测内存泄漏 2.内存增长 3.线程执行时间 Instruments help 数据库&缓存 缓存 SQLLife 极客时间课程 差异和性能优化 Realm 缓存 网络编程 Http/Https 《图解http/https》封装一个网络库 TCP/IP 《图
LifetimeTracker可以在您开发应用程序时立即保留周期/内存问题,并且会立即向您显示这些问题,因此您可以更轻松地找到它们。 Instruments和Memory Graph Debugger很棒,但是很多时候开发人员在关闭功能实现时忘记...