viewDidDisappear: суть метода, жизненный цикл UIViewController и когда вызывается

Что такое viewDidDisappear?

viewDidDisappear — это метод-хук суперкласса UIViewController, который система вызывает после того, как представление (view) полностью удалено из иерархии окон на экране. Он является частью стандартного жизненного цикла view в UIKit и предоставляет разработчику точку для выполнения завершающих операций.

Метод объявлен в протоколе UIViewController и доступен для переопределения во всех подклассах. Сигнатура метода: override func viewDidDisappear(_ animated: Bool). Параметр animated указывает, сопровождался ли переход анимацией. Это позволяет различать программные и анимированные переходы для более точного управления поведением.

В отличие от viewWillDisappear, который вызывается до начала анимации, viewDidDisappear гарантирует, что view уже не видна пользователю. Это критично для операций, которые должны выполняться только после полного скрытия интерфейса — например, скрытие полноэкранных overlay-элементов или завершение записи видео.

Сигнатура и объявление

Метод определён в базовом классе UIViewController и имеет следующую сигнатуру:

import UIKit

class MyViewController: UIViewController {
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        // Освобождение ресурсов и отписка
    }
}

Обязательный вызов super.viewDidDisappear(animated) в первой строке реализации — это требование UIKit. Без него суперкласс не сможет корректно завершить внутренние процессы, связанные с отображением view. Игнорирование этого правила приводит к непредсказуемому поведению навигации и потенциальным сбоям.

Место viewDidDisappear в жизненном цикле UIViewController

Полный жизненный цикл UIViewController состоит из шести ключевых методов, каждый из которых отвечает за определённую фазу существования view. viewDidDisappear завершает последовательность скрытия, следуя за viewWillDisappear. Важно понимать порядок вызова всех методов, чтобы правильно распределять инициализацию и освобождение ресурсов.

Последовательность при появлении view: viewDidLoad → viewWillAppear → viewDidAppear. При скрытии: viewWillDisappear → viewDidDisappear. Завершающая фаза — deinit, который вызывается при уничтожении объекта UIViewController. Эти шесть методов образуют полный цикл, гарантирующий предсказуемое управление состоянием.

Каждый из этих методов вызывается ровно один раз за соответствующий переход. Исключение — viewDidLoad, который может вызываться повторно, если ViewController был выгружен из памяти при нехватке ресурсов и затем восстановлен. В таком случае viewDidDisappear будет предшествовать повторному viewDidLoad.

Связь с анимацией перехода

Параметр animated в сигнатуре метода сообщает, был ли переход анимирован. Это полезно для различения программных переходов без анимации (например, при установке rootViewController) и анимированных переходов, инициированных пользователем. Если значение false, возможно, контроллер скрыт системой принудительно — в этом случае некоторые операции, зависящие от времени, могут быть неактуальны.

Когда вызывается viewDidDisappear

Система вызывает viewDidDisappear ровно в двух сценариях: когда ViewController удаляется из стека навигации и когда он покрывается другим контроллером. В обоих случаях метод сигнализирует, что view больше не видна пользователю, и разработчик должен освободить ресурсы, которые не нужны в фоне. Понимание этих сценариев предотвращает ошибочные предположения о состоянии приложения.

Первый сценарий — pop из UINavigationController. Когда пользователь нажимает кнопку "Назад", вызывается popViewController: animated. Текущий контроллер получает viewDidDisappear, а затем, если на него больше нет сильных ссылок, deinit. Второй сценарий — present/dismiss. При модальном показе нового контроллера presentingViewController получает viewDidDisappear. При dismiss этот метод вызывается у контроллера, который был показан модально.

Третий, менее очевидный сценарий — добавление child ViewController. Если в контейнерный контроллер (например, UIPageViewController или UITabBarController) добавляется новый дочерний контроллер, активный дочерний контроллер получает viewDidDisappear. Это критично для приложений с вкладками или каруселями страниц — каждая смена tab должна корректно приостанавливать работу неактивного экрана.

Исключения и неочевидные случаи

Существует важное исключение: если UIViewController отображается в модальном окне, и пользователь свайпом вниз закрывает его интерактивно, система может не вызвать viewDidDisappear при неполном свайпе. Это поведение появилось в iOS 13 вместе с интерактивным dismiss. Разработчики должны обрабатывать состояние через UIAdaptivePresentationControllerDelegate и метод didDismiss для гарантированного получения события.

Ещё одна особенность — memory warnings. При нехватке памяти система может выгрузить view контроллера, который не отображается на экране. В этом случае viewDidDisappear обычно вызывается до выгрузки, но разработчику стоит дублировать критически важные операции освобождения в didReceiveMemoryWarning для подстраховки. Такой подход предотвращает потерю данных при экстремальных сценариях.

Типичные сценарии использования

viewDidDisappear применяется для трёх основных категорий операций: остановка активностей, освобождение ресурсов и сохранение состояния. Каждая категория имеет свои best practices, выработанные сообществом iOS-разработчиков. Рассмотрим наиболее частые сценарии с примерами реализации.

• Остановка анимаций — вызов layer.removeAllAnimations() для CALayer, остановка UIView.animate блоков
• Освобождение ресурсов — обнуление больших изображений, сброс кэшированных данных, закрытие файловых дескрипторов
• Отписка от уведомлений — удаление наблюдателей из NotificationCenter.default, остановка KVO-наблюдений
• Сохранение прогресса — запись черновиков в CoreData или UserDefaults при закрытии экрана редактирования
• Скрытие overlay — убирание индикаторов загрузки, тултипов и popover-элементов, которые не должны оставаться после перехода

Пример: отписка от NotificationCenter

Типичная ошибка — подписаться на уведомления в viewDidLoad и никогда не отписываться. Это приводит к вызову обработчика на уничтоженном объекте, что вызывает crash. Правильный подход — подписка в viewWillAppear и отписка в viewDidDisappear, что гарантирует актуальность подписки только во время отображения контроллера на экране.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    NotificationCenter.default.addObserver(
        self,
        selector: #selector(handleKeyboardShow),
        name: UIResponder.keyboardWillShowNotification,
        object: nil
    )
}

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    NotificationCenter.default.removeObserver(self)
}

Такой паттерн гарантирует, что обработчик уведомлений активен только когда контроллер виден на экране. При переходе на другой экран все подписки автоматически удаляются, а при возврате восстанавливаются. Это повышает надёжность приложения и исключает класс багов, связанных с уведомлениями.

Примеры кода на Swift

Рассмотрим два практических примера использования viewDidDisappear в реальных проектах. Первый пример демонстрирует остановку таймера при скрытии экрана, второй — корректное завершение наблюдения за клавиатурой. Оба примера следуют принципу освобождения ресурсов при неактивности контроллера.

Остановка таймера

Если на экране работает Timer для обновления UI (например, обратный отсчёт или карусель), его необходимо останавливать при скрытии контроллера. Продолжение работы таймера в фоне не только потребляет ресурсы процессора, но и может вызвать исключение при попытке обновить невидимый UI.

class CountdownViewController: UIViewController {
    private var countdownTimer: Timer?
    private var remainingSeconds: Int = 60

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        startTimer()
    }

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

    private func invalidateTimer() {
        countdownTimer()?.invalidate()
        countdownTimer = nil
    }
}

Пауза видео при скрытии

Во многих приложениях AVPlayer воспроизводит видео во встроенном плеере. Если пользователь переходит на другой экран, видео должно автоматически ставиться на паузу. Реализация в viewDidDisappear гарантирует, что пауза происходит после полного скрытия экрана — это предотвращает мерцание чёрного кадра при переходе.

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    if player().timeControlStatus == .playing {
        player().pause()
        playerLayer().removeFromSuperlayer()
    }
    player = nil
}

Обнуление переменной player после паузы дополнительно освобождает память, занятую буферами видео. Этот подход особенно важен для приложений с длинными видеороликами, где буфер может занимать десятки мегабайт. Сочетание паузы с обнулением ссылок минимизирует footprint приложения в фоне.

viewDidDisappear и другие методы жизненного цикла

viewDidDisappear часто путают с viewWillDisappear и deinit, однако у каждого из этих методов своя зона ответственности. Понимание границ между ними — ключ к стабильной архитектуре iOS-приложения. Неверное использование может привести к двойному освобождению ресурсов или, наоборот, к их утечке.

Главное отличие viewDidDisappear от viewWillDisappear — момент вызова. viewWillDisappear вызывается, когда view ещё видна, но уже готовится к исчезновению. Это подходит для сохранения видимых данных (текст в полях ввода). viewDidDisappear вызывается после завершения анимации, когда view гарантированно не видна — идеально для освобождения ресурсов, не связанных с визуальным состоянием.

deinit, в отличие от viewDidDisappear, вызывается только при уничтожении объекта UIViewController в памяти. Если контроллер просто скрыт (например, покрыт модальным окном), deinit не вызывается. В этой ситуации viewDidDisappear — единственная точка для выполнения завершающих операций. Полное освобождение ресурсов должно происходить в deinit, но viewDidDisappear отвечает за временное освобождение до повторного появления.

Когда использовать какой метод

• viewWillDisappear — сохранение вводимых данных, отправка аналитики о начале перехода
• viewDidDisappear — остановка анимаций, отписка от уведомлений, скрытие overlay-элементов
• deinit — финальное освобождение больших ресурсов, закрытие сетевых соединений

При разработке с использованием SwiftUI метод viewDidDisappear не применяется — его заменяет модификатор .onDisappear, который работает аналогичным образом. Однако в SwiftUI отсутствует прямой контроль над жизненным циклом, и разработчики полагаются на Combine и State-объекты для управления ресурсами. Для UIKit-приложений viewDidDisappear остаётся основным инструментом управления скрытием экрана.

Типичные ошибки при реализации

Даже опытные iOS-разработчики допускают ошибки в работе с viewDidDisappear. Рассмотрим пять наиболее распространённых проблем и способы их предотвращения. Знание этих anti-patterns поможет избежать трудноотлавливаемых багов, связанных с жизненным циклом контроллеров.

• Пропуск super.viewDidDisappear — вызов super обязателен для корректной работы UIKit, его отсутствие может вызвать нарушение внутреннего состояния контроллера
• Тяжёлые операции в viewDidDisappear — синхронная запись больших данных в viewDidDisappear блокирует главный поток и ухудшает анимацию перехода
• Забытая отписка от уведомлений — если не вызвать removeObserver в viewDidDisappear, обработчик может сработать на zombie-объекте, вызвав EXC_BAD_ACCESS
• Двойная отписка — удаление наблюдателя, который уже был удалён в другом месте, приводит к исключению NSInternalInconsistencyException
• Зависимость от порядка вызова — во вложенных контейнерах порядок вызова viewDidDisappear у child и parent контроллеров не гарантирован

Особого внимания заслуживает потокобезопасность. Если viewDidDisappear вызывается на главном потоке (что гарантировано UIKit), но освобождение ресурсов включает асинхронные операции, необходимо синхронизировать доступ к разделяемым данным. Использование DispatchQueue.main.async внутри viewDidDisappear для обновления UI после завершения асинхронной задачи — распространённый, но корректный подход.

Ещё один важный anti-pattern — вызов методов делегата внутри viewDidDisappear, которые могут инициировать новый переход или модальный показ. Это создаёт цикл, в котором viewDidDisappear может быть вызван повторно до завершения первого вызова. Apple рекомендует избегать модальных показов внутри методов жизненного цикла, вынося их в отдельные обработчики событий.