ARC (Automatic Reference Counting) menaxhon memorien për instancat e klasave duke gjurmuar referencat e forta gjatë kompajlimit: kompajleri fut thirrje retain/release, dhe kur count-i i fortë i një objekti arrin zero ai dealokohet menjëherë — në mënyrë determinuese, jo nga një garbage collector në sfond.
nil gjatë dealokimit. Duhet të jetë var dhe 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 }
}
Zgjidhni sipas marrëdhënies së jetëgjatësisë, jo sipas zakonit:
| weak | unowned | |
|---|---|---|
| Optional | po (bëhet nil) | jo |
| Kostoja ARC | pak më e lartë (gjurmohet) | më e ulët |
| I sigurt nëse objekti tjetër ka ikur | po | crash |
| Përdoreni kur | referenca mund legjitimisht të bëhet nil (delegate, prind që mund të dealokohet i pari) | referenca garantohet t'i mbijetojë self-it (fëmijë → prind i detyrueshëm) |
! sinjalizojnë cikle.deinit — kontrolli më i shpejtë i shëndetit: nëse deinit nuk printon kurrë kur një ekran mbyllet, ai objekt bëri leak.deinit { print("released \(Self.self)") } // silence on dismiss = leak
Closure-t escaping që kapin self, referenca të forta prind/fëmijë në të dyja drejtimet, Timer/DispatchSourceTimer që mbajnë target-in e tyre, dhe abonime Combine që nuk ruhen në një cancellable që dealokohet.
ARC është determinues, kështu që leak-et janë përgjegjësia juaj, jo e një GC-je — një view controller i vetëm i mbajtur mund të mbërthejë megabajt imazhesh dhe të gjithë grafin e vet të objekteve. Intervistat senior e hetojnë këtë sepse zgjedhja e saktë weak kundrejt unowned dhe të diturit se si të provosh një leak me memory graph-in është ajo që i mban app-et afatgjata pa u fryrë.
Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro