在2014年WWDC会议403中，有以下幻灯片
演讲者说，在那种情况下，如果我们不在那里使用[u主self]，就会发生内存泄漏。这是否意味着我们应该总是在闭包中使用[ucontrolled self] ?
在Swift Weather应用程序的ViewController.swift的第64行，我没有使用[u主self]。但是我通过使用一些@ iboutlet来更新UI，比如self。温度和自加载指示器。这可能没问题，因为我定义的所有@IBOutlets都是弱的。但是为了安全起见，我们应该总是使用[无主的自我]吗?
class TempNotifier {
var onChange: (Int) -> Void = {_ in }
var currentTemp = 72
init() {
onChange = { [unowned self] temp in
self.currentTemp = temp
}
}
}
当前回答
根据Apple-doc
弱引用总是可选类型，并且是自动的 当它们引用的实例被释放时变为nil。 如果捕获的引用永远不会变成nil，那么它应该始终被捕获为无主引用，而不是弱引用
的例子,
// if my response can nil use [weak self]
resource.request().onComplete { [weak self] response in
guard let strongSelf = self else {
return
}
let model = strongSelf.updateModel(response)
strongSelf.updateUI(model)
}
// Only use [unowned self] unowned if guarantees that response never nil
resource.request().onComplete { [unowned self] response in
let model = self.updateModel(response)
self.updateUI(model)
}
其他回答
如果以上都说不通:
博士tl;
就像一个隐式打开的可选选项，如果你能保证 引用在它的使用点不会为nil，使用无主。 如果不是，那么你应该使用weak。
解释:
我检索了以下在:弱无主链接。从我收集到的，无主self不能为nil，但弱self可以，并且无主self可以导致悬空指针…这在Objective-C中是臭名昭著的。希望能有所帮助
“无主弱引用和无主引用行为相似，但并不相同。”
Unowned references, like weak references, do not increase the retain count of the object being referred. However, in Swift, an unowned reference has the added benefit of not being an Optional. This makes them easier to manage rather than resorting to using optional binding. This is not unlike Implicitly Unwrapped Optionals . In addition, unowned references are non-zeroing. This means that when the object is deallocated, it does not zero out the pointer. This means that use of unowned references can, in some cases, lead to dangling pointers. For you nerds out there that remember the Objective-C days like I do, unowned references map to unsafe_unretained references.
这就是让人有点困惑的地方。
弱引用和无主引用都不会增加保留计数。
它们都可以用来打破保留循环。那么我们什么时候使用它们呢?
苹果公司的文件显示:
“当一个引用在其生命周期的某个时间点变成nil是有效的时，就使用弱引用。相反，当你知道在初始化过程中设置的引用永远不会为nil时，使用无主引用。”
如果self可以在闭包中为nil，请使用[weak self]。
如果self在闭包中永远不会为nil，请使用[无主的self]。
Apple Swift文档中有一个很好的章节，用图片解释了在闭包中使用strong、weak和u主的区别:
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html
这里有一些很好的答案。但是最近对Swift实现弱引用方式的改变应该会改变每个人对弱self和无主self的使用决策。以前，如果你需要最好的性能，使用无主的自我优于弱自我，只要你能确定自我永远不会为nil，因为访问无主的自我比访问弱自我快得多。
但是Mike Ash已经记录了Swift如何更新弱变量的实现以使用侧边表，以及这如何极大地提高弱自我性能。
https://mikeash.com/pyblog/friday-qa-2017-09-22-swift-4-weak-references.html
Now that there isn't a significant performance penalty to weak self, I believe we should default to using it going forward. The benefit of weak self is that it's an optional, which makes it far easier to write more correct code, it's basically the reason Swift is such a great language. You may think you know which situations are safe for the use of unowned self, but my experience reviewing lots of other developers code is, most don't. I've fixed lots of crashes where unowned self was deallocated, usually in situations where a background thread completes after a controller is deallocated.
bug和崩溃是编程中最耗时、最痛苦、最昂贵的部分。尽最大努力编写正确的代码并避免它们。我建议制定一条规则，永远不要强制打开可选项，永远不要使用无主self而不是弱self。你不会失去任何东西，失去时代的力量和无主的自我其实是安全的。但是，您将从消除难以发现和调试的崩溃和错误中获益良多。
不，有些时候你肯定不想使用[u主self]。有时你想让闭包捕获self以确保在闭包被调用时它仍然存在。
示例:发起异步网络请求
如果您正在发出异步网络请求，您确实希望闭包在请求完成时保持自我。该对象可能已经被释放，但您仍然希望能够处理请求的完成。
何时使用无主自我或弱自我
真正需要使用[un主self]或[weak self]的唯一时候是创建强引用循环的时候。强引用循环是指存在一个所有权循环，其中对象最终拥有彼此(可能通过第三方)，因此它们永远不会被释放，因为它们都确保彼此存在。
In the specific case of a closure, you just need to realize that any variable that is referenced inside of it, gets "owned" by the closure. As long as the closure is around, those objects are guaranteed to be around. The only way to stop that ownership, is to do the [unowned self] or [weak self]. So if a class owns a closure, and that closure captures a strong reference to that class, then you have a strong reference cycle between the closure and the class. This also includes if the class owns something that owns the closure.
特别是在视频中的例子中
在幻灯片上的示例中，TempNotifier通过onChange成员变量拥有闭包。如果它们没有声明self为无主的，闭包也将拥有self，从而创建一个强引用循环。
无主和弱的区别
u主和weak的区别在于weak被声明为Optional，而u主则不是。通过声明它为弱，你可以处理闭包中某个时刻它可能为nil的情况。如果你试图访问一个无主变量，而这个变量恰好是nil，它将使整个程序崩溃。所以只有当你确定这个变量在闭包存在的时候才使用un主
unowned is similar to weak they don't a retained object from being destroyed, but weak variables turned to nil when the object its a reference to no longer exists, which we can handle with the normal checking of nils, unowned will just become garbage, you can't tell they are no longer garbage and using them will crash. The problem with weak is if an object has references to it by weak variables, when its destroyed, it has to go through every reference to it and set that variable to nil, this clearly is going to be expensive, using unowned instead is going just crash and finding this kind of bug is going to be difficult. One place to use unowned is if you are creating some carefully contained datatype, which has a clear interface, and its internals are not directly accessible, for you implementation it may be useful to have lots of circular references but that are self contained, you can used unowned references to let you break those circular references, with out the expense of weak variables, for example you may have a node tree, and each node needs has to have a reference to its parent, deleting a node is going to delete all its children, so there is no point of all the children having to have all there parent references set to nil.
