objective-c – IBOutlet Work的readonly属性是否优先?

前端之家收集整理的这篇文章主要介绍了objective-c – IBOutlet Work的readonly属性是否优先?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我继承的代码中,我看到了以下内容
@property (readonly) IBOutlet UIImageView * bgImage;

当我期望保留记忆模型如:

@property (readonly,retain) IBOutlet UIImageView * bgImage;

我很困惑为什么第一个属性定义工作而不会引起问题.

此外,正如您所期望的那样,dealloc中有一个版本:

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

如果有人能为此提出解释,我将不胜感激.我已经与原始开发人员交谈,他试图编写更简洁的代码,这就是为什么他在内存模型中省略了保留(似乎没有必要).

我想知道IBOutlet是否基本上被视为ivar IBOutlet语句,因为它只是readonly(没有使用setter,因此默认的assign memory模型没有区别).

如果永远不会期望IBOutlet发生变化,那么使用没有内存模型的readonly属性实际上是定义属性的更好方法吗?

解决方法

iOS上的nib加载器在nib中创建对象,然后自动释放它们.当它建立与outlet的连接时,它使用setValue:forKey :,它将调用该键的setter方法.如果没有定义setter,例如当IBOutlet是readonly属性时,对象在被分配之前仍然被保留.
(这是资源编程指南中的 Managing Nib Objects in iOS的解释.)

因此实际上,无论出口是否被声明为保留或分配,另一端的对象都由具有出口的对象所拥有.它由setter方法保留,或者由setValue保留:forKey:未找到setter时.由于在第二种情况下没有其他可能的所有者,您可以将具有插座的对象视为所有者.因此,nib中的对象应该以dealloc释放.

我同意你的看法,这个内存条件应该通过更改属性属性来包含retain来明确.*它是否只是readonly似乎没有区别(但是,见下文).从概念上讲,是的,该对象是只读的,因此是否明确标记它取决于您是否认为它是IBOutlet这一事实适当记录.

更新:
Paul.s的评论促使我做了一个快速测试.我创建了一个UIView子类,它记录了它的alloc,retain,release和autorelease调用,将它的实例粘贴到一个nib中,并通过一个属性为app app委托了一个IBOutlet.

手动计算引用计数活动,当属性为(readwrite,assign)时,实例出现了一个净0计数.当属性被声明为推荐方式时,它是net 1(readwrite,retain),以及它是(readonly,assign).所有这些都与预期的一样 – 当它(readwrite,分配setter用于建立连接,并且不进行保留.当它是只读时,连接机制会依赖于自己的保留.

最有趣的是,当我尝试通过声明属性(readwrite,assign)更改此视图的背景颜色来崩溃应用程序时(即,当它可能已被释放时),我看到最后一次调用以保留弹出窗口.

我认为这归结为:遵循Apple的建议 – 他们知道幕后发生了什么,并且(除了错误)不会引导你错.

(另外一件事就是,一如既往,担心绝对引用计数并不会非常有用 – 计数在一次点上一直上升到6,在保留和释放的二十几个调用中 – 您只需要担心直接导致的保留和释放.)

*当然,这在ARC下有所改变.我转述的信息在其章节的“遗产模式”部分.在ARC下,建议IBOutlets要弱,除非它们是顶级的,在这种情况下它们应该是强大的.这样做意味着您依赖视图层次结构(保留其子视图的视图)来维护自己.

原文链接:https://www.f2er.com/c/110540.html

猜你在找的C&C++相关文章