使用ARC时，我是否在dealloc中将属性设置为nil？ [英] Do I set properties to nil in dealloc when using ARC?
问题描述
我正在尝试学习iOS 5中的自动引用计数。现在这个问题的第一部分应该很简单：
I am trying to learn Automatic Reference Counting in iOS 5. Now the first part of this question should be easy:
-
使用ARC时， NOT 是否需要在我的dealloc中编写显式的
release-property语句是否正确？在其他
字中，以下 NOT 是否需要显式的
dealloc？
Is it correct that I do NOT need to write explicit release-property statements in my dealloc when using ARC? In other words, is it true that the following does NOT need a explicit dealloc?
@interface MyClass : NSObject
@property (strong, nonatomic) NSObject* myProperty;
@end
@implementation MyClass
@synthesize myProperty;
@end
我的下一个也是更重要的问题来自于过渡到ARC发行说明文档：
您不必（实际上不能）释放实例变量，但您可能需要在系统类上调用[self setDelegate：nil]并且其他未使用ARC编译的代码。
You do not have to (indeed cannot) release instance variables, but you may need to invoke [self setDelegate:nil] on system classes and other code that isn’t compiled using ARC.
这就引出了一个问题：如何知道哪些系统类未使用ARC编译？我什么时候应该创建自己的dealloc并明确地将强保留属性设置为nil？我是否应该假设属性中使用的所有NS和UI框架类都需要显式dealloc？
This begs the question: how do I know which system classes are not compiled with ARC? When should I be creating my own dealloc and explicitly setting strongly retaining properties to nil? Should I assume all NS and UI framework classes used in properties require explicit deallocs?
有大量关于SO和其他地方在使用手动参考跟踪时释放属性支持ivar的做法，但在使用ARC时相对较少。
There is a wealth of information on SO and elsewhere on the practices of releasing a property's backing ivar when using manual reference tracking, but relatively little about this when using ARC.
推荐答案
简短回答：不，您不必在ARC下的 dealloc 中输出属性。
Short answer: no, you do not have to nil out properties in dealloc under ARC.
长答案：即使在手动内存管理中，也不应该忽略 dealloc 中的属性。
Long answer: You should never nil out properties in dealloc, even in manual memory management.
在MRR中，您应该发布 ivars 。 Nilling out属性意味着调用setter，它可以调用它不应该在 dealloc 中触及的代码（例如，如果你的类或子类覆盖setter）。同样，它可能会触发KVO通知。释放ivar反而避免了这些不良行为。
In MRR, you should release your ivars. Nilling out properties means calling setters, which may invoke code that it shouldn't touch in dealloc (e.g. if your class, or a subclass, overrides the setter). Similarly it may trigger KVO notifications. Releasing the ivar instead avoids these undesired behaviors.
在ARC中，系统会自动为你释放任何ivars，所以如果这就是你所做的一切，你甚至没有实现 dealloc 。但是，如果您有任何需要特殊处理的非对象ivars（例如，您需要 free（）分配的缓冲区），您仍然必须处理<$ c中的那些$ c> dealloc 。
In ARC, the system automatically releases any ivars for you, so if that's all you're doing you don't even have to implement dealloc. However, if you have any non-object ivars that need special handling (e.g. allocated buffers that you need to free()) you still have to deal with those in dealloc.
此外，如果您已将自己设置为任何对象的委托，则应取消设置该关系 dealloc （这是关于调用 [obj setDelegate：nil] ）。关于在未使用ARC编译的类上执行此操作的注释是对弱属性的认可。如果类明确地将其委托属性标记为弱，那么您不必这样做，因为薄弱的属性意味着它会为你填补空间。但是，如果该属性标记为 assign ，那么您应该在 dealloc 中将其取消，否则该类将保留悬挂指针，如果它试图向其委托发送消息，可能会崩溃。请注意，这仅适用于非保留关系，例如委托。
Furthermore, if you've set yourself as the delegate of any objects, you should un-set that relationship in dealloc (this is the bit about calling [obj setDelegate:nil]). The note about doing this on classes that aren't compiled with ARC is a nod towards weak properties. If the class explicitly marks its delegate property as weak then you don't have to do this, because the nature of weak properties means it'll get nilled out for you. However if the property is marked assign then you should nil it out in your dealloc, otherwise the class is left with a dangling pointer and will likely crash if it tries to message its delegate. Note that this only applies to non-retained relationships, such as delegates.
这篇关于使用ARC时，我是否在dealloc中将属性设置为nil？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
