ARC (Automatic Reference Counting) verwaltet den Speicher für Klasseninstanzen, indem es Strong References zur Compile-Zeit verfolgt: Der Compiler fügt retain/release-Aufrufe ein, und sobald der Strong Count eines Objekts null erreicht, wird es sofort dealloziert — deterministisch, nicht durch einen im Hintergrund laufenden Garbage Collector.
nil gesetzt. Muss var und optional sein.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 }
}
Entscheide nach der Lebensdauer-Beziehung, nicht aus Gewohnheit:
| weak | unowned | |
|---|---|---|
| Optional | ja (wird nil) | nein |
| ARC-Kosten | etwas höher (getrackt) | geringer |
| Sicher, wenn anderes Objekt weg | ja | Absturz |
| Verwenden, wenn | die Referenz legitim nil werden kann (Delegates, Parent, der zuerst dealloziert werden kann) | garantiert ist, dass die Referenz self überlebt (Child → verpflichtender Parent) |
!-Markierungen kennzeichnen Zyklen.deinit-Logging — der schnellste Plausibilitätscheck: Wenn deinit beim Schließen eines Screens nie ausgegeben wird, ist dieses Objekt geleakt.deinit { print("released \(Self.self)") } // silence on dismiss = leak
Escaping Closures, die self erfassen, wechselseitige Strong References zwischen Parent und Child, Timer/DispatchSourceTimer, die ihr Target festhalten, sowie Combine-Subscriptions, die nicht in einem Cancellable gespeichert sind, das dealloziert wird.
ARC ist deterministisch, also liegen Leaks in deiner Verantwortung, nicht in der eines GC — ein einziger festgehaltener View Controller kann Megabytes an Bildern und seinen gesamten Objektgraphen binden. Senior-Interviews prüfen das, weil die korrekte Wahl zwischen weak und unowned und das Wissen, wie man ein Leak mit dem Memory Graph nachweist, langlebige Apps davor bewahrt, aufzublähen.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden