@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模型没有区别).
解决方法
(这是资源编程指南中的 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.jb51.cc/c/110540.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
