[Weak Self]

DispatchWorkItem 내부에 중첩된 애니메이션 클로저를 실행하는 코드가 있다고 가정해보겠습니다. 여기 세 가지 버전의 코드가 있습니다. 어느 코드가 순환 참조(retained cycle)를 유발하는지 말해주실 수 있나요? class ViewControllerA: UIViewController { var workItem: DispatchWorkItem? override func viewDidLoad() { let workItem = DispatchWorkItem { UIView.animate(withDuration: 1.0) { self.view.backgroundColor = .red } } self.workItem = workItem } } class ViewControllerB: UIViewController { var workItem: DispatchWorkItem? override func viewDidLoad() { let view = self.view let workItem = DispatchWorkItem { UIView.animte(withDuration: 1.0) { [weak self] in view?.backgroundColor = .red } } self.workItem = workItem } } class ViewControllerC: UIViewController { var workItem: DispatchWorkItem? override func viewDidLoad() { let workItem = DispatchWorkItem { UIView.animate(withDuration: 1.0) { [weak self] in self?.view.backgroundColor = .red } } self.workItem = workItem } } 정답은 세 가지 버전 모두입니다! 심지어 클로저 바깥에서 _view_에 대한 참조를 생성하는 버전 B도 순환 참조를 유발합니다. ...

사이클.. 아니, 위 그림에 보이는 그런 사이클이 아닙니다. 강한 순환 참조(strong reference cycles)를 의미하며, iOS 앱에서 뷰 컨트롤러가 메모리 누수를 유발하는 원인이 됩니다. 더 구체적으로, 참조 사이클을 피하기 위해 Swift 클로저 내부에서 [weak self]의 사용법과 self를 약하게 캡처(capture)하는 게 필요하거나 필요없는 경우에 대해 살펴보고자 합니다. 이 글에서 다루는 주제는 애플 공식 문서, 다양한 블로그 포스트와 튜토리얼을 읽고, 시행착오와 실험을 통해 배웠습니다. 어딘가 실수가 있다고 생각이 되면, 자유롭게 댓글이나 트위터로 알려주세요. 또한, 메모리 누수가 일어나는 다양한 시나리오와 어디서 [weak self]를 불필요하게 사용하는지 보여주는 작은 앱도 첨부합니다. ...