मेमोरी लीक और ब्लोट — यह क्या है, कारण और कैसे बचें

मेमोरी लीक और ऐप ब्लोट क्या है?

मेमोरी लीक — एक स्थिति जहाँ एक ऑब्जेक्ट जो अब ऐप के लिए आवश्यक नहीं है, हीप में बना रहता है क्योंकि GC रूट सेट से एक सक्रिय संदर्भ अभी भी उसकी ओर इशारा करता है। गार्बेज कलेक्टर ऐसे ऑब्जेक्ट को जीवित मानता है और उसे हटाता नहीं है।

मेमोरी ब्लोट — एक व्यापक समस्या जहाँ ऐप अपने वर्तमान कार्यों को करने के लिए आवश्यकता से अधिक मेमोरी का उपभोग करता है। कारण: अत्यधिक कैशिंग, ऑब्जेक्ट डुप्लिकेशन, उप-इष्टतम डेटा संरचनाएँ, और हीप विखंडन।

Android में, प्रत्येक ऐप के लिए एक सीमित हीप आवंटित किया जाता है (आमतौर पर डिवाइस और OS संस्करण के आधार पर 64–512 MB)। iOS में, सीमा कम सख्त है, लेकिन सीमा के पास पहुँचने पर सिस्टम एक मेमोरी चेतावनी भेजता है।

Facebook Engineering Blog के अनुसार, मेमोरी लीक मोबाइल ऐप्स में लगभग ~15% क्रैश रिपोर्ट का कारण बनती हैं। Android में, मेमोरी कम होने पर बार-बार GC रुकने के कारण ANR भी जुड़ जाते हैं।

Android और iOS में सामान्य मेमोरी लीक पैटर्न

Activity का स्थिर संदर्भ — एक क्लासिक Android लीक। यदि कोई स्थिर फ़ील्ड या सिंगलटन Activity का संदर्भ रखता है, तो finish() के बाद भी GC द्वारा इसे एकत्र नहीं किया जाएगा जब तक सिंगलटन जीवित है। Activity एक भारी ऑब्जेक्ट है जिसमें व्यू पदानुक्रम, संसाधन और Context शामिल हैं।

object LeakHolder {
    var activityRef: Activity ?= null // leak: static reference to Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity will never be GC'd
    }
}

अनाम वर्ग और लैम्ब्डा — बाहरी वर्ग का एक संदर्भ अंतर्निहित रूप से रखते हैं। यदि Runnable या Callback किसी बाहरी सेवा में भेजा जाता है और Activity नष्ट हो जाती है, तो अनाम वर्ग का ऑब्जेक्ट अभी भी कतार में रहता है और Activity को गार्बेज कलेक्ट होने से रोकता है।

• Handler विलंब के साथ — यदि Activity नष्ट हो जाती है लेकिन Handler.postDelayed अभी तक निष्पादित नहीं हुआ है, तो Activity लीक हो जाती है
• Thread और AsyncTask — स्क्रीन घुमाने पर, Activity फिर से बनाई जाती है जबकि पुराना Thread पुरानी Activity का संदर्भ रखता रहता है
• Retrofit/Callback — एक अनाम Callback प्रेजेंटर या फ़्रैगमेंट का संदर्भ रखता है
• पर्यवेक्षक — onDestroy पर बिना अनसब्सक्राइब किए LiveData या RxJava सब्सक्रिप्शन

iOS में, मुख्य समस्या रिटेन चक्र है: दो ऑब्जेक्ट एक-दूसरे के मजबूत संदर्भ रखते हैं, और ARC किसी के लिए भी संदर्भ गणना को शून्य नहीं कर सकता। एक विशिष्ट मामला: एक क्लोज़र जो self को मजबूती से कैप्चर करता है, और self जो क्लोज़र का संदर्भ रखता है।

मेमोरी लीक का पता कैसे लगाएं?

LeakCanary — Android में स्वचालित लीक पहचान के लिए Square की एक लाइब्रेरी। Activity या Fragment नष्ट होने के बाद, यह जाँचता है कि ऑब्जेक्ट GC द्वारा एकत्र किया गया था या नहीं। यदि नहीं, तो यह हीप डंप लेता है और लीक ट्रेस दिखाता है।

// LeakCanary 2.x — auto-integration via Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary auto-installs in debug build
        // via ContentProvider — zero code setup
    }
}

// Force check invocation
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — रीयल-टाइम मेमोरी मॉनिटरिंग के लिए एक अंतर्निहित उपकरण। यह हीप डंप रिकॉर्ड करने, संदिग्ध ऑब्जेक्ट (Retained Size > 1 MB) खोजने और प्रत्येक ऑब्जेक्ट तक GC रूट पथ का पता लगाने की अनुमति देता है।

iOS के लिए, Xcode Memory Graph Debugger का उपयोग करें। यह मेमोरी में ऑब्जेक्ट ग्राफ़ को विज़ुअलाइज़ करता है, रिटेन चक्र दिखाता है और तुरंत गोलाकार संदर्भों का पता लगाने की अनुमति देता है। दीर्घकालिक निगरानी के लिए Instruments > Allocations भी उपलब्ध है।

रोकथाम की रणनीतियाँ

WeakReference — उन संदर्भों के लिए एक बुनियादी तंत्र जो गार्बेज कलेक्शन में हस्तक्षेप नहीं करना चाहिए। यदि GC किसी ऑब्जेक्ट को एकत्र करने का निर्णय लेता है, तो WeakReference null लौटाता है। इसका उपयोग कॉलबैक, श्रोताओं और पृष्ठभूमि थ्रेड से UI घटकों के संदर्भों के लिए किया जाता है।

Lifecycle-aware घटक — Android Jetpack (Lifecycle, LiveData, Flow, coroutines) में लागू एक आर्किटेक्चरल दृष्टिकोण। सब्सक्रिप्शन onDestroy पर स्वचालित रूप से रद्द हो जाते हैं, जो लीक के मुख्य वर्ग को समाप्त करता है।

class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<List<User>>()
    val data: LiveData<List<User>> get() = _data

    fun loadData() {
        viewModelScope.launch {
            val result = repository.fetchData()
            _data.postValue(result)
            // coroutine auto-cancels on onCleared()
        }
    }
}

viewModelScope और lifecycleScope — Android में अंतर्निहित CoroutineScope जो संबंधित जीवनचक्र घटना पर रद्द हो जाते हैं। यह कोरूटीन के माध्यम से लीक को समाप्त करता है — आधुनिक Android विकास में सबसे आम परिदृश्य।

• उपयोग न करें Context, Activity, View या Fragment के स्थिर संदर्भ
• रद्द करें onDestroy पर disposeBag / CompositeDisposable में सभी RxJava सब्सक्रिप्शन
• उपयोग करें iOS क्लोज़र में [weak self] / [unowned self] रिटेन चक्र को रोकने के लिए
• जाँचें Bitmap और बड़े ऑब्जेक्ट — उन्हें रिसाइकिल या शून्य किया जाना चाहिए

मेमोरी प्रोफाइलिंग उपकरण

Android Studio में Memory Profiler — हीप मॉनिटरिंग के लिए प्राथमिक उपकरण। यह लाइव आवंटन, हीप स्नैपशॉट और प्रकार के अनुसार ऑब्जेक्ट गणना दिखाता है। यह एक डंप रिकॉर्ड करने और संदिग्ध ऑब्जेक्ट खोजने के लिए MAT (Memory Analyzer Tool) में विश्लेषण करने की अनुमति देता है।

Eclipse MAT — एक डेस्कटॉप हीप डंप विश्लेषक। Android Studio से HPROF फ़ाइल लोड करने के बाद, MAT एक डोमिनेटर ट्री बनाता है, प्रत्येक ऑब्जेक्ट का रिटेन आकार दिखाता है, और Leak Suspects Report के माध्यम से स्वचालित लीक संदिग्ध विश्लेषण प्रदान करता है।

Xcode Memory Graph — एक विज़ुअल रिटेन चक्र डिबगर। Memory Graph Debugger बटन पर क्लिक करने पर, Xcode ऐप को रोकता है, मेमोरी में एक पूरा ऑब्जेक्ट ग्राफ़ बनाता है, और रिटेन चक्र को लाल रंग में हाइलाइट करता है।

Google I/O 2023 के अनुसार, डीबग बिल्ड में LeakCanary का उपयोग करने वाले ऐप्स मेमोरी-संबंधित क्रैश को अपनाने के पहले 2 महीनों में 30–50% कम करते हैं। प्रोजेक्ट ऑनबोर्डिंग चरण के दौरान LeakCanary जोड़ने की सिफारिश की जाती है।