Разбор последствий: способна ли deinit продлить жизнь экземпляра, сохранив self в сильной ссылке?
Нет. deinit вызывается уже после того, как ARC обнаружил отсутствие сильных ссылок, поэтому сохранение self внутри deinit не может надёжно воскресить экземпляр. Если объект должен жить дольше, сильный владелец должен существовать до начала уничтожения.
ARC автоматизирует подсчёт ссылок, который раньше требовал ручного управления операциями удержания и освобождения объекта. Такой подход сохраняет детерминированное освобождение ресурсов, но не является сборкой мусора: момент уничтожения определяется владением, а не периодическим обходом графа объектов.
Модель ARC предполагает, что после перехода счётчика сильных ссылок к нулю объект завершает жизненный цикл. Возможность «воскресить» объект во время финализации разрушила бы предсказуемость этой модели и усложнила бы освобождение его свойств и памяти.
Последний сильный владелец может исчезнуть в результате присваивания, выхода из области видимости или завершения асинхронной операции. После этого ARC запускает deinit, где разработчик обычно освобождает внешние ресурсы: отписывается от уведомлений, закрывает дескриптор или отменяет наблюдение.
Ошибочно считать deinit последним шансом сохранить объект в кэше или глобальном хранилище. В этот момент экземпляр уже находится в процессе окончательного разрушения; попытка использовать его как обычный живой объект приводит к некорректной логике, а при обходе ограничений Swift — к неопределённому поведению.
ARC уменьшает число сильных ссылок при их уничтожении или переназначении. Когда сильных ссылок больше нет, ARC запускает deinit, затем разрушает хранилище экземпляра и освобождает память. deinit — финализатор, а не обычный метод, способный отменить это решение.
Даже если внутри deinit доступен self, это не означает, что экземпляр снова становится пригодным для владения. Нельзя рассчитывать на публикацию self в глобальное хранилище, передачу его в долгоживущий callback или создание цикла ссылок, который остановит уничтожение.
Если требуется сохранить объект, это нужно сделать раньше: передать его другому владельцу или изменить архитектуру так, чтобы жизнью ресурса управлял отдельный объект. Для операций, которые должны выполняться явно и могут продлить работу, лучше использовать метод вроде close или stop, а deinit оставить резервной очисткой.
Использование Unmanaged, небезопасных указателей или низкоуровневого Objective-C-кода не меняет гарантии обычного Swift-владения. Такие механизмы могут обойти статические проверки, но ответственность за корректное время жизни полностью переходит к разработчику.
Контроллер в deinit пытается добавить себя в глобальный кэш, чтобы сохранить состояние для следующего экрана. Это неверно: deinit уже означает отсутствие сильных владельцев, поэтому кэширование в этот момент не является способом продлить жизнь контроллера.
Вариант с сохранением самого контроллера в кэше следует заменить сохранением отдельной модели состояния. Альтернатива — передать контроллер кэшу до обнуления последней внешней ссылки, но это создаёт дополнительного владельца и риск утечки.
Практичное решение — заранее сохранить независимое состояние, выполнить явное завершение работы контроллера, а в deinit оставить только защитную очистку. Так жизненный цикл UI-объекта не смешивается с жизненным циклом данных, а уничтожение остаётся предсказуемым.
Можно ли вызвать deinit вручную, а затем продолжить пользоваться объектом?
Нет. deinit вызывается только механизмом ARC, когда экземпляр становится недоступным через сильные ссылки. Ручной вызов не разрешён, потому что разрушение объекта включает не только пользовательскую очистку, но и корректное уничтожение его хранилища и цепочки классов.
Продлит ли жизнь объекта сильная ссылка, созданная в самом начале deinit?
Нет. К началу deinit объект уже признан ARC готовым к уничтожению. Новая ссылка, созданная в этот момент или опубликованная через небезопасный механизм, не превращает финализацию в обычное состояние владения и не даёт гарантии, что объект можно безопасно использовать.
Как спроектировать действие, которое должно завершить работу до уничтожения объекта?
Вынести его в явный метод жизненного цикла, например stop, close или invalidate, и вызвать его пока существует сильный владелец. deinit должен служить страховочным механизмом для освобождения ресурсов, но не заменять обязательный протокол завершения работы.