слабый против бесхозного в Swift. Каковы внутренние различия?

У меня вопрос, какой смысл иметь два таких похожих понятия? Каковы внутренние различия, которые требуют наличия двух ключевых слов для того, что кажется на 99% одним и тем же?

Они совсем не похожи. Они настолько разные, насколько это возможно.

• weak — это очень сложная концепция, введенная вместе с введением ARC. Он выполняет почти чудодейственную задачу, позволяя вам предотвратить сохранение цикла (избегая строгой ссылки) без риска сбоя из-за висячего указателя, когда объект, на который указывает ссылка, исчезает — то, что происходило все время до ARC. был представлен.

• unowned, с другой стороны, не-ARC слабый (точнее, это то же самое, что и не-ARC assign). Это это то, чем мы привыкли рисковать, это это причина стольких сбоев до того, как была введена ARC. Это очень опасно, потому что вы можете получить висячий указатель и аварийное завершение работы, если указанный объект перестанет существовать.

Причина различия в том, что weak для того, чтобы совершить свое чудо, требует множества дополнительных накладных расходов для среды выполнения, вставляемых за кулисами компилятором. weak ссылки управляются для вас памятью. В частности, среда выполнения должна поддерживать блокнот всех ссылок, помеченных таким образом, отслеживая их, чтобы, если объект, на который слабо ссылаются, прекратит существование, среда выполнения могла найти эту ссылку и заменить ее на nil для предотвращения висячего указателя.

Как следствие, в Swift ссылка weak всегда относится к необязательному (именно так, чтобы ее можно было заменить на nil). Это дополнительный источник накладных расходов, потому что работа с необязательным влечет за собой дополнительную работу, так как он всегда должен быть развернут, чтобы что-то сделать с ним.

По этой причине unowned всегда следует отдавать предпочтение везде, где это применимо. Но никогда не используйте его, если это не абсолютно безопасно! С unowned вы отбрасываете автоматическое управление памятью и безопасность. Вы намеренно возвращаетесь к старым недобрым временам до ARC.

В моем случае общий случай возникает в ситуациях, когда для замыкания требуется список захвата, включающий self, чтобы избежать цикла сохранения. В такой ситуации почти всегда можно сказать [unowned self] в списке захвата. Когда мы делаем:

• Программисту удобнее, потому что распаковывать нечего. [weak self] будет необязательным, и его нужно развернуть, чтобы использовать.

• Он более эффективен, отчасти по той же причине (распаковка всегда добавляет дополнительный уровень косвенности), а отчасти потому, что это на одну слабую ссылку меньше для отслеживания списка блокнота среды выполнения.

Ссылка weak на самом деле установлена ​​на nil, и вы должны проверить ее, когда референт освободится, а ссылка unowned будет установлена ​​на nil, но вы не обязаны ее проверять.

Вы можете проверить weak на nil с помощью if let, guard, ? и т. д., но нет смысла проверять unowned, потому что вы думаете, что это невозможно. Если вы ошибаетесь, вы падаете.

Я обнаружил, что на практике я никогда не использую unowned. Это незначительное снижение производительности, но дополнительная безопасность от использования weak стоит того.

Я бы оставил бесхозное использование для очень конкретного кода, который необходимо оптимизировать, а не для общего кода приложения.

«Почему он существует», который вы ищете, заключается в том, что Swift предназначен для написания системного кода (например, ядра ОС), и если бы у них не было самых основных примитивов без дополнительного поведения, они не могли бы этого сделать .

ПРИМЕЧАНИЕ. Ранее в этом ответе я уже говорил, что значение unowned не равно нулю. Это неправильно, голый unowned равен нулю. unowned(unsafe) не равно нулю и может быть висячим указателем. Это необходимо для обеспечения высокой производительности и, как правило, не должно быть в коде приложения.