#iOSКомпас 🧭
1️⃣7️⃣5️⃣ Завдання 175

ARC: компілятор проти рантайму, хто що робить насправді?

З вами знову той самий автор каналу @badlinkschannel. Сподіваюсь вам ще не набридла ця ідея капітана галери про iOS розробника.

🤔 Керування пам'яттю у Swift - одна з тих тем, яку проходять усі, але мало хто справді розуміє. Особливо це стосується Automatic Reference Counting (ARC). Ми звикли думати про нього як про чарівний збирач сміття, який десь там, у надрах системи, стежить за нашими об'єктами. Але реальність набагато цікавіша й прозаїчніша. ARC - це насамперед компіляторна технологія, і саме тут ховається більшість непорозумінь.

🔣 Компілятор як головний архітектор пам'яті:

Уявіть архітектора, який проєктує будинок. Він не будує його сам - для цього є будівельники. Але він створює детальні креслення, де кожна балка, кожен електричний ланцюг, кожна труба мають своє місце. ARC у Swift - приблизно такий архітектор. Коли ви пишете:

class User {
let name: String
init(name: String) { self.name = name }
}

func createUser() {
let user = User(name: "Олексій")
// щось робимо з user
}

Компілятор аналізує ownership і lifetime значень та генерує необхідні операції керування пам'яттю. Грубо кажучи, для нативного Swift-об'єкта це можна уявити приблизно так:

func createUser() {
let user = User(name: "Олексій")
// swift_retain там, де він справді потрібен
// щось робимо з user
// swift_release, коли володіння закінчується
}

Причому це саме спрощена модель. Оптимізатор може прибирати зайві retain/release, об'єднувати їх або взагалі змінювати lifetime об'єкта.

Ключовий момент: ARC не є збирачем сміття, який у рантаймі періодично шукає непотрібні об'єкти. Компілятор визначає правила ownership і генерує відповідні операції, а вже рантайм виконує їх.

🔣 Рантайм - виконавець:

Якщо ARC - архітектор, то рантайм - будівельна бригада, яка працює за кресленнями. Коли виконується `swift_retain`, Swift runtime збільшує strong reference count. Коли виконується `swift_release` - зменшує його. Якщо останнє сильне посилання зникає - об'єкт проходить процедуру знищення.

І тут важливий нюанс: Swift не просто використовує Objective-C runtime для всіх своїх об'єктів. Нативні Swift-об'єкти мають власний механізм reference counting у Swift runtime. А `objc_retain` та `objc_release` з'являються там, де ми маємо справу з Objective-C-об'єктами та bridging.

Тобто reference count - це не якась абстрактна магія ARC. Це частина низькорівневого стану об'єкта, якою керує runtime. Нормального публічного Swift API, на який можна покластися для читання цього лічильника, у нас немає.

🔣 Autorelease - не те, що ви думаєте:

Слово autorelease викликає найдивніші асоціації. «Автоматичне звільнення»? «Відкладений збирач сміття»? Насправді все набагато простіше.

Autorelease не звільняє об'єкт одразу. Він означає приблизно таке: «Відклади відповідний release до моменту, коли поточний autorelease pool буде очищено».

Особливо це актуально на межі Swift та Objective-C, де продовжують діяти Objective-C conventions і Foundation API можуть повертати autoreleased об'єкти.

Autorelease pool при цьому теж не магічний контейнер зі своїм збирачем сміття. Як спрощену модель його можна уявляти як механізм, який реєструє autoreleased об'єкти та відкладає відповідні release до моменту очищення pool.

У чистому Swift-коді ви зазвичай працюєте зі Swift ARC та ownership напряму, а autorelease найчастіше стає помітним саме при взаємодії з Objective-C та Foundation.

#️⃣ ARC у Swift - це не магія і не активний збирач сміття. Компілятор аналізує ownership і генерує операції керування lifetime об'єктів, а Swift runtime вже виконує низькорівневу роботу - reference counting, знищення об'єктів та інші пов'язані операції.

Розуміння цього розподілу відповідальності критично важливе. Воно пояснює, чому одні оптимізації пам'яті працюють, а інші - ні. Чому autorelease pool важливий в одних контекстах і майже непомітний в інших. І чому reference count - це деталь реалізації runtime, а не лічильник, на який має спиратися ваш Swift-код.

@Zatishna_Galera