Всегда ли нужно указывать weak self в замыканиях?

Всегда ли нужно указывать weak self в замыканиях?

Нет, использование weak self в замыканиях не всегда обязательно и зависит от конкретного сценария и контекста жизни объектов. Ключевой вопрос — нужно ли предотвращать цикл сильных ссылок (retain cycle), который может привести к утечкам памяти. Разберём ситуации, когда это необходимо, и когда — нет.

Когда нужно использовать weak self?

Использование weak self критически важно в двух основных случаях:

1. Когда объект self владеет замыканием, а замыкание захватывает self Это классический сценарий retain cycle. Например, когда у контроллера есть свойство с замыканием, и это замыкание ссылается на сам контроллер.

   class ViewController: UIViewController {
       var completion: (() -> Void)? // Сильная ссылка на замыкание
       
       func setup() {
           // ЗАМЫКАНИЕ ЗАХВАТЫВАЕТ self → возникает retain cycle!
           completion = {
               self.doSomething() // self захвачен strongly
           }
       }
   }
   

   Здесь нужно weak self:

   completion = { [weak self] in
       self?.doSomething()
   }
   

2. При асинхронных операциях с долгим временем жизни Например, сетевые запросы, таймеры, наблюдение за уведомлениями, где замыкание может жить долго и сохранять self после его возможного уничтожения.

   func fetchData() {
       networkService.fetch { [weak self] result in
           // Без weak self контроллер не освободится, пока запрос не завершится
           self?.handle(result)
       }
   }
   

Когда weak self можно опустить?

1. Замыкания с коротким временем жизни Например, анимации в UIKit (UIView.animate), где замыкание выполняется мгновенно и не сохраняется.

   UIView.animate(withDuration: 0.3) {
       self.view.alpha = 0 // Безопасно, т.к. замыкание выполняется и сразу уничтожается
   }
   

2. Когда self гарантированно переживает замыкание Например, в DispatchQueue.main.async, если вы уверены, что объект будет существовать до выполнения блока (хотя здесь часто всё же используют weak для безопасности).

3. Использование [unowned self] как альтернатива Применяется, когда self точно не станет nil во время выполнения замыкания, иначе это вызовет краш. Рискованный вариант.

   let handler = { [unowned self] in
       self.doSomething() // Если self уже освобождён → краш
   }
   

Практические рекомендации

• Используйте weak self в замыканиях, которые хранятся как свойства (например, completion-хендлеры в сервисах).
• Используйте weak self в асинхронных операциях, особенно в сетевых запросах или таймерах.
• Можно не использовать в синхронных и мгновенных операциях, таких как sort, map, filter для коллекций или анимациях UIKit.
• Будьте осторожны с unowned — это явная оптимизация, но она требует уверенности в жизненном цикле.

Пример сценария с анализом

class DataManager {
    var onUpdate: (() -> Void)?
    
    func startMonitoring() {
        // ПЛОХО: retain cycle, если onUpdate хранится сильно
        onUpdate = { self.logUpdate() }
        
        // ХОРОШО: weak self разрывает цикл
        onUpdate = { [weak self] in
            self?.logUpdate()
        }
    }
}

Итог: weak self — это инструмент для управления памятью, а не догма. Его применение должно быть осознанным, основанным на анализе взаимных ссылок и времени жизни объектов. В сомнительных случаях предпочтительнее использовать weak self для предотвращения трудноуловимых утечек памяти.