Unowned Reference: यह क्या है, सिंटैक्स और मोबाइल एप्लिकेशन में उपयोग

Unowned Reference क्या है?

Unowned Reference ARC में एक ऑब्जेक्ट का गैर-मालिकाना संदर्भ है जो उसके retain count को नहीं बढ़ाता है। weak के विपरीत, unowned संदर्भ ऑब्जेक्ट के डीलोकेशन के बाद शून्यीकृत नहीं होता: यह उस मेमोरी की ओर इशारा करता रहता है जो पहले ही मुक्त हो चुकी है। ऐसे संदर्भ तक पहुँच EXC_BAD_ACCESS के साथ रनटाइम क्रैश का कारण बनती है।

“अस्वामित्व” शब्द शब्दार्थ को दर्शाता है: ऑब्जेक्ट मौजूद है, लेकिन कोई भी उसके जीवनकाल के लिए जिम्मेदार नहीं है। डेवलपर स्पष्ट रूप से घोषित करता है: “मैं गारंटी देता हूँ कि यह ऑब्जेक्ट तब तक जीवित रहेगा जब तक मैं इसे संदर्भित करता हूँ।” कंपाइलर इस गारंटी की पुष्टि नहीं करता — यह डेवलपर स्तर पर एक अनुबंध है।

Swift.org Documentation, 2026 के अनुसार, गारंटीकृत जीवनकाल वाले परिदृश्यों में unowned संदर्भ weak से बेहतर होते हैं क्योंकि वे: वैकल्पिक प्रकार की आवश्यकता नहीं होती (साफ़ कोड), unwrap की आवश्यकता नहीं होती (कम force-unwrap या guard let), और शून्यीकरण weak तालिका के रखरखाव का कोई ओवरहेड नहीं होता। हालाँकि, अनुबंध का कोई भी उल्लंघन क्रैश में परिणत होता है।

Swift में unowned सिंटैक्स

Swift में, unowned संदर्भ let या var से पहले कीवर्ड unowned के साथ घोषित किए जाते हैं। weak के विपरीत, unowned दोनों let और var हो सकता है, और वैकल्पिक प्रकार की आवश्यकता नहीं होती। यह गुण unowned को उन संदर्भों के लिए सुविधाजनक बनाता है जो डोमेन तर्क द्वारा nil नहीं हो सकते।

class Country {
    let name: String
    var capital: City!           // आरंभीकरण के बाद सेट किया जाएगा
    init(name: String) { self.name = name }
}

class City {
    let name: String
    unowned let country: Country   // ✅ unowned let — जीवनकाल गारंटी

    init(name: String, country: Country) {
        self.name = name
        self.country = country
    }
}

// उपयोग
let france = Country(name: "France")
let paris = City(name: "Paris", country: france)
france.capital = paris
// ✅ Country → City (strong), City → Country (unowned) — कोई retain cycle नहीं

इस उदाहरण में, City unowned let country — एक शहर बिना देश के अस्तित्व में नहीं रह सकता। यदि देश गायब हो जाता है, तो शहर (और संदर्भ) अपना अर्थ खो देते हैं। शब्दार्थ की दृष्टि से, यह unowned के लिए एक आदर्श मामला है: जीवनकाल गारंटी मौजूद है, वैकल्पिक की आवश्यकता नहीं, retain cycle उत्पन्न नहीं होता।

unowned var

unowned var अनुमत है लेकिन कम आम है। इसका उपयोग तब किया जाता है जब संदर्भ को बदला जा सकता है (उदाहरण के लिए, किसी बच्चे को दूसरे माता-पिता से पुनः जोड़ना)। पुनः असाइनमेंट पर, पुराने ऑब्जेक्ट का डीलोकेशन बाहरी मालिक की जिम्मेदारी है।

Unowned Optional

Swift 5.0+ में, unowned वैकल्पिक (unowned let x: Type?) के लिए समर्थन पेश किया गया। यह एक समझौता है: unowned गारंटी देता है कि यदि संदर्भ nil नहीं है, तो ऑब्जेक्ट जीवित है। डीलोकेशन पर व्यवहार क्रैश है, जैसा कि सामान्य unowned के साथ होता है।

Unowned vs Weak: कब क्या उपयोग करें

unowned और weak के बीच चुनाव Swift आर्किटेक्चर डिज़ाइन करते समय लगातार लिए जाने वाले निर्णयों में से एक है। आइए प्रत्येक मामले के मानदंड और अनुशंसाएँ देखें।

व्यावहारिक नियम

weak का उपयोग करें यदि ऑब्जेक्ट के जीवनकाल के बारे में थोड़ा भी संदेह हो। Weak सुरक्षित, स्पष्ट है और इसमें प्रमाण की आवश्यकता नहीं है। unowned का उपयोग करें केवल तब जब आप उन सभी परिदृश्यों को खारिज कर सकें जिनमें ऑब्जेक्ट पहले मुक्त हो सकता है। विशिष्ट मामले: बच्चा जो माता-पिता के बिना मौजूद नहीं है; क्लोज़र जो समकालिक रूप से निष्पादित होता है; अपने आरंभकर्ता के भीतर ऑब्जेक्ट तक पहुँच।

Airbnb Swift Style Guide, 2025 के अनुसार, बड़े कोडबेस में डिफ़ॉल्ट रूप से weak का उपयोग करने की अनुशंसा की जाती है और unowned केवल स्पष्ट टिप्पणी के साथ जो जीवनकाल गारंटी की व्याख्या करती हो। यह रिफैक्टरिंग के दौरान गैर-स्पष्ट क्रैश के जोखिम को कम करता है।

क्लोज़र्स में Unowned self

क्लोज़र्स पैरेंट-चाइल्ड संबंधों के बाद unowned का दूसरा सबसे लगातार उपयोग मामला है। कैप्चर लिस्ट [unowned self] का उपयोग तब किया जाता है जब गारंटी हो कि self क्लोज़र से अधिक समय तक जीवित रहता है। आइए सही और गलत परिदृश्य देखें।

कब unowned self सुरक्षित है

समकालिक क्लोज़र्स — sorted, filter, map। वे वर्तमान थ्रेड पर तुरंत निष्पादित होते हैं, self निश्चित रूप से जीवित है। unowned के साथ कैप्चर लिस्ट यहाँ स्वीकार्य है और साफ़ कोड देती है।

class DataProcessor {
    var items: [Int] = [3, 1, 4, 1, 5]

    func processSorted() {
        // ✅ unowned self — sorted समकालिक रूप से निष्पादित होता है, self गारंटीपूर्वक जीवित है
        let sorted = items.sorted { [unowned self] a, b in
            return self.customCompare(a, b)
        }
    }

    func customCompare(_ a: Int, _ b: Int) -> Bool { return a < b }
}

कब unowned self खतरनाक है

अतुल्यकालिक क्लोज़र्स — विलंब, नेटवर्क अनुरोध, एनिमेशन के साथ। क्लोज़र को शेड्यूल करने और उसके निष्पादन के बीच self मुक्त हो सकता है। यहाँ unowned self क्रैश की ओर ले जाता है। [weak self] का उपयोग करें।

class NetworkLoader {
    func loadData() {
        // ❌ खतरनाक: अतुल्यकालिक क्लोज़र में unowned self
        URLSession.shared.dataTask(with: url) { [unowned self] data, _, _ in
            self.handleResponse(data)  // क्रैश यदि self मुक्त हो जाता है
        }.resume()
    }

    func handleResponse(_ data: Data?) { }

    // ✅ सही: weak self + guard
    func loadDataSafe() {
        URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in
            guard let self else { return }
            self.handleResponse(data)
        }.resume()
    }
}

नियम याद रखें: unowned self — केवल समकालिक क्लोज़र्स के लिए जो तुरंत निष्पादित होते हैं। अतुल्यकालिक क्लोज़र्स के लिए, हमेशा weak self + guard let का उपयोग करें। अपवाद: यदि आप क्लोज़र के पूरा होने तक ऑब्जेक्ट का स्पष्ट रूप से संदर्भ रखते हैं (उदाहरण के लिए, किसी अन्य चर में एक मजबूत संदर्भ रखकर)।

Unowned के जोखिम और उनसे कैसे बचें

Unowned एक शक्तिशाली लेकिन खतरनाक उपकरण है। आइए वास्तविक दुनिया के परिदृश्य देखें जहाँ unowned क्रैश का कारण बन सकता है और जोखिम को कम करने के तरीके।

रिफैक्टरिंग और गारंटी बदलना

unowned का मुख्य जोखिम व्यावसायिक तर्क में बदलाव है जो जीवनकाल गारंटी को अमान्य करता है। डेवलपर कोड रिफैक्टर करता है: स्वामित्व बदलता है, विलंबित मुक्ति शुरू करता है, कैशिंग जोड़ता है — और unowned संदर्भ एक टाइम बम बन जाता है। कंपाइलर चेतावनी नहीं देगा — केवल उपयोगकर्ता के डिवाइस पर क्रैश।

अनुशंसा: unowned का उपयोग केवल तब करें जब जीवनकाल गारंटी स्पष्ट और दस्तावेज़ीकृत हो। प्रत्येक unowned के लिए टिप्पणी जोड़ें: यह संदर्भ सुरक्षित क्यों है और किन परिस्थितियों में इसका उल्लंघन हो सकता है।

UIKit पदानुक्रम में Unowned

UIKit unowned के लिए उच्च जोखिम वाला क्षेत्र है। नेविगेशन (pop, dismiss), मेमोरी अनलोडिंग, या ओरिएंटेशन परिवर्तनों के दौरान किसी भी समय ViewController मुक्त हो सकता है। यदि आप ViewController को unowned self के साथ क्लोज़र में पास करते हैं, तो पृष्ठभूमि से लौटने या एनिमेशन पूरा होने पर self nil हो सकता है।

सर्वोत्तम अभ्यास

unowned का उपयोग करते समय जोखिम कम करने के लिए, इन नियमों का पालन करें:

• डिफ़ॉल्ट रूप से weak पसंद करें — weak सुरक्षित है, unowned एक अनुकूलन है, मानक नहीं
• गारंटी दस्तावेज़ीकृत करें — प्रत्येक unowned के लिए, औचित्य के साथ टिप्पणी लिखें
• ViewController में unowned से बचें — UIKit जीवनचक्र unowned गारंटियों के लिए अप्रत्याशित है
• unowned का उपयोग केवल समकालिक क्लोज़र्स के लिए करें — sorted, filter, map सुरक्षित उम्मीदवार हैं
• कोड समीक्षा के दौरान जाँच करें — प्रत्येक unowned को कोड लेखक से औचित्य की आवश्यकता होती है
• थोड़े से संदेह पर weak पर जाएँ — पठनीयता में हानि (एक guard let) प्रोडक्शन में क्रैश से कम है

// उदाहरण: स्पष्ट औचित्य के साथ दस्तावेज़ीकृत unowned संदर्भ
class InvoiceLineItem {
    let productName: String
    let price: Decimal

    // unowned Invoice — InvoiceLineItem Invoice के बिना मौजूद नहीं हो सकता।
    // Invoice Item बनाता है और उसे हटाए जाने पर हटा देता है।
    // गारंटी: Invoice कम से कम उतने समय तक जीवित रहता है जितना Item।
    unowned let invoice: Invoice

    init(productName: String, price: Decimal, invoice: Invoice) {
        self.productName = productName
        self.price = price
        self.invoice = invoice
    }
}

// यह एक मजबूत गारंटी है: Invoice deinit में सभी Items हटा देता है।
// गारंटी का उल्लंघन = व्यावसायिक तर्क में बग जिसे ठीक करने की आवश्यकता है।

गारंटियों का दस्तावेज़ीकरण एक पेशेवर मानक है। बड़ी परियोजनाओं (Airbnb, Uber) में, कोड समीक्षा में प्रत्येक unowned के लिए औचित्य की आवश्यकता होती है। यदि गारंटी स्पष्ट नहीं है, तो weak का उपयोग करें। unowned पर टिप्पणी भविष्य के डेवलपर्स को यह समझने में मदद करती है कि यहाँ weak का उपयोग क्यों नहीं किया गया और कौन सी स्थितियाँ गारंटी को तोड़ सकती हैं।