ახსენი ARC სიღრმისეულად: weak vs unowned და როგორ აღმოვაჩინოთ leak-ები.

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** მართავს class ინსტანციების მეხსიერებას strong მიმართვების კომპილაციის დროს თვალყურის დევნებით: კომპილატორი ჩასვამს `retain`/`release` გამოძახებებს და როცა ობიექტის strong რაოდენობა ნულს აღწევს, ის მაშინვე თავისუფლდება — დეტერმინისტულად, არა ფონური garbage collector-ის მიერ.

## როგორ ცვლიან მიმართვები რაოდენობას

- **strong** (ნაგულისხმევი) — ზრდის რაოდენობას; ინარჩუნებს ობიექტს ცოცხალს.
- **weak** — *არ* ზრდის; ავტომატურად ხდება `nil` deallocation-ისას. უნდა იყოს `var` და optional.
- **unowned** — *არ* ზრდის; ითვლება ყოველთვის ვალიდურად. deallocation-ის შემდეგ წვდომა არის ავარია (ან უარესი, განუსაზღვრელი ქცევა `unowned(unsafe)`-თან).

```swift
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 }
}
```

## weak vs unowned — გადაწყვეტილება

აირჩიე **სიცოცხლის ურთიერთობის** მიხედვით, არა ჩვევით:

| | weak | unowned |
|--|------|---------|
| Optional | კი (ხდება nil) | არა |
| ARC ღირებულება | ოდნავ მაღალი (თვალყურდევნებული) | დაბალი |
| უსაფრთხო, თუ სხვა ობიექტი გამქრალია | კი | **ავარია** |
| გამოიყენე, როცა | მიმართვას *შეუძლია* კანონიერად გახდეს nil (delegate-ები, მშობელი, რომელიც შეიძლება ჯერ გათავისუფლდეს) | მიმართვა გარანტირებულად გადააჭარბებს self-ს (შვილი → სავალდებულო მშობელი) |

## leak-ების აღმოჩენა

1. **Xcode Memory Graph Debugger** — დაპაუზდი და მოძებნე ობიექტები, რომლებიც უნდა გამქრალიყო; იისფერი `!` მარკერები ციკლებს აღნიშნავს.
2. **Instruments → Leaks / Allocations** — ადევნე თვალი მონოტონურად მზარდ მეხსიერებას, როცა ნაკადს იმეორებ.
3. **`deinit` logging** — ყველაზე სწრაფი შემოწმება: თუ `deinit` არასდროს ბეჭდავს ეკრანის დახურვისას, ის ობიექტი გაიჟონა.

```swift
deinit { print("released \(Self.self)") }  // silence on dismiss = leak
```

## leak-ის გავრცელებული წყაროები

escaping closure-ები, რომლებიც `self`-ს იჭერენ, ორმხრივი მშობელი/შვილი strong მიმართვები, `Timer`/`DispatchSourceTimer`, რომლებიც ინახავენ თავიანთ target-ს, და Combine subscription-ები, რომლებიც არ ინახება cancellable-ში, რომელიც თავისუფლდება.

## რატომ არის ეს მნიშვნელოვანი

ARC დეტერმინისტულია, ამიტომ leak-ები შენი პასუხისმგებლობაა, არა GC-ის — ერთმა შენარჩუნებულმა view controller-მა შეიძლება მეგაბაიტობით სურათი და მისი მთელი ობიექტების გრაფი დააჭიროს. senior ინტერვიუები ამას ისწავლიან, რადგან weak vs unowned სწორად არჩევა და leak-ის memory graph-ით *დამტკიცების* ცოდნა არის სწორედ ის, რაც ხანგრძლივად მომუშავე აპლიკაციებს გაბერვისგან იცავს.

	weak	unowned
Optional	კი (ხდება nil)	არა
ARC ღირებულება	ოდნავ მაღალი (თვალყურდევნებული)	დაბალი
უსაფრთხო, თუ სხვა ობიექტი გამქრალია	კი	ავარია
გამოიყენე, როცა	მიმართვას შეუძლია კანონიერად გახდეს nil (delegate-ები, მშობელი, რომელიც შეიძლება ჯერ გათავისუფლდეს)	მიმართვა გარანტირებულად გადააჭარბებს self-ს (შვილი → სავალდებულო მშობელი)

როგორ ცვლიან მიმართვები რაოდენობას

weak vs unowned — გადაწყვეტილება

leak-ების აღმოჩენა

leak-ის გავრცელებული წყაროები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები