Какой runtime-компромисс появляется при использовании weak-ссылки вместо strong?
weak-ссылка не удерживает объект, но требует от ARC дополнительного отслеживания для автоматического обнуления после уничтожения объекта. Поэтому её чтение и обслуживание обычно сложнее и потенциально дороже, чем работа с обычной strong-ссылкой.
ARC автоматизировал управление сильными ссылками, но не устранил необходимость моделировать связи между объектами. Для делегатов, владельцев callback-объектов и других неосвобождающих связей понадобился безопасный способ не допустить циклов удержания.
weak решает эту задачу ценой дополнительной runtime-механики: система должна знать, какие слабые ссылки указывают на объект, чтобы сделать их nil до того, как к уже уничтоженному объекту обратятся.
Обычная сильная ссылка увеличивает число владельцев объекта и обычно сводится к простой операции удержания или освобождения. Слабая ссылка не увеличивает это число, но при уничтожении объекта должна стать безопасно недействительной.
Если заменить strong на weak без необходимости, объект может исчезнуть раньше ожидаемого. Если же везде использовать strong, возрастает риск циклов удержания. Поэтому выбор ссылки влияет не только на время жизни, но и на стоимость доступа и обслуживания связи.
При создании или изменении weak-ссылки ARC регистрирует её в служебной инфраструктуре runtime. Когда последний владелец объекта освобождает его, runtime перед завершением уничтожения находит связанные слабые ссылки и обнуляет их.
Чтение weak-ссылки также не является простым чтением адреса. Runtime проверяет состояние ссылки и обычно временно получает сильную локальную фиксацию объекта на время используемой операции, чтобы объект не исчез посреди обращения. Точные внутренние структуры и стоимость зависят от реализации Swift и платформы, поэтому нельзя привязывать поведение к конкретному числу операций или структуре памяти.
Практический компромисс таков:
nil, но требует runtime-обслуживания, optional-проверок и не гарантирует наличие объекта;В приложении контроллер хранит callback от большого количества короткоживущих объектов. Разработчик делает все обратные ссылки weak, чтобы исключить циклы, но callback вызывается в горячем цикле и постоянно читает эти ссылки.
Вариант с strong-ссылками ускоряет доступ и гарантирует наличие объектов, однако может удерживать их дольше нужного и усложнить освобождение графа. Вариант с weak безопаснее для владения, но добавляет проверки, optional-распаковку и runtime-обслуживание слабых ссылок.
Разумное решение — оставить weak только на границах владения, где она действительно разрывает цикл, а внутри краткой операции сначала получить локальную strong-ссылку. Это одновременно фиксирует объект на время операции и не заставляет весь объектный граф владеть им постоянно. Если участок критичен по производительности, выбор подтверждают профилированием, а не предположением о стоимости ARC.
1. Означает ли weak, что объект освобождается сразу после исчезновения последней strong-ссылки?
Нет. Weak-ссылка сама объект не удерживает, поэтому она не откладывает его уничтожение. Однако фактический момент освобождения может зависеть от других сильных ссылок, временных удержаний, особенностей вызова и оптимизаций ARC. После уничтожения объекта weak-ссылка должна быть обнулена runtime.
2. Является ли weak-ссылка просто адресом, который заменяется на nil?
Нет. Для безопасного обнуления runtime должен отслеживать weak-ссылки, связанные с объектом. Конкретная реализация скрыта и может меняться, но полагаться на weak как на обычное чтение указателя нельзя: её значение может исчезнуть, а доступ требует специальной обработки.
3. Нужно ли заменять все strong-ссылки на weak ради экономии памяти?
Нет. Weak не является универсальной оптимизацией памяти. Она меняет семантику владения, допускает исчезновение объекта и обычно добавляет runtime-накладные расходы. Сильная ссылка должна использоваться там, где объект действительно является частью времени жизни владельца, а weak — там, где связь не должна продлевать жизнь объекта или иначе возникает цикл.