Выбор ответа Middle ARC и циклы ссылок обновлено
Почему Timer держит контроллер
Вопрос
Контроллер создаёт Timer.scheduledTimer(timeInterval:target: self, selector:..., repeats: true) и инвалидирует таймер в deinit. Почему deinit никогда не вызывается?
Попробуйте сами
Выберите вариант, и откроется разбор.
Показать ответ и разбор
Коротко
Правильный ответ: Таймер сильно держит target, а run loop держит таймер. Run loop удерживает запланированный таймер, а таймер с target-action сильно удерживает target.
Варианты ответа
deinitу контроллеров не вызывается, их освобождает UIKit по-своему- Таймер сильно держит
target, а run loop держит таймерправильный ответ - Таймер держит контроллер слабо, а проблема в неверном селекторе
- Повторяющиеся таймеры сами инвалидируются в
deinit, и он зацикливается
Разбор
Run loop удерживает запланированный таймер, а таймер с target-action сильно удерживает target. Инвалидация в deinit это замкнутый круг: deinit не наступит, пока таймер жив. Правильно: инвалидировать в viewWillDisappear или использовать блочный API с [weak self] и инвалидировать в deinit. У контроллеров deinit вызывается нормально, если нет лишних ссылок.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Ещё по теме «ARC и циклы ссылок»
- Когда нужен autoreleasepool в Swift
- Цикл ссылок через замыкание-свойство
- Почему делегат объявляют weak
- DispatchQueue.main.async и self
- Как найти утечку памяти в iOS-приложении
- Жизненный цикл объекта в Swift-рантайме
- Когда уместен unowned
- Задача на Swift: какие объекты утекут из-за циклов ссылок