ARC (Automatic Reference Counting) hanterar minne för klassinstanser genom att spåra starka referenser vid kompilering: kompilatorn infogar retain/release-anrop, och när ett objekts starka räknare når noll deallokeras det omedelbart — deterministiskt, inte av en garbage collector i bakgrunden.
nil vid deallokering. Måste vara var och optional.unowned(unsafe)).final class Customer {
var card: Card? // strong: customer owns card
}
final class Card {
unowned let owner: Customer // unowned: card never outlives its owner
init(owner: Customer) { self.owner = owner }
}
Välj utifrån livslängdsrelation, inte av vana:
| weak | unowned | |
|---|---|---|
| Optional | ja (blir nil) | nej |
| ARC-kostnad | något högre (spåras) | lägre |
| Säker om andra objektet är borta | ja | krasch |
| Använd när | referensen kan legitimt bli nil (delegates, förälder som kan deallokeras först) | referensen garanteras överleva self (barn → obligatorisk förälder) |
!-markörer flaggar cykler.deinit-loggning — det snabbaste sanity-testet: om deinit aldrig skrivs ut när en skärm stängs har objektet läckt.deinit { print("released \(Self.self)") } // silence on dismiss = leak
Escaping closures som fångar self, dubbelriktade starka förälder/barn-referenser, Timer/DispatchSourceTimer som håller kvar sitt target, och Combine-prenumerationer som inte lagras i en cancellable som deallokeras.
ARC är deterministiskt, så läckor är ditt ansvar, inte en GC:s — en enda kvarhållen view controller kan låsa fast megabyte av bilder och hela sin objektgraf. Senior-intervjuer undersöker detta eftersom att korrekt välja weak kontra unowned och veta hur man bevisar en läcka med memory graph är vad som håller långkörande appar från att svälla.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera