Question

使用了arc是不是就等于没有内存泄漏了

Answer 1

尽管iOS5.0加入版本号之后ARC机制，由于相互引用关系是复杂的。内存泄漏可能仍然存在。于是，懂原理是非常重要的。这里讲述在没有ARC的情况下，怎样使用Instruments来查找程序中的内存泄露。以及NSZombieEnabled设置的使用。本文如果你已经比较熟悉Obj-C的内存管理机制。实验的开发环境：XCode4.5.21、执行Demo。先下载一个实现准备好的内存泄露的Demo吧：leakapp下载下来。打开执行，程序是一个寿司的列表，列出各种寿司卷。试着选择里面的几行，应该是选第二行的时候就崩溃了。崩溃截图：在崩溃的地方断住了，知道crash的地方了，可是不知道详细crash的原因。2、设置NSZombieEnabled这是一个“EXC_BAD_ACCESS”错误。我们打开XCode的选项：“NSZombieEnabled”。在crash时可能会给你很多其它的一些提示信息。设置步骤：12：勾上红色框里的2：勾上红色框里的执行。按刚才的操作选中当中的cell。再次crash，这次在output窗体会看到多了一项错误信息：2012-11-2813:22:08.911PropMemFun[2132:11303]***-[CFStringrespondsToSelector:]:messagesenttodeallocatedinstance0x713ebc0大概意思是：向已释放的内存发送消息。也就是说使用了已释放的内存。在C语言相当于使用了“野指针”执行。按刚才的操作选中当中的cell。再次crash，这次在output窗体会看到多了一项错误信息：2012-11-2813:22:08.911PropMemFun[2132:11303]***-[CFStringrespondsToSelector:]:messagesenttodeallocatedinstance0x713ebc0大概意思是：向已释放的内存发送消息。也就是说使用了已释放的内存。在C语言相当于使用了“野指针”看了下crash的这个语句，sushiString应该是没问题的，它是从stringWithFormat初始化出来的。那就是_lastSushiSelected的问题。_lastSushiSelected指向了sushiString。sushiString是一个autorelease变量。在第二次点击时。使用的是sushiString已经被释放，所以crash了。那为_lastSushiSelected保留一下。就能够用了。代码改动例如以下：_lastSushiSelected=[sushiStringretain];执行，这时候不崩溃。3、分析内存泄露(shift+command+b)app不crash了。那看看有没有内存泄露。用XCode的Analyze就能分析到哪里有内存泄露分析之后能够看到：这里提示alertView没被释放。有内存泄露，那我们释放[alertViewrelease];再分析，这个问题攻克了。4、使用Instruments的leaks工具分析内存泄露不能把全部的内存泄露查出来。有的内存泄露是在执行时。用户操作时才产生的。那就须要用到Instruments了。按上面操作，build成功后跳出Instruments工具。选择Leaks选项，这时候寿司程序也执行起来了，选中list中的项，拖动等操作后，工具显示效果例如以下：大家可能都能猜到，红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?先在工具栏按下红色的圆形button，把工具监视内存的活动停下来。选择Leak，然后点中间十字交叉那，选择CallTree.这时候的CallTree的可选项能够选了。选中InvertCallTree和HideSystemLibraries,显演示样例如以下：这时候内存泄露的详细代码找到了，在右边的红色框框里指定了哪个方法出现了内存泄露。你仅仅要在这些方法上双击。就会跳转到详细的代码。，是不是非常方便。这里应该是提示100%内存会泄露。6、解决内存泄露问题问题找到了，那就解决吧