IOS性能调优系列:使用Zombies动态分析内存中的僵尸对象

硬广:《IOS性能调优系列》第四篇,预计会有二十多篇,持续更新,欢迎关注。

前两篇《IOS性能调优系列:Analyze静态分析》、《IOS性能调优系列:使用Instruments动态分析内存泄漏》关注了内存泄露的问题,本篇正好相反,关注的是内存中那些被过度释放的对象(overreleased objects)。

这篇的标题纠结了半天,到底是写EXC_BAD_ACCESS错误调试,还是写内存中僵尸对象的分析,最后还是选了个Duang~Duang~的标题。

今天在论坛上看到个帖子,遇到的就是本篇要分析的问题,正好拿来解释Bug场景:

相信在使用ARC之前,很多人遇到过EXC_BAD_ACCESS错误,这个错误可以理解为访问了已被释放的对象,苹果称之为僵尸对象。

比如在不开启ARC下,下面这段代码:

NSString* hello = [NSString stringWithFormat:@"Hello"];
NSLog(@"What you say is %@",hello);
[hello release];

hello对象不是手动分配,而是加入到自动释放池,由释放池负责释放,所以第三行调用release时就会产生EXC_BAD_ACCESS错误。

在开启ARC后,可以很大程度上避免产生EXC_BAD_ACCESS错误,但也是有出现可能的,比如IOS里使用了C++代码,C++部分的对象是不会有ARC来管理的。

EXC_BAD_ACCESS错误不像访问空指针一样容易定位,往往报错时很难查找到错误点,所以XCode在Instruments中提供了单独的Zombies工具来分析这类错误。

使用Zombies分析的原理



和使用 Instruments的其他工具一样,点击XCode的Product菜单Profile启动Instruments:

可以看到Zombies工具下边的介绍,用于查找那些被过度释放的僵尸对象。

Zombies工具的查找原理其实和设置NSZombieEnabled环境变量的调试方式是一样的,启动Zombies后在内部设置了NSZombieEnabled为True。

启用了NSZombieEnabled的话,它会用一个僵尸来替换默认的dealloc实现,也就是在引用计数降到0时,该僵尸实现会将该对象转换成僵尸对象。僵尸对象的作用是在你向它发送消息时,就不会向之前那样Crash或者产生 一个难以理解的行为,而是放出一个错误消息,它会显示一段日志并自动跳入调试器, 因此我们就可以找到具体或者大概是哪个对象被错误的释放了。

使用Zombies分析的步骤



1、启动Instruments,选择Zombies;

2、对之前产生EXC_BAD_ACCESS的测试用例重新运行,直到程序崩溃,如果发生EXC_BAD_ACCESS错误,会出现以下界面:

3、通过滑动箭头来查看错误细节,例如可以看到该对象的内存操作过程,如malloc、autorelease、retain、release等操作;

4、查看底部的详细历史,选择相应的行可以定位到相应的代码,找出产生错误的代码:

基本上通过查看Zombies工具给出的信息找出错误代码行是比较简单的,Zombies也只有在产生EXC_BAD_ACCESS错误时才有用。

手动设置NSZombieEnabled环境变量:



XCode也提供了手动设置NSZombieEnabled环境变量的方法,不过设置NSZombieEnabled为True后,会导致内存占用的增长,同时会影响Leaks工具的调试,这是因为设置NSZombieEnabled会用僵尸对象来代替已释放对象。

点击Product菜单Edit Scheme打开该页面,然后勾选Enable Zombie Objects 复选框:

一般不建议进行进行手动设置,而应该使用Zombies工具进行调试。



记录,为更好的自己!转载请注明出处!

时间: 2024-10-12 21:42:16

IOS性能调优系列:使用Zombies动态分析内存中的僵尸对象的相关文章

IOS性能调优系列:使用Instruments动态分析内存泄漏

硬广:<IOS性能调优系列>第二篇,持续更新,欢迎关注. 第一篇介绍了Analyze对App做静态分析,可以发现应用中的内存泄漏问题,对于有些内存泄漏情况通过静态分析无法解决的,可以通过动态分析来发现,分析起来更有针对性. 从本篇开始介绍XCode提供的强大的分析工具Instruments,内存分析只是Instruments中的一个功能,其他功能后续介绍. 使用Instruments动态分析内存泄漏 Instruments中的Leaks功能主要用于分析内存泄漏,还是以<IOS性能调优系列

IOS性能调优系列:使用Allocation动态分析内存使用情况

硬广:<IOS性能调优系列>第三篇,持续更新,欢迎关注. <IOS性能调优系列:Analyze静态分析>介绍了使用静态分析方法查找IOS内存泄漏的方法,<IOS性能调优系列:使用Instruments动态分析内存泄漏>讲解了使用Instruments的Leaks工具动态分析内存泄漏. 这两篇都是关注于内存泄漏的,是内存调优首先要关注的方面. 关于内存的问题,除了内存泄漏以外,还可能存在内存不合理使用的情况,也会导致IOS内存警告. 内存的不合理使用往往比内存泄漏更难发现

IOS性能调优系列:使用Time Profiler发现性能瓶颈

硬广:<IOS性能调优系列>第五篇,预计会有二十多篇,持续更新,欢迎关注. 之前四篇都是关注于内存方面,分析了内存泄漏.僵尸对象.内存分配,本篇介绍Time Profiler工具的使用,开始真正的“性能”调优之旅. Time Profiler还有之前介绍过的Leaks.Allocations工具,被戏称为Instruments的救命三招,是当应用遇到问题时首先应当使用的三个工具. Time Profiler帮助我们分析代码的执行时间,找出导致程序变慢的原因,告诉我们“时间都去哪儿了?”. 在使

IOS性能调优系列:Analyze静态分析

目前关于IOS性能优化的教程较少,决定写一个<IOS性能调优系列>,主要关注与内存泄漏.性能优化.流量和电量分析几个方面. XCode已经提供了非常强大的性能调优工具,结合几个第三方工具和一些技巧,进行性能优化非常简单. 第一篇先写写最简单的,Analyze静态分析. 相信IOS开发者在App进行Build或Archive时,会产生很多编译警告,这些警告是编译时产生的,静态分析的过程也类似,在XCode Product菜单下,点击Analyze对App进行静态分析. Analyze主要分析以下

IOS性能调优系列(全)

总结: 三类工具 基础工具 (NSLog的方式记录运行时间.) 性能工具.检测各个部分的性能表现,找出性能瓶颈 内存工具.检查内存正确性和内存使用效率 性能工具: 可以衡量CPU的使用,时间的消耗,电池的消耗 一.Time Profile 启动Time Profile:Xcode ——> Product ——> Profile ——> Time Profile 使用Time Profiler调试程序,能获取到整个应用程序运行中所消耗的时间分布和百分比 使用Time Profile前有两点

Android性能调优篇之探索JVM内存分配

详细内容请查看我的简书地址:Android性能调优篇之探索JVM内存分配 或者我的个人博客地址:Android性能调优篇之探索JVM内存分配

iOS性能调优总结

引言 说起性能调优,我本来想说很多,但是觉得枯燥的语言并不能表达我对于性能调优的重视,所以我打算举个不太恰当的例子. 曾经有这么一家工厂,他们的产品从原材料到出厂一共需要经过30条产品线. 这家公司的老板对底下的员工曾多次强调过质量的重要性,员工们却不以为然,他们觉得自己做的都很不错. 有一次,老板去视察,走到了一条产品线上,问起工人,这条产品线的合格率能达到多少,那个工人自豪的说,"98%!".老板却并没有十分满意,摇着头走开了. 那位工人非常的疑惑.这么高的合格率,老板为什么还是不

[Spark性能调优] 第四章 : Spark Shuffle 中 JVM 内存使用及配置内幕详情

本课主题 JVM 內存使用架构剖析 Spark 1.6.x 和 Spark 2.x 的 JVM 剖析 Spark 1.6.x 以前 on Yarn 计算内存使用案例 Spark Unified Memory 的运行原理和机制 引言 Spark 从1.6.x 开始对 JVM 的内存使用作出了一种全新的改变,Spark 1.6.x 以前是基于静态固定的JVM内存使用架构和运行机制,如果你不知道 Spark 到底对 JVM 是怎么使用,你怎么可以很有信心地或者是完全确定地掌握和控制数据的缓存空间呢,所

jvm原理及性能调优系列(jvm调优)

个人认为jvm调优主要通过以下方法解决 1.设置合适的最大堆内存(新生代和老生代的最大和值)和最小堆内存(jvm启动时占用的操作系统内存大小),及设置好堆的比例分配. 2.设置合适的新生代 因为对其对系统性能和GC回收有一定的影响. 3.设置合适的持久代 因为其直接决定系统可以支持多少个类定义和多少个常亮. 4.设置合适的线程栈 否则系统可能因为线程所需资源和空间不够而异常退出.