onDestroy: यह क्या है, Android में Activity का कार्य समाप्त करना

onDestroy: Android में यह क्या है?

onDestroy — एक कॉलबैक विधि जिसे Android Activity या Fragment को पूरी तरह नष्ट करने से पहले कॉल करता है। यह डेवलपर के लिए संसाधनों को मुक्त करने, पृष्ठभूमि संचालन रद्द करने और डेटा कार्य समाप्त करने का अंतिम अवसर है। onDestroy निष्पादित होने के बाद, Activity/Fragment इंस्टेंस को कचरा संग्रह (GC) के लिए चिह्नित किया जाता है और इसका उपयोग नहीं किया जा सकता है।

onDestroy कॉल करने के कारण:

• स्पष्ट finish() कॉल — उपयोगकर्ता ने “पीछे” दबाया या डेवलपर ने finishActivity() कॉल किया।
• स्क्रीन रोटेशन — Activity नष्ट हो जाती है और नए कॉन्फ़िगरेशन के साथ पुनः बनाई जाती है।
• कॉन्फ़िगरेशन परिवर्तन — कीबोर्ड, भाषा परिवर्तन, स्क्रीन आकार परिवर्तन (मल्टी-विंडो)।
• सिस्टम निर्णय — Android संसाधन मुक्त करने के लिए Activity को मारता है (लेकिन onDestroy कॉल नहीं हो सकता)।

Google Android Vitals आँकड़ों (2025) के अनुसार, सभी Activity विनाश मामलों में से लगभग 12% स्क्रीन रोटेशन के कारण, 65% finish() के कारण और 23% कॉन्फ़िगरेशन परिवर्तनों के कारण होते हैं। onDestroy छोड़े जाने वाली प्रक्रिया मृत्यु का प्रतिशत कम RAM (4 GB से कम) वाले उपकरणों के आधार पर लगभग 5–8% है।

onDestroy कब कॉल किया जाता है — और कब नहीं कॉल किया जाता

onDestroy अधिकांश मानक परिदृश्यों में कॉल किया जाता है, लेकिन महत्वपूर्ण अपवाद हैं जिन्हें डेवलपर को ध्यान में रखना चाहिए। onDestroy कॉल की गारंटी को समझना एप्लिकेशन आर्किटेक्चर के लिए महत्वपूर्ण है, विशेष रूप से डेटा सहेजने और WorkManager कार्यों को रद्द करने के लिए।

onDestroy कब कॉल किया जाता है:

• उपयोगकर्ता “पीछे” बटन दबाता है — Activity.finish() → onPause → onStop → onDestroy।
• स्क्रीन रोटेशन — Activity नष्ट होती है (onPause → onStop → onDestroy), फिर पुनः बनाई जाती है।
• कॉन्फ़िगरेशन परिवर्तन — सिस्टम सेटिंग जिसमें Activity पुनर्निर्माण आवश्यक है।
• finishAffinity() कॉल करना — स्टैक में सभी Activities समाप्त करना।
• FragmentManager से Fragment हटाना — Fragment प्राप्त करता है: onPause → onStop → onDestroyView → onDestroy → onDetach।

onDestroy कब नहीं कॉल किया जाता:

• सिस्टम द्वारा प्रक्रिया मृत्यु — Android मेमोरी कम होने पर पूरी एप्लिकेशन प्रक्रिया को मार देता है। Activity को onDestroy प्राप्त नहीं होता क्योंकि प्रक्रिया Linux कर्नेल स्तर पर समाप्त होती है।
• असामान्य समाप्ति — मुख्य थ्रेड में अनकैच्ड अपवाद onDestroy कॉल किए बिना एप्लिकेशन को मार देता है।
• फोर्स स्टॉप — उपयोगकर्ता सेटिंग्स में एप्लिकेशन को जबरन रोकता है।

onDestroy कॉल की गारंटी की कमी के कारण, Google अनुशंसा करता है: महत्वपूर्ण डेटा सहेजने के लिए कभी भी onDestroy पर भरोसा न करें। onSaveInstanceState(), WorkManager या स्वचालित सहेजने वाले Room का उपयोग करें। onDestroy संसाधनों को मुक्त करने के लिए है, स्थायित्व (persistence) के लिए नहीं।

Activity और Fragment में onDestroy: समानताएं और अंतर

onDestroy Activity और Fragment दोनों के लिए मौजूद है, लेकिन विभिन्न अनुबंधों के साथ। Fragment का जीवनचक्र अधिक विस्तृत है: onDestroy के अलावा, onDestroyView (View पदानुक्रम का विनाश) और onDetach (Activity से अलग होना) भी हैं।

मुख्य अंतर: Fragment का View स्वयं Fragment की तुलना में अधिक बार पुनः बनाया जाता है। स्क्रीन रोटेशन के दौरान, Fragment onDestroyView (View विनाश) से गुजरता है, लेकिन Fragment स्वयं और इसका ViewModel जीवित रहते हैं। onDestroyView मेमोरी लीक से बचने के लिए View संदर्भों को साफ़ करने का सही स्थान है। Fragment का onDestroy Activity के onDestroy के समान है, जो Fragment के पूरी तरह हटाए जाने पर कॉल किया जाता है।

चाइल्ड फ़्रैगमेंट पैरेंट Fragment के onDestroy से पहले नष्ट हो जाते हैं। Activity में, चाइल्ड फ़्रैगमेंट को onDestroy तब प्राप्त होता है जब पैरेंट Activity का onDestroy कॉल किया जाता है। क्रम गारंटीकृत है: फ़्रैगमेंट उन्हें समाहित करने वाली Activity से पहले समाप्त होते हैं।

onDestroy में क्या करें: सफाई जाँच सूची

onDestroy उन सभी संसाधनों को मुक्त करने के लिए है जो Activity या Fragment से अधिक जीवित नहीं रहने चाहिए. onStop के विपरीत, जो वापसी तक संसाधनों को मुक्त करता है, onDestroy अंतिम सफाई करता है।

onDestroy में अनिवार्य कार्यों की जाँच सूची:

• कोरूटीन और Flow रद्द करें — उन jobs को रद्द करें जो viewModelScope से बंधी नहीं हैं। viewModelScope स्वचालित रूप से रद्द हो जाता है, लेकिन lifecycleScope Activity के जीवनचक्र से बंधा होता है।
• सॉकेट और चैनल बंद करें — WebSocket (OkHttp), BluetoothSocket, ServerSocket। विनाश के बाद उन्हें खुला रखना सिस्टम संसाधन लीक है।
• फ़ाइलें और स्ट्रीम बंद करें — FileInputStream, FileOutputStream, Cursor। Cursor ContentProvider पर ANR का कारण बन सकता है यदि बंद न किया जाए।
• ContentObserver से सदस्यता रद्द करें — यदि Activity सामग्री परिवर्तन (संपर्क, मीडिया लाइब्रेरी) देख रही है।
• BroadcastReceiver अपंजीकृत करें — गतिशील रूप से पंजीकृत रिसीवर रद्द किए जाने चाहिए।
• डेटाबेस बंद करें — Room एप्लिकेशन नष्ट होने पर स्वचालित रूप से कनेक्शन बंद कर देता है, लेकिन प्रत्यक्ष SQLiteDatabase को मैन्युअल close() की आवश्यकता होती है।

onDestroy में क्या न करें: onDestroy में डेटा सहेजें नहीं — onPause या onSaveInstanceState का उपयोग करें। नया Service या WorkManager कार्य शुरू न करें — Activity नष्ट हो जाएगी और आप परिणाम ट्रैक नहीं कर पाएंगे। UI अपडेट करने का प्रयास न करें — View पदानुक्रम पहले ही नष्ट हो चुका है या नष्ट होने की प्रक्रिया में है; findViewById() कॉल करने पर null वापस आएगा।

onDestroy और ViewModel: एक साथ काम करना

ViewModel स्क्रीन रोटेशन के दौरान Activity के onDestroy से बचने के लिए डिज़ाइन किया गया है, लेकिन finish() के दौरान Activity के साथ नष्ट हो जाता है। यह असममित व्यवहार डेवलपर्स के बीच भ्रम का मुख्य कारण है।

स्क्रीन रोटेशन के दौरान:

• Activity: onPause → onStop → onDestroy (Activity नष्ट)।
• ViewModel: नष्ट नहीं हुआ — ViewModelStore सहेजा जाता है और नई Activity को भेजा जाता है।
• नई Activity: onCreate → onStart → onResume, वही ViewModel प्राप्त करती है।

finish() के दौरान (उपयोगकर्ता ने “पीछे” दबाया):

• Activity: onPause → onStop → onDestroy।
• ViewModel: onCleared() — Activity के onDestroy के बाद कॉल किया जाता है।
• सभी viewModelScope कोरूटीन स्वचालित रूप से रद्द हो जाते हैं।

इसलिए, onDestroy में viewModelScope रद्द करना आवश्यक नहीं है — ViewModel स्वयं ऐसा करेगा। यदि आप lifecycleScope (Activity से बंधा, ViewModel से नहीं) उपयोग कर रहे हैं, तो इसे onDestroy में lifecycleScope.cancel() के माध्यम से रद्द करें या Job को मैन्युअल रूप से प्रबंधित करें।

Kotlin में onDestroy के साथ कोड उदाहरण

उदाहरण 1: lifecycleScope कोरूटीन रद्दीकरण के साथ onDestroy Activity

Activity में सही lifecycleScope प्रबंधन प्रदर्शित करता है: नेटवर्क स्थिति की निगरानी के लिए कोरूटीन शुरू की जाती है और onDestroy में रद्द की जाती है।

class NetworkMonitorActivity : AppCompatActivity() {
    private val networkCallback = object : ConnectivityManager.NetworkCallback() {
        override fun onAvailable(network: Network) {
            Log.d("NetworkMonitor", "नेटवर्क उपलब्ध")
        }
        override fun onLost(network: Network) {
            Log.d("NetworkMonitor", "नेटवर्क खो गया")
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_network)
        val connectivityManager = getSystemService(ConnectivityManager::class.java)
        connectivityManager.registerDefaultNetworkCallback(networkCallback)
        lifecycleScope.launch {
            Log.d("NetworkMonitor", "नेटवर्क निगरानी शुरू")
        }
    }

    override fun onDestroy() {
        super.onDestroy()
        val connectivityManager = getSystemService(ConnectivityManager::class.java)
        connectivityManager.unregisterNetworkCallback(networkCallback)
        Log.d("NetworkMonitor", "onDestroy: कॉलबैक रद्द किया गया")
    }
}

onDestroy में, नेटवर्क कॉलबैक पंजीकरण रद्द किया जाता है। lifecycleScope जीवनचक्र नष्ट होने पर स्वचालित रूप से रद्द हो जाता है — अलग से कोरूटीन रद्दीकरण आवश्यक नहीं है। नेटवर्क कॉलबैक को अपंजीकृत किया जाना चाहिए, अन्यथा यह Activity नष्ट होने के बाद भी सिस्टम में बना रहेगा।

उदाहरण 2: View संदर्भ सफाई के साथ onDestroy Fragment

Fragment onDestroyView में View संदर्भों को सही ढंग से साफ़ करता है, क्लोज़र के कारण मेमोरी लीक को रोकता है।

class ProfileFragment : Fragment() {
    private var avatarView: ImageView? = null
    private var progressBar: ProgressBar? = null
    private val imageLoader = ImageLoader()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        avatarView = view.findViewById(R.id.avatar)
        progressBar = view.findViewById(R.id.progress)
        loadProfile()
    }

    private fun loadProfile() {
        viewLifecycleOwner.lifecycleScope.launch {
            try {
                progressBar?.visibility = View.VISIBLE
                val bitmap = imageLoader.load("https://example.com/avatar.png")
                avatarView?.setImageBitmap(bitmap)
            } finally {
                progressBar?.visibility = View.GONE
            }
        }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        avatarView = null
        progressBar = null
        imageLoader.cancel()
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d("ProfileFragment", "onDestroy: Fragment पूरी तरह नष्ट हो गया")
    }
}

onDestroyView में, View संदर्भ null पर सेट किए जाते हैं — यह मेमोरी लीक को रोकता है यदि imageLoader में क्लोज़र avatarView का संदर्भ रखता है। Fragment स्वयं और इसका ViewModel onDestroy तक जीवित रहते हैं। imageLoader.cancel() लोडिंग रद्द करता है यदि Fragment स्क्रीन छोड़ देता है।

उदाहरण 3: onDestroy में isFinishing की जाँच

isFinishing() का उपयोग यह अंतर करने की अनुमति देता है कि Activity उपयोगकर्ता कमांड द्वारा समाप्त हो रही है या पुनर्निर्माण के लिए।

class AnalyticsActivity : AppCompatActivity() {
    private val analytics = Analytics()

    override fun onDestroy() {
        if (isFinishing) {
            Log.d("AnalyticsActivity", "Activity finish() के साथ समाप्त हो रही है — एनालिटिक्स भेज रहा है")
            analytics.sendSessionEnd()
        } else {
            Log.d("AnalyticsActivity", "Activity पुनः बनाई जा रही है (रोटेशन/कॉन्फ़िगरेशन) — एनालिटिक्स नहीं भेज रहा है")
        }
        super.onDestroy()
    }
}

isFinishing() की जाँच एनालिटिक्स, लॉगिंग और सत्र डेटा सफाई के लिए एक महत्वपूर्ण पैटर्न है। रोटेशन के दौरान, सत्र समाप्ति ईवेंट नहीं भेजे जाने चाहिए — उपयोगकर्ता अभी भी एप्लिकेशन के साथ काम कर रहा है। Google Analytics के अनुसार, गलत isFinishing() जाँच 40% झूठी सत्र घटनाओं का कारण है।