swift - 无主与弱者。为什么我们应该更喜欢无主？

Question

正如 Apple 在“The Swift Programming Language”中所说的，似乎我们应该尽可能地使用 unowned 而不是 weak:

If the captured reference will never become nil, it should always be captured as an unowned reference, rather than a weak reference.

来自 this page 上的“弱引用和无主引用”部分

我确实知道这两者之间的区别。但我很好奇是否有任何充分的理由更喜欢 unowned 而不是 weak？我认为 weak 更安全，我们总是可以编写 [weak obj] 和一个可选的绑定(bind)检查，而不考虑 obj .

它是否与某些性能考虑有关或我错过了什么？或者一直使用 weak 而不是 unowned 是完全可以的吗？

Answer 1

一旦弱引用指向的对象被释放，它们就会自动设置为nil。为了在 Swift 中实现这一点，这些必须声明为 var 和可选的:

class SomeOtherClass {
    weak var weakProperty: SomeClass?
}

如果 weakProperty 可以变成 nil 而 SomeOtherClass 的实例仍然存在并且我们想在使用之前检查它，这很好它(代表就是这样的一个例子)。但是，如果某些引用在逻辑上永远不应该是 nil 并且我们仍然想防止保留循环怎么办？在 Objective-C 中，任何对象引用都可以是 nil(并且消息传递 nil 总是默默地失败)所以没有两难选择，我们总是使用 weak。但是 Swift 根本没有可空引用。我们将可选项用于语义上可能缺乏值(value)的事物。但是我们不应该为了能够打破保留循环而被迫对必须始终有值(value)的东西使用可选值。这种做法将违背可选项的预期语义。

这就是 unowned 的用武之地。它有两种风格 - unowned(safe) 和 unowned(unsafe)。后者是危险的，它等同于 Objective-C 中的 assign 和 unsafe_unretained。但是前者是默认的(至少在调试时是这样；不确定他们是否在发布版本中将其优化为 unowned(unsafe))，如果引用的对象被过早释放，将会使您的应用可靠地崩溃.当然，如果出现问题，您的应用程序会崩溃，但这比静默失败更容易调试。它应该只在你真正想要的时候默默地失败(在这种情况下你会使用weak)