ARC کی گہرائی سے وضاحت کریں: weak بمقابلہ unowned، اور leaks کیسے detect کریں۔

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** class instances کے لیے memory کا انتظام strong references کو compile time پر track کر کے کرتا ہے: compiler `retain`/`release` calls داخل کرتا ہے، اور جب کسی object کا strong count صفر تک پہنچ جائے تو اسے فوراً deallocate کر دیا جاتا ہے — یقینی طور پر، کسی background garbage collector سے نہیں۔

## References count کو کیسے متاثر کرتے ہیں

- **strong** (default) — count بڑھاتا ہے؛ object کو زندہ رکھتا ہے۔
- **weak** — count *نہیں* بڑھاتا؛ deallocation پر خودبخود `nil` ہو جاتا ہے۔ لازماً `var` اور optional ہونا چاہیے۔
- **unowned** — count *نہیں* بڑھاتا؛ ہمیشہ valid فرض کیا جاتا ہے۔ deallocation کے بعد access ایک crash ہے (یا `unowned(unsafe)` کے ساتھ اس سے بھی بدتر، undefined behavior)۔

```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 بمقابلہ unowned — فیصلہ

عادت سے نہیں، بلکہ **lifetime relationship** سے انتخاب کریں:

| | weak | unowned |
|--|------|---------|
| Optional | ہاں (nil بن جاتا ہے) | نہیں |
| ARC لاگت | قدرے زیادہ (tracked) | کم |
| اگر دوسرا object جا چکا ہو تو محفوظ | ہاں | **crash** |
| کب استعمال کریں | جب reference جائز طور پر nil بن *سکتا* ہو (delegates، ایسا parent جو پہلے deallocate ہو سکتا ہے) | جب reference کا self سے زیادہ زندہ رہنا یقینی ہو (child → لازمی parent) |

## Leaks کا پتا لگانا

1. **Xcode Memory Graph Debugger** — pause کریں اور ایسے objects تلاش کریں جو جا چکے ہونے چاہییں تھے؛ جامنی `!` markers cycles کی نشاندہی کرتے ہیں۔
2. **Instruments → Leaks / Allocations** — کسی flow کو دہراتے ہوئے مسلسل بڑھتی memory کو دیکھیں۔
3. **`deinit` logging** — سب سے تیز جانچ: اگر screen بند ہونے پر `deinit` کبھی print نہ ہو تو وہ object leak ہو گیا۔

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

## Leaks کے عام ذرائع

`self` کو capture کرنے والے escaping closures، دو طرفہ parent/child strong references، اپنے target کو retain کرتے `Timer`/`DispatchSourceTimer`، اور ایسی Combine subscriptions جو کسی deallocate ہونے والے cancellable میں store نہ ہوں۔

## یہ کیوں اہم ہے

ARC یقینی ہے، اس لیے leaks آپ کی ذمہ داری ہیں، کسی GC کی نہیں — ایک ہی retained view controller میگابائٹس تصاویر اور اپنا سارا object graph جکڑ سکتا ہے۔ Senior interviews یہ اس لیے کھنگالتے ہیں کیونکہ weak بمقابلہ unowned کا درست انتخاب اور memory graph سے leak کو *ثابت* کرنا جاننا ہی وہ چیز ہے جو دیر تک چلنے والی apps کو پھولنے سے بچاتی ہے۔

	weak	unowned
Optional	ہاں (nil بن جاتا ہے)	نہیں
ARC لاگت	قدرے زیادہ (tracked)	کم
اگر دوسرا object جا چکا ہو تو محفوظ	ہاں	crash
کب استعمال کریں	جب reference جائز طور پر nil بن سکتا ہو (delegates، ایسا parent جو پہلے deallocate ہو سکتا ہے)	جب reference کا self سے زیادہ زندہ رہنا یقینی ہو (child → لازمی parent)

References count کو کیسے متاثر کرتے ہیں

weak بمقابلہ unowned — فیصلہ

Leaks کا پتا لگانا

Leaks کے عام ذرائع

یہ کیوں اہم ہے

متعلقہ سوالات