作用
简单来说就用来Debug野指针的情况。
我们向一个被释放的对象发送消息是不安全的，但是有时候又没有问题。这主要取决于这个对象之前所在的内存空间是否被重写过了，这是不确定的，因此所造成的情况也是不确定的。当这块内存空间被复写为另一个对象的时候，如果不能识别我们发送的消息，那么崩溃是必然的。如果有时候能被识别，那么debug起来就非常困难。
Zombies
Cocoa 有个很好的功能：“Zombies”，此时就能派上很大用处。当“Zombies”开启的时候，runtime将会把所有要被销毁（deallocated）的对象变成特殊的僵尸对象，而不是按正常流程进行销毁。而存放这些僵尸对象的内存空间是不可复用的，从而杜绝以上这种野指针的情况。
此时我们向一个zombie发送消息的话，将会抛出异常并明确告知消息被发送到了一个已经销毁的对象上。
如下：
*** -[CFString respondToSelector:]: message sent to deallocated instance 0x7ff9e9c080e0
使用
在Xcode中：
Edit Scheme
Edit Scheme
按照图中注解给Zombie Objects打上勾即可。
原理
主要还是依赖于runtime、Foundation和CoreFoundation框架。如果我们打开了Zombie Objects选项，当一个对象即将deallocated的时候，将会额外多一步，就是额外的这一步将该对象转换为僵尸对象而不是直接deallocated。
下面一段代码做参考：
@interface EOCClass : NSObject
@end
@implementation EOCClass
@end
void PrintClassInfo(id obj) {
Class cls = object_getClass(obj);
Class superCls = class_getSuperclass(cls);
NSLog(@"===%s : %s ===",class_getName(cls),class_getName(superCls));
}
int main(int argc, char * argv[]) {
@autoreleasepool {
EOCClass *obj = [[EOCClass alloc] init];
NSLog(@"Before release:");
PrintClassInfo(obj);
[obj release];
NSLog(@"After release:");
PrintClassInfo(obj);
}
}
这段代码用了MRC,以此更方便展示将是对象的产生。
最后的运行结果如下：
Before release:
=== EOCClass : NSObject ===
After release:
=== _NSZombie_EOCClass : nil ===
从上可以看出，当一个对象变成僵尸的时候，它的类也从EOCClass变成了_NSZombie_EOCClass。问题是，这个类是哪里来的？
自然而然我们会想到runtime创建了这个僵尸类。
以上这个僵尸类是模板NSZombie类的一个副本，它并没有什么别的作用，只是简单的作为一个标记。
以下是一段伪代码，大致展现了这个僵尸类是如何创建的，并且该对象是如何变成一个僵尸对象的：
//Obtain the class of the object being deallocated 获得将要释放的对象的类
Class cls = object_getClass(self);
//Get the class's name 获得类名
const char *clsName = class_getName(cls);
//Prepend _NSZombie_ to the class name 提前扩展好需要的类名
const char *zombieClsName = "_NSZombie_" + clsName;
// See if the specific zombie class exists 检查该类是否存在
Class zombieCls = objc_lookUpClass(zombieClsName);
//If the specific zombie class doesn't exist,
//then it needs to be created 如果不存在，则创建
if (!zombieCls) {
//Obtain the template zombie class called _NSZombie_ 获得模板类_NSZombie_
Class baseZombieCls = objc_loopUpClass("_NSZombie_");
//Duplicate the base zombie class,where the new class's name is the prepended string from above 以模板为基础重建一个类，类名为以上的zombieClsName字符串
zombieCls = objc_duplicateClass(baseZombieCls,zombieClsName,0);
}
//Perform normal destruction of the object being deallocated 执行一般的销毁流程
objc_destructInstance(self);
//Set the class of the object being deallocated to the zombie class 讲对象的类设置为僵尸类
objc_setClass(self,zombieCls);
//the class of 'self' is now _NSZombie_OriginalClass
当NSZombieEnabled 这个选项开启的时候，runtime会将上述代码与之前常规的dealloc代码进行互换，由此来保证对象的类变成僵尸类。
关键一点是，这个内存中的对象其实还是活着的，内存并没有被释放，因此该内存也不会被重复使用。因为对象被标记为了僵尸，所以接收到消息的时候能提示我们异常所在。
之所以大费周章的给每一个对象的类都重新制定一个相对应的僵尸类是因为这样在反馈问题的时候会显得更加精准一些，如果都简单的报错NSZombie对象无法识别方法，那么debug效果就几乎没有了
NSZombie
NSZombie本身并不实现任何方法，也没有父类，所以它是一个基类，就像NSObject一样。因为它不实现任何方法，所以当接收到消息的时候，会完整的走一遍消息转发流程。
消息转发中关键的一环是forwarding,它做的其中一件事情就是先检查对象的类名是否含有前缀NSZombie,如果检测到了，那么就直接走报告僵尸对象的流程。再打印完错误信息之后程序就结束运行了。
以下这段伪代码可以帮助理解在forwarding里是怎么处理zombie对象的：
//Obtain the object's class 取得对象的类
Class cls = object_getClass(self);
//Get the class's name 取得类名
const char *clsName = class_getName(cls);
//Check if the class is prefixed with _NSZombie_ 检查是否含有前缀_NSZombie_
if(string_has_prefix(clsName,"_NSZombie_")) {
//if so, this object is a zombie 如果前缀符合，那么它是一个僵尸对象
//Get the original class name by skipping past the _NSZombie_, i.e. taking the substring from character 10 获取原始的类名
const char *originalClsName = substring_from(clsName,10);
//Get the selector name of the message 获取方法名
const char *selectorName = sel_getName(_cmd);
//Log a message to indicate which selector is being sent yo which zombie 打印错误信息
Log("*** -[%s %s]: message sent to deallocated instance %p", originalClsName,selectorName,self);
//Kill the application 结束程序
abort();
}
网友评论