ARC (Automatic Reference Counting) beheert geheugen voor class-instanties door strong references tijdens het compileren bij te houden: de compiler voegt retain/release-aanroepen in, en wanneer de strong-telling van een object nul bereikt wordt het onmiddellijk gedealloceerd — deterministisch, niet door een garbage collector op de achtergrond.
nil gezet bij deallocatie. Moet var en optional zijn.unowned(unsafe)).final class Customer {
var card: Card? // strong: customer bezit card
}
final class Card {
unowned let owner: Customer // unowned: card leeft nooit langer dan zijn owner
init(owner: Customer) { self.owner = owner }
}
Kies op basis van de levensduurrelatie, niet uit gewoonte:
| weak | unowned | |
|---|---|---|
| Optional | ja (wordt nil) | nee |
| ARC-kosten | iets hoger (bijgehouden) | lager |
| Veilig als het andere object weg is | ja | crash |
| Gebruik wanneer | de referentie legitiem nil kan worden (delegates, parent die eerder gedealloceerd kan worden) | de referentie gegarandeerd langer leeft dan self (child → verplichte parent) |
!-markeringen signaleren cycli.deinit-logging — de snelste sanity check: als deinit nooit print wanneer een scherm sluit, is dat object gelekt.deinit { print("released \(Self.self)") } // stilte bij dismiss = leak
Escaping closures die self capturen, tweerichtings strong references tussen parent en child, Timer/DispatchSourceTimer die hun target vasthouden, en Combine-subscriptions die niet zijn opgeslagen in een cancellable die gedealloceerd wordt.
ARC is deterministisch, dus leaks zijn jouw verantwoordelijkheid, niet die van een GC — een enkele vastgehouden view controller kan megabytes aan afbeeldingen en zijn hele object graph vastpinnen. Senior interviews peilen dit omdat het correct kiezen tussen weak en unowned en weten hoe je een leak met de memory graph bewijst, is wat langlopende apps ervan weerhoudt op te zwellen.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren