ARC (Automatic Reference Counting) gère la mémoire des instances de classe en suivant les références fortes à la compilation : le compilateur insère des appels retain/release, et lorsque le compteur de références fortes d'un objet atteint zéro, il est désalloué immédiatement — de manière déterministe, pas par un garbage collector en arrière-plan.
nil lors de la désallocation. Doit être var et optional.unowned(unsafe)).final class Customer {
var card: Card? // strong : le customer possède la card
}
final class Card {
unowned let owner: Customer // unowned : la card ne survit jamais à son owner
init(owner: Customer) { self.owner = owner }
}
Choisissez selon la relation de durée de vie, pas par habitude :
| weak | unowned | |
|---|---|---|
| Optional | oui (devient nil) | non |
| Coût ARC | légèrement plus élevé (suivi) | plus faible |
| Sûr si l'autre objet a disparu | oui | plantage |
| À utiliser quand | la référence peut légitimement devenir nil (delegates, parent pouvant être désalloué en premier) | la référence est garantie de survivre à self (enfant → parent obligatoire) |
! signalent les cycles.deinit — le contrôle le plus rapide : si deinit ne s'affiche jamais à la fermeture d'un écran, cet objet a fui.deinit { print("released \(Self.self)") } // silence au dismiss = fuite
Les closures escaping capturant self, les références fortes bidirectionnelles parent/enfant, Timer/DispatchSourceTimer retenant leur cible, et les abonnements Combine non stockés dans un cancellable qui se désalloue.
ARC est déterministe, donc les fuites sont votre responsabilité, pas celle d'un GC — un seul view controller retenu peut immobiliser des mégaoctets d'images et tout son graphe d'objets. Les entretiens senior sondent cela car choisir correctement entre weak et unowned et savoir prouver une fuite avec le memory graph est ce qui empêche les apps de longue durée de gonfler.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don