Where does the weak self go?
First of all, note that you generally don't need to worry about retain cycles with DispatchQueue.main.asyncAfter
, as the closure will be executed at some point. Therefore whether or not you weakly capture self
, you won't be creating a permanent retain cycle (assuming that tickle.fresh
also doesn't).
Whether or not you put a [weak self]
capture list on the outer asyncAfter
closure depends entirely on whether you want self
to be retained until the closure is called (after the time you set). If you don't need self
to remain alive until the closure is called, put [weak self]
in, if you do, then don't put it in.
Whether or not you put a [weak self]
on the inner closure (the one passed to tickle.fresh
) depends on whether you've already weakly captured self
in the outer closure. If you haven't, then you can put [weak self]
in order to prevent the inner closure from retaining it. If however, the outer closure has already weakly captured self
, then the inner closure will already have a weak reference to self
, thus adding [weak self]
to the inner closure will have no effect.
So, to summarise:
DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
tickle.fresh { msg in
self.paint()
}
}
self
will be retained by both the outer and inner closure.
DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in
tickle.fresh { msg in
self?.paint()
}
}
self
will not be retained by either closure.
DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in
tickle.fresh { [weak self] msg in
self?.paint()
}
}
Same as the above, the additional [weak self]
for the inner closure has no effect, as self
is already weakly captured by the outer closure.
DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
tickle.fresh { [weak self] msg in
self?.paint()
}
}
self
will be retained by the outer closure, but not the inner closure.
Of course, it might be that you don't want self
to be retained by the outer closure, but you do want it to be retained by the inner closure. In such cases, you can declare a local variable in the outer closure in order to hold a strong reference to self
, when you can then capture in the inner closure:
DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in
guard let strongSelf = self else { return }
tickle.fresh { msg in
strongSelf.paint()
}
}
Now, self
won't be kept alive by the outer closure, but once it's called, if self
still exists, it will be kept alive by the inner closure until that closure has been deallocated.
In response to:
Is a strong reference to a weak reference, a weak or strong reference?
Weak references are implemented as optionals, which are value types. Therefore you cannot directly have a strong reference to one – instead you first have to unwrap it, and then take a strong reference to the underlying instance. In this case you're simply dealing with a strong reference (exactly like my example above with strongSelf
).
However, if a weak reference is boxed (this happens with closure capture – the value type will be put into a heap-allocated box) – then you can indeed have a strong reference to that box. The effect of this is equivalent to a weak reference to the original instance, you just have an invisible bit of extra indirection.
In fact, this is exactly what happens in the example where the outer closure weakly captures self
and the inner closure 'strongly captures' that weak reference. The effect is that neither closure retains self
.
Fattie
Updated on January 15, 2020Comments
-
Fattie over 4 years
I often do this,
let when = DispatchTime.now() + 2.0 DispatchQueue.main.asyncAfter(deadline: when) { beep() }
and in one app we often do this
tickle.fresh(){ msg in paint() }
but if you do this
let when = DispatchTime.now() + 2.0 DispatchQueue.main.asyncAfter(deadline: when) { tickle.fresh(){ msg in paint() } }
of course you have to do this
let when = DispatchTime.now() + 2.0 DispatchQueue.main.asyncAfter(deadline: when) { [weak self] _ in tickle.fresh(){ msg in self?.paint() } }
or, maybe this
let when = DispatchTime.now() + 2.0 DispatchQueue.main.asyncAfter(deadline: when) { tickle.fresh(){ [weak self] msg in self?.paint() } }
or maybe this
let when = DispatchTime.now() + 2.0 DispatchQueue.main.asyncAfter(deadline: when) { [weak self] _ in tickle.fresh(){ [weak self] msg in self?.paint() } }
W T H should we do?
All three suggestions seem to work perfectly. What's the full depth of meaning here? And which should one do? Is a strong reference to a weak reference, a weak or strong reference? To be or not to be? That's the question!
-
Hamish over 7 years@JoeBlow It means that
self
will be kept alive by the outer closure, but once it has been executed, it could be deallocated before the inner closure gets executed (assuming that it's executed asynchronously). And in the final example, I'm using optional binding withguard let
, which unwraps the weakself
, giving me a strong reference to it :) -
Hamish over 7 years@JoeBlow Sure, there's no harm in using both – although as I say, the inner
[weak self]
is unnecessary if the outer closure capturesself
weakly. -
Hamish over 7 yearsYour note has been noted @JoeBlow :) I added a response to your question "Is a strong reference to a weak reference, a weak or strong reference?" late last night btw, don't know whether you saw it or not. The answer is it can be either – depending on how you're taking the strong reference to the weak reference.
-
GoldenJoe over 6 yearsVery nice answer.
-
Andrea Gorrieri over 5 yearsReally nice and clear answer, is there any documentation related to these ARC inner closures concepts?
-
mfaani over 4 yearsYour headline "First of all, note that you generally don't need to worry about retain cycles with " is misleading. With dispatchQueues it's NEVER a concern of 'retain cycles' The concern is mainly about 'strong references', 'abandoned memory', basically an object that is referenced from a root/global object. Roots/globals are like GCD or runloop. e.g. with Runloop and (repeating) timers. The runloop is never releasing
self
its target.self
doesn't have a reference back to the runloop. Hence it never gets deallocated. (1/2) -
mfaani over 4 yearsThe memory graph for abandoned memory is a one way linear graph that goes all the way back to a root object. For retains cycles is either a cycle or a 'two way' line in isolation. For more see here. Also see How can I create a reference cycle using dispatchQueues? and here
-
manmal over 4 yearsI have to add a caveat to the notion that, when using
asyncAfter
, a weakification is in all cases not necessary. I haven't tried it lately, but there was a time when UIViewController instances died as soon as they were removed from the view hierarchy, leading to a crash when accessing them asynchronously. Weakification mitigated this. To be fair, it probably was a bug in UIKit's memory management.