ARC (Automatic Reference Counting) styrer minne for klasseinstanser ved å spore sterke referanser på kompileringstidspunktet: kompilatoren setter inn retain/release-kall, og når et objekts sterke telling når null, deallokeres det umiddelbart — deterministisk, ikke av en garbage collector i bakgrunnen.
nil ved deallokering. Må være var og optional.unowned(unsafe)).final class Customer {
var card: Card? // strong: customer eier card
}
final class Card {
unowned let owner: Customer // unowned: card overlever aldri sin eier
init(owner: Customer) { self.owner = owner }
}
Velg etter levetidsrelasjon, ikke etter vane:
| weak | unowned | |
|---|---|---|
| Optional | ja (blir nil) | nei |
| ARC-kostnad | litt høyere (spores) | lavere |
| Trygg hvis andre objekt er borte | ja | krasj |
| Bruk når | referansen kan legitimt bli nil (delegates, forelder som kan deallokeres først) | referansen er garantert å overleve self (barn → obligatorisk forelder) |
!-markører flagger sykluser.deinit-logging — den raskeste fornuftssjekken: hvis deinit aldri skrives ut når en skjerm lukkes, lekket det objektet.deinit { print("released \(Self.self)") } // stillhet ved dismiss = lekkasje
Escaping closures som fanger self, toveis forelder/barn-sterke referanser, Timer/DispatchSourceTimer som beholder sitt mål, og Combine-abonnementer som ikke er lagret i en cancellable som deallokeres.
ARC er deterministisk, så lekkasjer er ditt ansvar, ikke en GCs — en enkelt beholdt view controller kan pinne megabyte med bilder og hele objektgrafen sin. Senior-intervjuer undersøker dette fordi korrekt valg av weak kontra unowned og det å vite hvordan man beviser en lekkasje med memory-grafen er det som holder langvarige apper fra å svulme opp.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner