onPause: यह क्या है, Android में Activity स्थिति सहेजना

Android में onPause क्या है

onPause Activity जीवनचक्र की चौथी विधि है, जो तब कॉल की जाती है जब स्क्रीन इनपुट फोकस खो देती है लेकिन उपयोगकर्ता को आंशिक रूप से दिखाई देती रहती है. यह ऐप के सक्रिय रूप से चलने और छिपने के बीच की एक «संक्रमणकालीन» स्थिति है। सिस्टम निम्नलिखित परिदृश्यों में onPause कॉल करता है: कोई दूसरा Activity खुलना (नई स्क्रीन वर्तमान को आंशिक रूप से ढकती है), कोई डायलॉग विंडो दिखना (Dialog, PopupWindow, Snackbar onPause नहीं बुलाते, लेकिन DialogFragment बुलाता है), हाल के ऐप्स बटन दबाना, इनकमिंग कॉल, स्क्रीन लॉक करने के लिए पावर बटन दबाना।

onPause का मुख्य उद्देश्य ऐप को छिपाए या नष्ट किए जाने की संभावना के लिए तैयार करना है। यह जीवनचक्र का अंतिम बिंदु है जहाँ डेवलपर सुनिश्चित हो सकता है कि सिस्टम के किसी अन्य घटक में संक्रमण जारी रखने से पहले उसका कोड निष्पादित होगा। onPause के बाद, सिस्टम onStop कॉल करता है (यदि Activity पूरी तरह छिप जाता है), जिसके बाद प्रक्रिया बिना किसी अतिरिक्त सूचना के किसी भी समय समाप्त की जा सकती है।

Android Developers (2025) दस्तावेज़ीकरण के अनुसार, onPause को यथासंभव हल्का और तेज़ होना चाहिए। जब तक onPause नियंत्रण वापस नहीं करता, सिस्टम अगला Activity शुरू नहीं कर सकता — इसका मतलब है कि उपयोगकर्ता स्क्रीन संक्रमण में देरी देखता है। Google 100 मिलीसेकंड से कम में onPause पूरा करने की अनुशंसा करता है, और सभी लंबी संचालन (डेटाबेस में सहेजना, डिस्क पर लिखना) को coroutines या apply() के माध्यम से एसिंक्रोनस रूप से किया जाना चाहिए।

Activity में onPause

Activity में, onPause विधि हर बार कॉल की जाती है जब स्क्रीन सक्रिय रहना बंद कर देती है लेकिन आंशिक रूप से प्रदर्शित होती रह सकती है. एक विशिष्ट उदाहरण: उपयोगकर्ता मैप्स ऐप खोलता है, स्थान साझा करें पर टैप करता है, और मैप्स के ऊपर एक सिस्टम ऐप चयन डायलॉग दिखाई देता है। मैप्स Activity को onPause मिलता है लेकिन डायलॉग के नीचे दृश्यमान रहता है। जब डायलॉग बंद होता है, मैप्स को onResume मिलता है बिना onStart कॉल किए (स्क्रीन पूरी तरह छिपी नहीं थी)।

class NoteEditorActivity : AppCompatActivity() {
    private var binding: ActivityNoteEditorBinding? = null
    private val prefs by lazy {
        getSharedPreferences("note_drafts", Context.MODE_PRIVATE)
    }

    override fun onPause() {
        super.onPause()

        // नोट ड्राफ्ट सहेजें — एसिंक्रोनस रूप से
        prefs.edit()
            .putString("draft_title", binding?.titleInput?.text.toString())
            .putString("draft_body", binding?.bodyInput?.text.toString())
            .putLong("draft_timestamp", System.currentTimeMillis())
            .apply()

        // वीडियो रोकें
        binding?.videoPlayer?.pause()

        // एक्सक्लूसिव संसाधन मुक्त करें
        releaseCamera()
        releaseAudioFocus()
    }

    override fun onResume() {
        super.onResume()
        // ड्राफ्ट पुनर्स्थापित करें
        binding?.titleInput?.setText(prefs.getString("draft_title", ""))
        binding?.bodyInput?.setText(prefs.getString("draft_body", ""))
        acquireCamera()
        acquireAudioFocus()
    }
}

NoteEditorActivity उदाहरण onPause के सही संचालन को दर्शाता है: apply() के माध्यम से SharedPreferences में ड्राफ्ट सहेजना, वीडियो फ़ाइल को रोकना, कैमरा और ऑडियो फोकस मुक्त करना। प्रत्येक कॉल हल्का और तेज़ है, बिना ANR को ट्रिगर करने के लिए पर्याप्त समय तक UI थ्रेड को ब्लॉक किए। क्रम पर ध्यान दें: super.onPause() पहली पंक्ति में कॉल किया जाता है — यह गारंटी देता है कि उपयोगकर्ता कोड में अपवाद होने पर भी सिस्टम तर्क निष्पादित होगा।

onPause में स्थिति सहेजना

onPause अंतिम बिंदु है जहाँ डेवलपर ऐप के छिपाए जाने या सिस्टम द्वारा मारे जाने से पहले उपयोगकर्ता डेटा को विश्वसनीय रूप से सहेज सकता है. onStop के बाद, सिस्टम मेमोरी कम होने पर onDestroy कॉल किए बिना प्रक्रिया समाप्त कर सकता है। onSaveInstanceState() विधि onPause के बाद कॉल की जाती है, लेकिन इसका Bundle दीर्घकालिक भंडारण के लिए नहीं है — यह केवल अगले onCreate तक जीवित रहता है।

apply() के साथ SharedPreferences

एसिंक्रोनस apply() के साथ SharedPreferences onPause में छोटी मात्रा में डेटा सहेजने का इष्टतम तरीका है commit() के विपरीत, जो डिस्क पर सिंक्रोनस रूप से डेटा लिखता है और बूलियन लौटाता है, apply() तुरंत मेमोरी में डेटा सहेजता है और डिस्क पर एसिंक्रोनस लेखन निर्धारित करता है। यह commit() के 10–100 मिलीसेकंड की तुलना में UI थ्रेड पर 1 मिलीसेकंड से भी कम लेता है।

override fun onPause() {
    super.onPause()

    // ❌ खराब: सिंक्रोनस लेखन थ्रेड को ब्लॉक करता है
    // prefs.edit().putInt("score", score).commit()

    // ✅ अच्छा: एसिंक्रोनस लेखन
    prefs.edit().putInt("score", score).apply()

    // जटिल ऑब्जेक्ट के लिए — ViewModel में कैशिंग
    viewModel.saveState()
}

Room और Coroutines

onPause में संरचित डेटा (Room के माध्यम से SQLite) के लिए, lifecycleScope के साथ coroutines का उपयोग किया जाता है. ViewModelScope ViewModel नष्ट होने पर स्वचालित रूप से coroutine को रद्द कर देता है, जो बंद डेटाबेस में लिखने से रोकता है। coroutines के साथ Room के माध्यम से लिखने में 5–15 मिलीसेकंड लगते हैं और UI थ्रेड को ब्लॉक नहीं करता।

// ViewModel में:
fun saveDraft(title: String, body: String) {
    viewModelScope.launch(Dispatchers.IO) {
        noteDao.insert(NoteDraft(title = title, body = body))
    }
}

// Activity.onPause में:
viewModel.saveDraft(
    binding?.titleInput?.text.toString(),
    binding?.bodyInput?.text.toString()
)

Fragment में onPause

Fragment में onPause तब कॉल किया जाता है जब Fragment सक्रिय रहना बंद कर देता है लेकिन दृश्यमान रह सकता है. यह तब होता है जब: Fragment को FragmentTransaction के माध्यम से दूसरे Fragment से बदला जाता है; Fragment ViewPager में वर्तमान पृष्ठ नहीं रह जाता; Fragment वाले Activity को onPause मिलता है। Activity onPause और Fragment onPause के बीच परस्पर क्रिया सख्ती से पदानुक्रमित है: पहले Activity को onPause मिलता है, फिर उसके सभी Fragments को।

class MapFragment : Fragment() {
    private var mapController: MapController? = null

    override fun onPause() {
        super.onPause()
        mapController?.stopFollowMode()
        binding?.mapContainer?.alpha = 0.7f
    }

    override fun onResume() {
        super.onResume()
        binding?.mapContainer?.alpha = 1.0f
        if (isVisible) {
            mapController?.startFollowMode()
        }
    }
}

onPause में मानचित्रों के साथ काम करने की विशिष्टताएँ: Google Maps और Yandex Maps सक्रिय फ़ॉलो मोड में महत्वपूर्ण GPU संसाधनों का उपभोग करते हैं। फोकस खोने पर, मानचित्र एनिमेशन को अक्षम करना और मार्कर अपडेट आवृत्ति कम करना समझ में आता है, और फोकस वापस मिलने पर पूर्ण कार्यक्षमता बहाल करना चाहिए। यह स्क्रीन के बीच स्विच करते समय प्रदर्शन में सुधार करता है और बिजली की खपत कम करता है।

onPause बनाम onStop: अंतर और परिदृश्य

शुरुआती Android डेवलपर्स के बीच सबसे आम भ्रमों में से one onPause और onStop के बीच अंतर न समझ पाना है। आइए प्रत्येक परिदृश्य की जाँच करें और सही विधि निर्धारित करें।

मुख्य नियम: onPause फोकस की किसी भी हानि पर कॉल होता है, onStop केवल दृश्यता पूरी तरह खोने पर कॉल होता है. यदि Activity दृश्यमान रहता है (भले ही आंशिक रूप से), onStop कॉल नहीं होता। यह स्प्लिट स्क्रीन, PiP और पारदर्शी Activity मोड के लिए महत्वपूर्ण है — यहाँ onPause/onResume काम करते हैं, लेकिन onStart/onStop नहीं।

onPause का समय और प्रदर्शन

onPause सबसे समय-महत्वपूर्ण जीवनचक्र विधि है क्योंकि यह अगले Activity के रेंडरिंग को ब्लॉक करती है। सिस्टम नया Activity दिखाने से पहले वर्तमान Activity के onPause के पूरा होने की प्रतीक्षा करता है। यदि onPause 100 मिलीसेकंड से अधिक लेता है, तो उपयोगकर्ता संक्रमण में देरी देखता है; यदि 5 सेकंड से अधिक लेता है, तो सिस्टम ANR प्रदर्शित करता है।

प्रदर्शन अनुशंसाएँ

Google Android Performance Guide (2025) onPause के लिए निम्नलिखित अनुशंसाएँ देता है: नेटवर्क अनुरोध न करें — उन्हें रद्द किया जाना चाहिए या WorkManager में ले जाया जाना चाहिए; डिस्क पर बड़ी फ़ाइलें न लिखें — पृष्ठभूमि थ्रेड पर BufferedWriter का उपयोग करें; जटिल SQL क्वेरी न निष्पादित करें — Room संचालन coroutines के माध्यम से एसिंक्रोनस होना चाहिए; नई ऑब्जेक्ट बनाने से बचें — onPause में कचरा संग्रह देरी को बढ़ा देता है; SharedPreferences के लिए commit() के बजाय apply() का उपयोग करें।

override fun onPause() {
    super.onPause()

    // ❌ खराब: HTTP अनुरोध UI को ब्लॉक करता है
    // val response = api.syncSave(data).execute()

    // ❌ खराब: फ़ाइल में सिंक्रोनस लेखन
    // FileOutputStream(file).write(data)

    // ✅ अच्छा: एसिंक्रोनस सहेजना
    lifecycleScope.launch {
        withContext(Dispatchers.IO) {
            api.saveData(data)
            fileDao.write(data)
        }
    }

    // ✅ अच्छा: SharedPreferences में हल्का लेखन
    prefs.edit().putString("key", value).apply()
}

Android Studio Profiler (CPU ट्रेस) के माध्यम से onPause प्रोफाइलिंग सटीक निष्पादन समय दिखाती है। यदि onPause 100 ms से अधिक लेता है, तो Profiler विधि को पीले रंग में हाइलाइट करता है, और 500 ms से अधिक — लाल रंग में। IT Sectr में वाणिज्यिक परियोजनाओं में, हम Macrobenchmark परीक्षणों का उपयोग करते हैं जो स्वचालित रूप से Activities के बीच संक्रमण समय की जाँच करते हैं और CI पाइपलाइन में प्रदर्शन प्रतिगमन का संकेत देते हैं।

onPause में सामान्य गलतियाँ

अनुभवी डेवलपर्स भी onPause में गलतियाँ करते हैं। आइए पाँच विशिष्ट समस्याओं और उनके समाधानों की जाँच करें।

सिंक्रोनस डेटाबेस लेखन

onPause में सिंक्रोनस क्वेरी (.executeAsObservable() बिना coroutines के) के साथ Room DAO कॉल करना UI थ्रेड को 10–50 ms के लिए ब्लॉक करता है। यदि उसी समय GC या लेखन प्रतिस्पर्धा होती है, तो देरी 200–500 ms तक पहुँच सकती है। समाधान: Dispatchers.IO के साथ coroutines या SharedPreferences के लिए apply() का उपयोग करें।

नए श्रोता पंजीकृत करना

onPause श्रोताओं को पंजीकृत करने का स्थान नहीं है। यदि आप onPause में BroadcastReceiver पंजीकृत करते हैं, तो यह तब सक्रिय रहेगा जब Activity दृश्यमान नहीं है। पंजीकरण केवल onStart/onResume में होना चाहिए, और onPause/onStop में — केवल पंजीकरण रद्द करना। अपवाद Intent-संचालित API हैं जिन्हें कॉल से पहले पंजीकरण की आवश्यकता होती है।

अपवादों को अनदेखा करना

यदि onPause में कोई अनहैंडल अपवाद होता है, तो सिस्टम onStop और onDestroy कॉल नहीं करता। Activity एक अनिश्चित स्थिति में फँस जाता है, और वापसी पर onResume मुक्त किए गए संसाधनों को ठीक से बहाल नहीं कर सकता। समाधान: Log.e() के माध्यम से लॉगिंग के साथ महत्वपूर्ण संचालन को try/catch में लपेटें।

अनावश्यक डेटा सहेजना

onPause में वह डेटा सहेजने की आवश्यकता नहीं है जिसे आसानी से बहाल किया जा सकता है। उदाहरण के लिए, API अनुरोध परिणाम onPause में नहीं, बल्कि प्राप्त करने के समय Room या DataStore में कैश किए जाते हैं। केवल वही सहेजें जो उपयोगकर्ता ने मैन्युअल रूप से दर्ज किया और स्वचालित रूप से बहाल नहीं किया जा सकता — फ़ील्ड में टेक्स्ट, चयनित आइटम, स्क्रॉल स्थिति।

super.onPause() भूलना

super.onPause() कॉल किया जाना चाहिए, लेकिन onCreate के विपरीत, इसे छोड़ने से तत्काल क्रैश नहीं होता। सिस्टम onPause में super की कमी को «माफ» कर देता है, लेकिन आंतरिक स्टेट मशीन गलत स्थिति में चली जाती है। अगला onResume कॉल इनपुट फोकस बहाल करने में विफल हो सकता है, जिससे Activity «जमी» रह जाती है। हमेशा super.onPause() को जितनी जल्दी हो सके कॉल करें।