为什么delegate属性要用assign不能用retain？

最新推荐文章于 2016-04-04 20:40:42 发布

转载最新推荐文章于 2016-04-04 20:40:42 发布 · 935 阅读

文章标签：

#IOS #内存泄漏

IOS开发专栏收录该内容

30 篇文章

订阅专栏

也因为这样，iOS官方文件才会要建议我们所以的delegate都要用assign property。
也就是所谓”weak reference”的property，他的特色就是虽然会持有对方的reference，但是不会增加retain count。
如此下来，当myViewController的retain count变成0，则会dealloc。
同时在dealloc中，也一并把myClass release，则myClass也跟着被release。

- (void)dealloc
{
   [myClass release];
   [super dealloc];
}

事情就结束了吗? 还没有唷…
这边还有一个大家常常忘记的重点，那就是上面的dealloc这样写会有潜在危险。
应该要改成这样

- (void)dealloc
{
    myClass.delegate = nil;
    [myClass release];
    [super dealloc];
}

你可能会很纳闷，myClass不是马上就会被release了吗? 干嘛要先把他的delegate设成nil?
那是因为我们假设myClass会马上会被dealloc，但是现实状况这个是不一定的，
有可能里面内部有建个NSURLConnection，或是正在做某件事情而让其他物件也retain myClass。
如果myClass没有马上dealloc，那他的myClass.delegate不就正指向一个不合法的位置了吗? (此种pointer称作dangling pointer)

解决方法是在MyViewController的dealloc中，在release myClass之前，
要先把原本指向自己的delegate改设成nil，这样才可以避免crash发生。
在我之前写的project，很大一部份的crash都是这样造成的，因为这个问题通常不是每次都发生，
但是发生的时候确很难在重新复制，所以不可不慎啊。

但是很兴奋的是到了iOS5中的Automatic Reference Counting 这个问题可以有所改善。
在ARC中提出了一个新的weak reference的概念来取代原本的assign，
weak reference指到的物件若是已经因retain count归零而dealloc了，则此weak reference也自动设成nil。
而原本旧的这种assign的作法，在ARC中叫做__unsafe_unretained，这只是为了相容iOS4以下的版本。

回顾重点:
如果你是写library给别人用的，记得把你的delegate设成assign property，这样才不会造成circular reference
当你是要始用别人的library，记得在你自己dealloc的时候，把delegate设成nil，以避免crash的事情发生。

References
[1] Communicating with Objects

原文：http://blog.sina.com.cn/s/blog_4cd8dd130101lvx2.html