ARC (Automatic Reference Counting) menguruskan memori untuk instance class dengan menjejaki strong reference pada masa kompilasi: pengkompil menyisip panggilan retain/release, dan apabila kiraan strong sesuatu objek mencecah sifar ia dide-alokasi serta-merta — secara deterministik, bukan oleh garbage collector latar belakang.
nil semasa de-alokasi. Mesti var dan optional.unowned(unsafe)).final class Customer {
var card: Card? // strong: customer memiliki card
}
final class Card {
unowned let owner: Customer // unowned: card tidak pernah hidup lebih lama daripada owner
init(owner: Customer) { self.owner = owner }
}
Pilih mengikut hubungan jangka hayat, bukan mengikut kebiasaan:
| weak | unowned | |
|---|---|---|
| Optional | ya (menjadi nil) | tidak |
| Kos ARC | sedikit lebih tinggi (dijejaki) | lebih rendah |
| Selamat jika objek lain tiada | ya | ranap |
| Guna apabila | rujukan boleh secara sah menjadi nil (delegate, parent yang mungkin dide-alokasi dahulu) | rujukan dijamin hidup lebih lama daripada self (anak → parent wajib) |
! menandai cycle.deinit — semakan kewarasan terpantas: jika deinit tidak pernah dicetak apabila sesuatu skrin ditutup, objek itu bocor.deinit { print("released \(Self.self)") } // senyap semasa dismiss = kebocoran
Escaping closure yang menangkap self, strong reference parent/child dua-hala, Timer/DispatchSourceTimer yang mengekalkan sasarannya, dan langganan Combine yang tidak disimpan dalam cancellable yang dide-alokasi.
ARC bersifat deterministik, jadi kebocoran ialah tanggungjawab anda, bukan GC — satu view controller yang dikekalkan boleh mengunci beberapa megabait imej dan seluruh graf objeknya. Temu duga senior menyiasat ini kerana memilih weak vs unowned dengan betul dan mengetahui cara membuktikan sesuatu kebocoran dengan memory graph ialah yang mengekalkan aplikasi berjalan-lama daripada membengkak.
Pustaka soalan temu duga IT dengan jawapan terperinci — daripada Junior hingga Senior.
Derma