ARC (Automatic Reference Counting) ngelola memori kanggo instance class kanthi nglacak strong reference nalika compile time: compiler nyelehake panggilan retain/release, lan nalika strong count sawijining objek tekan nol, objek kasebut langsung didealokasi — kanthi deterministik, dudu dening garbage collector ing background.
nil nalika dealokasi. Kudu var lan 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 }
}
Milih adhedhasar gegayutan umur (lifetime), dudu adhedhasar kabiasan:
| weak | unowned | |
|---|---|---|
| Optional | ya (dadi nil) | ora |
| Biaya ARC | rada luwih dhuwur (dilacak) | luwih murah |
| Aman yen objek liya ilang | ya | crash |
| Gunakake nalika | referensi bisa dadi nil kanthi sah (delegate, parent sing bisa didealokasi luwih dhisik) | referensi dijamin urip luwih suwe tinimbang self (child → parent wajib) |
! ungu nuduhake cycle.deinit — cek paling cepet: yen deinit ora tau nyithak nalika layar ditutup, objek kasebut leak.deinit { print("released \(Self.self)") } // silence on dismiss = leak
Escaping closure sing nangkep self, strong reference rong arah antarane parent/child, Timer/DispatchSourceTimer sing nahan target-e, lan langganan Combine sing ora disimpen ing cancellable sing didealokasi.
ARC iku deterministik, mula leak iku tanggung jawabmu, dudu tanggung jawab GC — siji view controller sing kecekel bisa nahan megabyte gambar lan kabeh object graph-e. Wawancara senior nyelidhiki iki amarga milih weak vs unowned kanthi bener lan ngerti carane mbuktekake leak nganggo memory graph iku sing njaga app sing mlaku suwe ora mbludhak.
Pustaka pitakon wawancara IT kanthi jawaban rinci — saka Junior nganti Senior.
Nyumbang