Почему подписки и отписки на события опасно делать в viewDidLoad?

Question

viewDidLoad вызывается обычно один раз, но экран может появляться и исчезать много раз. Если подписаться в viewDidLoad, события будут приходить даже когда экран не виден, а отписка “в другом месте” легко забудется или не отработает в edge-кейсах. Это приводит к утечкам, дублям обработчиков и багам с состоянием. Подписки обычно привязывают к viewWillAppear/viewDidDisappear или к более явному жизненному циклу объекта.

YeaHub · Accepted Answer

Опасность в том, что viewDidLoad относится к моменту создания view, а подписки относятся к моменту активности экрана. Эти вещи не совпадают по времени.1) Несовпадение смысловviewDidLoad:вызывается, когда view созданаможет случиться задолго до первого показаобычно не повторяетсяподписка:должна быть активна, пока экран “живой” или “видимый”часто должна включаться и выключаться много разЕсли подписался в viewDidLoad, а экран:ушёл в backgroundперекрылся модалкойбыл скрыт другим экраномто события всё равно могут продолжить приходить.2) Типовые проблемыДубли обработчиковесли подписка где-то повторяется (например, при пересоздании view), можно случайно получить несколько одинаковых подписокрезультат: обработчик срабатывает 2-3-10 разУтечки памятиподписка удерживает объект (прямо или косвенно)контроллер не деинициализируется, потому что “на него кто-то подписан”События приходят в невидимый экранUI обновляется, когда пользователь экран не видитвозможны краши из-за обращения к состоянию, которое уже неактуальноСложные сценарии переходовинтерактивные dismiss/pop могут быть отмененыметоды жизненного цикла могут вызываться не в ожидаемой пареВ таких сценариях “подписался в didLoad, отписался в willDisappear” легко даёт расхождение.3) Примеры, где это особенно больноNotificationCenterNotificationCenter.default.addObserver(
    self,
    selector: #selector(handle),
    name: UIApplication.didEnterBackgroundNotification,
    object: nil
)
// если не удалить observer — проблемы (утечки, неожиданные вызовы)
KVO / наблюдениеесли не снять наблюдение, можно получить краш при деинициализацииCombine / Rxподписки живут дольше экрана, если их не очищать4) Как правильнее мыслить про подпискиЧтобы не ловить баги, полезно разделять подписки на типы:Подписки, которые нужны пока экран виденвключать в viewWillAppearвыключать в viewDidDisappearПодписки, которые нужны пока существует контроллерподписываться при создании (или в viewDidLoad)обязательно отписываться в deinitПодписки, которые должны переживать экранывыносить в сервисы / менеджеры, а не держать во вью-контроллере5) Мини-шаблон (логика без больших блоков)Идея: делать жизненный цикл подписки симметричным.override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    // subscribe()
}

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    // unsubscribe()
}

deinit {
    // на всякий случай: cleanup, removeObserver, cancel tokens
}
Краткий выводПодписки в viewDidLoad опасны, потому что viewDidLoad почти не повторяется, а “активность экрана” повторяется постоянно. Привязывай подписки либо к появлению/исчезновению (viewWillAppear/viewDidDisappear), либо к жизни объекта (deinit) — в зависимости от смысла.