ARC (Automatic Reference Counting) yana sarrafa memory don class instances ta hanyar bin diddigin strong references a lokacin compile: compiler yana saka retain/release calls, kuma lokacin da strong count na object ya kai sifili sai a deallocate shi nan take — a tabbatacce, ba ta background garbage collector ba.
nil kai tsaye a lokacin deallocation. Dole ne ya zama var kuma 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 }
}
Zaɓa bisa lifetime relationship, ba bisa al'ada ba:
| weak | unowned | |
|---|---|---|
| Optional | eh (yana zama nil) | a'a |
| ARC cost | ɗan fi girma (ana bin diddigi) | ƙasa |
| Aminci idan ɗayan object ya tafi | eh | crash |
| Yi amfani lokacin | reference na iya zama nil bisa doka (delegates, parent da zai iya deallocate da farko) | an tabbatar reference zai rayu fiye da self (child → parent na wajibi) |
! suna nuna cycles.deinit logging — dubawa mafi sauri: idan deinit bai taɓa buga ba lokacin da allo ya rufe, wannan object ya leak.deinit { print("released \(Self.self)") } // silence on dismiss = leak
Escaping closures da ke capture self, two-way parent/child strong references, Timer/DispatchSourceTimer da ke riƙe target ɗinsu, da Combine subscriptions da ba a ajiye a cikin cancellable da ke deallocate ba.
ARC tabbatacce ne, don haka leaks alhakinka ne, ba na GC ba — view controller guda da aka riƙe na iya kama megabytes na images da dukkan object graph ɗinsa. Manyan hirar aiki suna bincika wannan saboda zaɓar weak da unowned daidai da sanin yadda za a tabbatar da leak da memory graph shi ne abin da ke hana dogayen apps kumburewa.
Ɗakin karatu na tambayoyin hira na IT tare da amsoshi cikakke — daga Junior zuwa Senior.
Ba da Gudummawa