O ARC (Automatic Reference Counting) gerencia a memória de instâncias de classe rastreando referências fortes em tempo de compilação: o compilador insere chamadas retain/release, e quando a contagem de referências fortes de um objeto chega a zero ele é desalocado imediatamente — de forma determinística, não por um garbage collector em segundo plano.
nil na desalocação. Deve ser var e opcional.unowned(unsafe)).final class Customer {
var card: Card? // strong: o customer é dono do card
}
final class Card {
unowned let owner: Customer // unowned: o card nunca sobrevive ao seu dono
init(owner: Customer) { self.owner = owner }
}
Escolha pela relação de tempo de vida, não por hábito:
| weak | unowned | |
|---|---|---|
| Opcional | sim (torna-se nil) | não |
| Custo de ARC | ligeiramente maior (rastreada) | menor |
| Seguro se o outro objeto sumiu | sim | crash |
| Use quando | a referência pode legitimamente virar nil (delegates, pai que pode desalocar primeiro) | a referência tem garantia de sobreviver a self (filho → pai obrigatório) |
! sinalizam ciclos.deinit — a verificação de sanidade mais rápida: se deinit nunca imprime quando uma tela fecha, aquele objeto vazou.deinit { print("released \(Self.self)") } // silêncio ao dispensar = vazamento
Closures escapantes capturando self, referências fortes bidirecionais pai/filho, Timer/DispatchSourceTimer retendo seu alvo, e assinaturas do Combine não armazenadas em um cancellable que seja desalocado.
O ARC é determinístico, então vazamentos são responsabilidade sua, não de um GC — um único view controller retido pode fixar megabytes de imagens e todo o seu grafo de objetos. Entrevistas sênior investigam isso porque escolher corretamente entre weak e unowned e saber como provar um vazamento com o memory graph é o que impede que apps de longa duração inchem.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar