ARC (Automatic Reference Counting) gestisce la memoria per le istanze di classe tracciando i reference strong in fase di compilazione: il compilatore inserisce le chiamate retain/release, e quando il conteggio strong di un oggetto raggiunge zero viene deallocato immediatamente — in modo deterministico, non tramite un garbage collector in background.
nil alla deallocazione. Deve essere var e optional.unowned(unsafe)).final class Customer {
var card: Card? // strong: il customer possiede la card
}
final class Card {
unowned let owner: Customer // unowned: la card non sopravvive mai al suo owner
init(owner: Customer) { self.owner = owner }
}
Scegli in base alla relazione di durata, non per abitudine:
| weak | unowned | |
|---|---|---|
| Optional | sì (diventa nil) | no |
| Costo ARC | leggermente più alto (tracciato) | più basso |
| Sicuro se l'altro oggetto non c'è più | sì | crash |
| Usa quando | il reference può legittimamente diventare nil (delegate, parent che può deallocarsi prima) | il reference è garantito sopravvivere a self (child → parent obbligatorio) |
! segnalano i cicli.deinit — la verifica di sanità più rapida: se deinit non stampa mai quando una schermata si chiude, quell'oggetto ha fatto leak.deinit { print("released \(Self.self)") } // silenzio alla chiusura = leak
Closure escaping che catturano self, reference strong bidirezionali parent/child, Timer/DispatchSourceTimer che trattengono il loro target e subscription di Combine non memorizzate in un cancellable che si dealloca.
ARC è deterministico, quindi i leak sono responsabilità tua, non di un GC — un singolo view controller trattenuto può bloccare megabyte di immagini e l'intero suo grafo di oggetti. I colloqui senior indagano su questo perché scegliere correttamente tra weak e unowned e saper dimostrare un leak con il memory graph è ciò che impedisce alle app di lunga durata di gonfiarsi.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona