Warm Start: सार, वार्म लॉन्च और Android में अनुकूलन

Q: क्या Warm Start Cold Start में बदल सकता है?

हाँ, यदि Warm Start के क्षण में सिस्टम ऐप प्रक्रिया को मारने का निर्णय लेता है (जैसे, किसी अन्य ऐप के लिए मेमोरी खाली करने के लिए), तो लॉन्च खरोंच से Cold Start बन जाता है। यह 2–3 GB RAM वाले उपकरणों पर होता है जब कई ऐप एक साथ चल रहे होते हैं। वास्तव में, मध्य-श्रेणी के उपकरणों पर मिनिमाइज़ करने के बाद Warm Start केवल 10–20 मिनट के लिए गारंटीकृत है।

Q: क्या Warm Start के दौरान ViewModel संरक्षित रहता है?

हाँ, यदि प्रक्रिया नहीं मारी गई, तो ViewModel मेमोरी में रहता है और onCleared नहीं बुलाया जाता है। यह Warm Start का एक मुख्य लाभ है: नेटवर्क अनुरोधों के माध्यम से लोड किया गया सारा डेटा, ViewModel में कैश — सब कुछ तुरंत उपलब्ध है। यदि प्रक्रिया मार दी गई, तो ViewModelProvider.Factory या @HiltViewModel के माध्यम से ViewModel नए सिरे से बनाया जाता है, और SavedStateHandle सहेजे गए फ़ील्ड को पुनर्स्थापित करता है।

Q: Warm Start Cold Start से धीमा क्यों हो सकता है?

सैद्धांतिक रूप से, Warm Start हमेशा Cold Start से तेज़ होता है, लेकिन व्यवहार में ऐसे परिदृश्य हैं जहाँ अंतर न्यूनतम है: यदि Application.onCreate हल्का था (50 ms) और Activity.onCreate भारी है (800 ms), तो Warm Start (800 ms) लगभग Cold Start (850 ms) के बराबर है। इस मामले में, आपको Application नहीं, बल्कि Activity.onCreate को अनुकूलित करना चाहिए — यह Warm Start के लिए बाधा बन जाता है।

Q: SplashScreen API Warm Start को कैसे प्रभावित करता है?

Android 12+ पर SplashScreen API स्टार्टअप पर तुरंत एक सिस्टम स्प्लैश (रंगीन पृष्ठभूमि पर आइकन) दिखाता है — Cold और Warm Start दोनों के लिए। Warm Start के लिए, स्प्लैश केवल 100–300 ms के लिए प्रदर्शित होता है, जिसके बाद इसे ऐप के UI से बदल दिया जाता है। SplashScreen लॉन्च को गति नहीं देता, बल्कि Activity निर्माण समय को छिपाकर धारणा में सुधार करता है।

Q: क्या Warm Start को अनुकूलित करना आवश्यक है यदि Cold Start पहले से तेज़ है?

हाँ, क्योंकि Warm Start Cold Start की तुलना में 2–3 गुना अधिक बार होता है। यदि Cold Start में 1.2 सेकंड लगते हैं और Warm Start में 600 ms लगते हैं, तो 40% लॉन्च (Warm) अभी भी 0.6 सेकंड लेते हैं, जो ध्यान देने योग्य है। Warm Start को 200–300 ms तक अनुकूलित करने से उपयोगकर्ता को तत्काल वापसी का एहसास होता है। 6+ GB RAM वाले उपकरणों पर, Warm Start सभी लॉन्च का 80% तक हो सकता है, जिससे इसका अनुकूलन प्राथमिकता बन जाता है।

लेखक: IT Sectr प्रकाशित: 2026-03-31 पढ़ने का समय: 8 मिनट

Warm Start एक Android ऐप लॉन्च परिदृश्य है जहाँ ऐप प्रक्रिया पहले से मेमोरी में मौजूद होती है (जैसे, मिनिमाइज़ करने के बाद), लेकिन Activity को संसाधन बचाने के लिए सिस्टम द्वारा नष्ट कर दिया गया था। Application.onCreate पहले ही निष्पादित हो चुका है, क्लासेज़ लोड हो चुकी हैं, लेकिन UI नए सिरे से बनाया जाता है। Google, 2024 के अनुसार, Warm Start में 200–800 ms लगते हैं और 4 GB RAM वाले उपकरणों पर लगभग 40% लॉन्च होते हैं।

मुख्य बातें

Warm Start — मौजूदा प्रक्रिया के साथ ऐप लॉन्च करना, लेकिन मेमोरी में Activity के बिना
Cold Start से अंतर: Application.onCreate निष्पादित नहीं होता, क्लासेज़ पहले से लोड हैं
समय Warm Start में 200–800 ms लगते हैं जबकि Cold Start में 1–5 सेकंड
परिदृश्य: कई घंटों के बाद ऐप पर वापसी, OOM-killer द्वारा Activity हटाना
अनुकूलन Activity स्थिति और डेटा कैशिंग के संरक्षण पर केंद्रित है

Warm Start क्या है

Warm Start Cold Start और Hot Start के बीच की स्थिति है: ऐप प्रक्रिया मेमोरी में मौजूद है (कभी-कभी Linux बैकग्राउंड कैश में), लेकिन Activity सक्रिय नहीं है और नए सिरे से बनाई जाएगी। जब Android की RAM कम हो जाती है, तो यह Activity को स्टैक से हटा सकता है, प्रक्रिया को जीवित छोड़कर। जब उपयोगकर्ता ऐप पर लौटता है, तो Warm Start होता है: एक नया Activity इंस्टेंस बनाया जाता है, लाइफसाइकिल विधियाँ onCreate → onStart → onResume निष्पादित होती हैं, लेकिन Application.onCreate और क्लास लोडिंग को छोड़ दिया जाता है।

Warm Start के कारण

Android प्रक्रिया प्राथमिकता (महत्व रैंक) के आधार पर Activity को हटाने का निर्णय लेता है। बैकग्राउंड में Activity (स्तर PROCESS_STATE_IMPORTANT_FOREGROUND या PROCESS_STATE_TOP_SLEEPING) ऐप मिनिमाइज़ करने के 5–30 मिनट बाद नष्ट हो सकती है, उपलब्ध RAM पर निर्भर करता है। 3 GB RAM वाले उपकरणों पर, Activity 10 मिनट के भीतर हटाई जा सकती है; 8 GB RAM वाले उपकरणों पर, कई घंटों के बाद। महत्वपूर्ण: Warm Start के दौरान onSaveInstanceState को Activity नष्ट होने से पहले बुलाया जाता है, और डेवलपर UI स्थिति सहेज सकता है।

उपयोगकर्ता धारणा

उपयोगकर्ता Warm और Cold Start के बीच अंतर नहीं देखता — वह बस ऐप आइकन पर टैप करता है और प्रतीक्षा करता है। हालाँकि, Warm Start के दौरान, एक खाली सफेद स्क्रीन दिखाई दे सकती है यदि ऐप ने कस्टम स्टार्टअप विंडो थीम सेट नहीं की है। Google स्टार्टअप Activity के लिए मेनिफेस्ट में कस्टम थीम (Theme.AppCompat.Light या Theme.Material3.DayNight) सेट करने की सलाह देता है ताकि Warm Start के दौरान सफेद/काली स्क्रीन की झिलमिलाहट से बचा जा सके। Android 12+ पर, SplashScreen API भी इस प्रभाव को छिपाता है।

Warm Start vs Cold Start vs Hot Start

तीनों लॉन्च प्रकारों के बीच अंतर समझना सही प्रोफाइलिंग और अनुकूलन रणनीति चुनने के लिए आवश्यक है। प्रत्येक प्रकार की अपनी अवधि, अपनी बाधाएँ और माप उपकरण होते हैं।

मापदंड	Cold Start	Warm Start	Hot Start
प्रक्रिया	नए सिरे से बनाई जाती है	मेमोरी में मौजूद है	मेमोरी में मौजूद है
Application.onCreate	निष्पादित होता है	निष्पादित नहीं होता	निष्पादित नहीं होता
Activity	नए सिरे से बनाई जाती है	नए सिरे से बनाई जाती है	स्टैक से पुनर्स्थापित की जाती है
समय	1–5 सेकंड	200–800 ms	< 200 ms
Activity.onCreate	पूर्ण	पूर्ण (पुनर्स्थापना के साथ)	छोड़ दिया जाता है

व्यवहार में, Warm Start उपयोगकर्ता की आदतों और डिवाइस RAM के आधार पर सभी ऐप लॉन्च के 30% से 60% तक होता है। जो उपयोगकर्ता कई ऐप खुले रखते हैं (मल्टीटास्कर), वे Warm Start का अधिक सामना करते हैं। सोशल नेटवर्क और मैसेंजर के लिए, Warm Start सबसे आम परिदृश्य है क्योंकि ऐप हमेशा बैकग्राउंड में रहता है। बैंकिंग ऐप के लिए, इसके विपरीत, Cold Start प्रमुख है (सुरक्षा कारणों से प्रक्रिया की अनिवार्य सफाई)।

वार्म लॉन्च के चरण

Warm Start तीन चरणों से बना है, जिनमें से प्रत्येक को मापा और अनुकूलित किया जा सकता है। Cold Start के विपरीत, यहाँ कोई fork चरण या क्लास लोडिंग नहीं है, लेकिन एक स्थिति पुनर्स्थापना चरण है जो महंगा हो सकता है।

चरण 1: स्टार्टअप विंडो (विंडो बैकग्राउंड)

सिस्टम जाँचता है कि ऐप के पास स्टार्टअप विंडो के लिए थीम है या नहीं। यदि थीम सेट नहीं है, तो एक सफेद (या काली, सिस्टम पर निर्भर) स्क्रीन दिखाई देती है। यदि थीम सेट है, तो थीम बैकग्राउंड दिखाया जाता है। यह चरण 10–30 ms लेता है, लेकिन यह दृष्टिगत रूप से ध्यान देने योग्य है यदि थीम ऐप के वास्तविक UI से मेल नहीं खाती। Theme.Material3.DayNight का उपयोग कस्टम windowBackground के साथ करें जिसका रंग पहली स्क्रीन के बैकग्राउंड से मेल खाता हो — यह तत्काल लोडिंग प्रभाव पैदा करता है।

चरण 2: Activity निर्माण (पुनर्स्थापना)

सिस्टम onCreate को Bundle savedInstanceState पास करके बुलाता है जो Activity नष्ट होने से पहले onSaveInstanceState में सहेजा गया था। यदि ऐप ने स्थिति को ठीक से सहेजा (फ़ील्ड टेक्स्ट, स्क्रॉल स्थिति, ViewModel डेटा), तो पुनर्स्थापना जल्दी होती है। यदि नहीं, तो Activity खरोंच से शुरू होती है और उपयोगकर्ता डेटा लोड होने तक लोडर देखता है। मुख्य बिंदु: ViewModel ऑब्जेक्ट Warm Start से केवल तभी बचते हैं यदि प्रक्रिया नष्ट नहीं हुई थी — Warm Start के दौरान, ViewModel मेमोरी में रहता है।

चरण 3: पहला फ्रेम (TTFD)

onCreate के बाद, onStart → onResume निष्पादित होते हैं, और सिस्टम पहली ड्रॉ को ट्रिगर करता है। TTFD (Time To First Draw) Warm Start के लिए मध्य-श्रेणी के उपकरण पर 300 ms से कम होना चाहिए। यदि पहली स्क्रीन में भारी Views के साथ जटिल RecyclerView है या नेटवर्क से इमेज लोड करती है, तो TTFD सीमा से अधिक हो सकता है। पहले फ्रेम के बाद सामग्री की सुचारू लोडिंग के लिए Placeholder और Shimmer का उपयोग करें।

Warm Start कैसे मापें

Warm Start को मापना Cold Start से अधिक जटिल है क्योंकि आपको उस स्थिति का अनुकरण करने की आवश्यकता है जहाँ प्रक्रिया जीवित है लेकिन Activity नष्ट हो गई है। -S फ्लैग के साथ मानक ADB कमांड काम नहीं करता — यह प्रक्रिया को मार देता है। Warm Start के लिए अलग दृष्टिकोण का उपयोग करें।

ADB shell am start बिना -S के

पहले, adb shell monkey के माध्यम से ऐप लॉन्च करें या आइकन पर टैप करें, फिर इसे मिनिमाइज़ करें (adb shell input keyevent 3 keyevent HOME)। 5–10 सेकंड प्रतीक्षा करें ताकि सिस्टम Activity को हटा सके, फिर adb shell am start -W (बिना -S के) चलाएँ। कमांड Cold Start की तुलना में कम स्टार्टअप समय लौटाएगा। पुनरुत्पादन के लिए, एक स्क्रिप्ट का उपयोग करें: लॉन्च → प्रतीक्षा → होम → प्रतीक्षा → लॉन्च।

bash

# ADB के माध्यम से Warm Start का अनुकरण
$ adb shell am start -W \
    com.example.app/.MainActivity

# आउटपुट (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Warm Start के लिए Macrobenchmark

androidx.benchmark.macro लाइब्रेरी Warm Start मापन का समर्थन करती है। परीक्षण में, startupMode = StartupMode.WARM सेट करें — लाइब्रेरी ऐप लॉन्च करेगी, इसे मिनिमाइज़ करेगी, प्रतीक्षा करेगी (कॉन्फ़िगरेबल विलंब), और फिर पुनः लॉन्च को मापेगी। Macrobenchmark 10–20 पुनरावृत्तियाँ करता है और प्रतिशतक की गणना करता है। CI/CD में, आप एक सीमा निर्धारित कर सकते हैं: यदि P50 Warm Start 600 ms से अधिक हो जाता है, तो परीक्षण विफल हो जाता है। यह प्रत्येक कमिट के साथ प्रतिगमन को ट्रैक करने की अनुमति देता है।

Firebase Performance Monitoring

Firebase अंतिम ऐप बंद होने के समय के आधार पर स्वचालित रूप से Cold और Warm Start के बीच अंतर करता है। यदि ऐप पिछले 30 मिनट के भीतर खोला गया था, तो Firebase लॉन्च को Warm के रूप में वर्गीकृत करता है। Firebase कंसोल में, आप प्रत्येक स्टार्टअप प्रकार के लिए अलग-अलग चार्ट देखेंगे, जिससे आप अनुकूलन प्रभावशीलता का मूल्यांकन कर सकते हैं। उदाहरण के लिए, ViewModel में स्थिति संरक्षण लागू करने के बाद, आप Warm Start समय में 30% की कमी देख सकते हैं।

Warm Start को कैसे अनुकूलित करें

Warm Start अनुकूलन दो क्षेत्रों पर केंद्रित है: Activity.onCreate को तेज़ करना और उचित स्थिति पुनर्स्थापना। चूँकि Application.onCreate और क्लास लोडिंग पहले ही पूरी हो चुकी है, मुख्य बाधा पहली स्क्रीन का UI कोड है।

अतुल्यकालिक स्थिति पुनर्स्थापना

यदि सहेजी गई स्थिति (savedInstanceState) में ऐसा डेटा है जिसे डिसीरियलाइज़ेशन (Bitmap, String, JSON) की आवश्यकता है, तो इसे बैकग्राउंड थ्रेड पर करें। onCreate में Bundle से सीधे पढ़ने के बजाय, एक coroutine लॉन्च करें और shimmer स्क्रीन दिखाएँ। व्यवहार में, मध्य-श्रेणी के उपकरण पर Bundle डिसीरियलाइज़ेशन में 20–100 ms लगते हैं — यह छोटा लगता है, लेकिन Warm Start के लिए, यह कुल समय का 10–50% है। Jetpack के Saved State Module का उपयोग करें, जो स्वचालित रूप से Bundle या डेटाबेस में ViewModel स्थिति को सहेजता और पुनर्स्थापित करता है।

setContentView का अनुकूलन

XML लेआउट इन्फ्लेशन Warm Start के सबसे महंगे चरणों में से एक है। यदि पहली स्क्रीम AppBar, CollapsingToolbar, NestedScrollView प्लस तीन RecyclerViews के साथ जटिल CoordinatorLayout का उपयोग करती है, तो इन्फ्लेशन का समय 300 ms तक पहुँच सकता है। समाधान: सपाट पदानुक्रम के लिए ConstraintLayout का उपयोग करें, स्टार्टअप पर दिखाई न देने वाले अनुभागों (बॉटम शीट, डायलॉग) के लिए ViewStub लागू करें, AsyncLayoutInflater के माध्यम से भारी फ़्रैगमेंट के लिए अतुल्यकालिक इन्फ्लेशन सक्षम करें। Jetpack Compose में, इन्फ्लेशन की आवश्यकता नहीं है, लेकिन Warm Start के दौरान Compose ट्री संकलन समान समय ले सकता है।

डेटा कैशिंग

Warm Start के दौरान, ऐप ने पिछले सत्र में जो डेटा लोड किया था वह पहले से कैश में हो सकता है: Room डेटाबेस, SharedPreferences, ViewModel में इन-मेमोरी कैश। यदि आपकी पहली स्क्रीन सर्वर से एक सूची दिखाती है, तो स्टार्टअप पर कैश जाँचें और बैकग्राउंड में डेटा अपडेट करें। cache-then-network रणनीति का उपयोग करें: पहले कैश किया गया डेटा दिखाएँ (तुरंत), फिर सर्वर से अपडेट करें (अतुल्यकालिक रूप से)। यह कथित Warm Start समय को 100–200 ms तक कम कर देता है।

kotlin

// Warm Start के लिए कैशिंग के साथ ViewModel
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // पहले कैश, फिर नेटवर्क
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: डेटा पहले से DB में
            cache.emit(api.fetchItems()) // बैकग्राउंड अपडेट
        }
    }
}

Warm Start के दौरान स्थिति संरक्षण

उचित स्थिति संरक्षण वह मुख्य कारक है जो अच्छे Warm Start को बुरे से अलग करता है। उपयोगकर्ता ऐप पर लौटने और वही देखने की अपेक्षा करता है जो उन्होंने छोड़ा था — स्क्रॉल स्थिति, फ़ील्ड में टेक्स्ट और चयनित टैब सहित।

onSaveInstanceState

सिस्टम onSaveInstanceState को तब बुलाता है जब Activity नष्ट की जा रही होती है, लेकिन प्रक्रिया के मारे जाने से पहले। Bundle में केवल सरल डेटा प्रकार (String, Int, Parcelable, Serializable) सहेजे जाते हैं। जटिल डेटा के लिए, ViewModel में SavedStateHandle का उपयोग करें — यह Warm Start के दौरान स्वचालित रूप से फ़ील्ड को सहेजता और पुनर्स्थापित करता है। onSaveInstanceState के विपरीत, SavedStateHandle तब भी काम करता है जब प्रक्रिया Warm Start से बच जाती है (ViewModel नष्ट नहीं होता)। उदाहरण: EditText में टेक्स्ट के लिए, SavedStateHandle.getLiveData(“text”) का उपयोग करें — टेक्स्ट स्वचालित रूप से सहेजा और पुनर्स्थापित किया जाएगा।

ViewModel और Warm Start

यदि Warm Start के दौरान प्रक्रिया नहीं मारी गई, तो ViewModel मेमोरी में रहता है और onCleared नहीं बुलाया जाता है। इसका मतलब है कि पिछले सत्र में लोड किया गया सारा डेटा तुरंत उपलब्ध है। हालाँकि, यदि प्रक्रिया मार दी गई (डिवाइस 30 मिनट से अधिक गहरी नींद में), तो ViewModel नष्ट हो जाता है और SavedStateHandle के साथ नए सिरे से बनाया जाता है। Warm Start के दौरान सही ViewModel व्यवहार के लिए, उन फ़ील्ड के साथ SavedStateHandle का उपयोग करें जिन्हें किसी भी परिदृश्य में पुनर्स्थापित करने की आवश्यकता है। अंतर: @HiltViewModel वाला ViewModel स्वचालित रूप से SavedStateHandle का समर्थन करता है।

तंत्र	प्रक्रिया जीवित	प्रक्रिया मारी गई
ViewModel	मेमोरी में डेटा	नष्ट, नए सिरे से बनाया गया
SavedStateHandle	मेमोरी में डेटा	Bundle से पुनर्स्थापित
onSaveInstanceState	Activity हटाने पर बुलाया जाता है	नहीं बुलाया जाता
Room DB	कैश उपलब्ध	कैश उपलब्ध (डिस्क)

RecyclerView स्क्रॉल स्थिति सहेजना

Warm Start की सबसे आम समस्याओं में से एक — स्क्रॉल स्थिति खोना। उपयोगकर्ता 50वें आइटम पर स्क्रॉल करता है, ऐप मिनिमाइज़ करता है, लौटता है — और सूची की शुरुआत देखता है। समाधान: layoutManager.onSaveInstanceState सहेजें (पहले दिखाई देने वाले आइटम की स्थिति और ऑफ़सेट सहेजता है) और इसे onRestoreInstanceState में पुनर्स्थापित करें। आप अंतिम दृश्य स्थिति को दिनांक/समय कुंजी के साथ SharedPreferences में भी सहेज सकते हैं ताकि Warm Start के दौरान स्थिति को जल्दी से पुनर्स्थापित किया जा सके।

kotlin

// RecyclerView स्क्रॉल स्थिति सहेजना
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putParcelable(
        "rv_state", binding.recyclerView
            .layoutManager?.onSaveInstanceState()
    )
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    savedInstanceState?.getParcelable<Parcelable>("rv_state")
        ?.let { binding.recyclerView.layoutManager?.onRestoreInstanceState(it) }
}

Warm Start के लिए कोड उदाहरण

Warm Start अनुकूलन के दो व्यावहारिक उदाहरण: ViewModel में SavedStateHandle का उपयोग और स्टार्टअप के बाद जटिल डेटा की अतुल्यकालिक पुनर्स्थापना।

ViewModel with SavedStateHandle

SavedStateHandle स्वचालित रूप से Bundle में फ़ील्ड सहेजता है और Warm Start के दौरान उन्हें पुनर्स्थापित करता है। उपयोगकर्ता प्रोफ़ाइल फ़ील्ड (String, JSON) अनावश्यक सर्वर अनुरोधों के बिना पुनर्स्थापित हो जाएगी। यदि प्रक्रिया मार दी गई, तो SavedStateHandle Bundle से अंतिम सहेजी गई स्थिति लोड करता है।

kotlin

class ProfileViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val profile: StateFlow<Profile?>
        get() = savedStateHandle
            .getStateFlow("profile", null)

    fun loadProfile(id: String) {
        viewModelScope.launch {
            savedStateHandle["profile"] =
                api.getProfile(id)
        }
    }
}

// Warm Start: profile null नहीं, UI बिना लोडर के
// लोड करने के बाद: profile SavedStateHandle में अपडेट होता है

भारी स्क्रीन के लिए AsyncLayoutInflater

यदि पहली स्क्रीन में जटिल लेआउट है (मानचित्र, ग्रेडिएंट, कई सूचियाँ), तो भारी तत्वों को बैकग्राउंड में इन्फ्लेट करने के लिए AsyncLayoutInflater का उपयोग करें। जब लेआउट इन्फ्लेट हो रहा हो, तो शिमर प्रभाव के साथ placeholder दिखाएँ। यह Warm Start के लिए विशेष रूप से महत्वपूर्ण है, जहाँ हर मिलीसेकंड मायने रखता है। AsyncLayoutInflater बैकग्राउंड थ्रेड पर चलता है और तैयार View को मुख्य थ्रेड पर कॉलबैक में पास करता है।

kotlin

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // तत्काल रेंडरिंग के लिए Placeholder लेआउट
        setContentView(R.layout.placeholder_shimmer)

        // भारी लेआउट की अतुल्यकालिक लोडिंग
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}

अक्सर पूछे जाने वाले प्रश्न

क्या Warm Start Cold Start में बदल सकता है?

हाँ, यदि Warm Start के क्षण में सिस्टम ऐप प्रक्रिया को मारने का निर्णय लेता है (जैसे, किसी अन्य ऐप के लिए मेमोरी खाली करने के लिए), तो लॉन्च खरोंच से Cold Start बन जाता है। यह 2–3 GB RAM वाले उपकरणों पर होता है जब कई ऐप एक साथ चल रहे होते हैं। वास्तव में, मध्य-श्रेणी के उपकरणों पर मिनिमाइज़ करने के बाद Warm Start केवल 10–20 मिनट के लिए गारंटीकृत है।

क्या Warm Start के दौरान ViewModel संरक्षित रहता है?

हाँ, यदि प्रक्रिया नहीं मारी गई, तो ViewModel मेमोरी में रहता है और onCleared नहीं बुलाया जाता है। यह Warm Start का एक मुख्य लाभ है: नेटवर्क अनुरोधों के माध्यम से लोड किया गया सारा डेटा, ViewModel में कैश — सब कुछ तुरंत उपलब्ध है। यदि प्रक्रिया मार दी गई, तो ViewModelProvider.Factory या @HiltViewModel के माध्यम से ViewModel नए सिरे से बनाया जाता है, और SavedStateHandle सहेजे गए फ़ील्ड को पुनर्स्थापित करता है।

Warm Start Cold Start से धीमा क्यों हो सकता है?

सैद्धांतिक रूप से, Warm Start हमेशा Cold Start से तेज़ होता है, लेकिन व्यवहार में ऐसे परिदृश्य हैं जहाँ अंतर न्यूनतम है: यदि Application.onCreate हल्का था (50 ms) और Activity.onCreate भारी है (800 ms), तो Warm Start (800 ms) लगभग Cold Start (850 ms) के बराबर है। इस मामले में, आपको Application नहीं, बल्कि Activity.onCreate को अनुकूलित करना चाहिए — यह Warm Start के लिए बाधा बन जाता है।

SplashScreen API Warm Start को कैसे प्रभावित करता है?

Android 12+ पर SplashScreen API स्टार्टअप पर तुरंत एक सिस्टम स्प्लैश (रंगीन पृष्ठभूमि पर आइकन) दिखाता है — Cold और Warm Start दोनों के लिए। Warm Start के लिए, स्प्लैश केवल 100–300 ms के लिए प्रदर्शित होता है, जिसके बाद इसे ऐप के UI से बदल दिया जाता है। SplashScreen लॉन्च को गति नहीं देता, बल्कि Activity निर्माण समय को छिपाकर धारणा में सुधार करता है।

क्या Warm Start को अनुकूलित करना आवश्यक है यदि Cold Start पहले से तेज़ है?

हाँ, क्योंकि Warm Start Cold Start की तुलना में 2–3 गुना अधिक बार होता है। यदि Cold Start में 1.2 सेकंड लगते हैं और Warm Start में 600 ms लगते हैं, तो 40% लॉन्च (Warm) अभी भी 0.6 सेकंड लेते हैं, जो ध्यान देने योग्य है। Warm Start को 200–300 ms तक अनुकूलित करने से उपयोगकर्ता को तत्काल वापसी का एहसास होता है। 6+ GB RAM वाले उपकरणों पर, Warm Start सभी लॉन्च का 80% तक हो सकता है, जिससे इसका अनुकूलन प्राथमिकता बन जाता है।

सारांश

Warm Start — मौजूदा प्रक्रिया के साथ ऐप लॉन्च करना, मेमोरी में Activity के बिना, समय 200–800 ms
Cold Start से मुख्य अंतर: Application.onCreate निष्पादित नहीं होता, क्लासेज़ लोड हैं
Warm Start के तीन चरण: स्टार्टअप विंडो → Activity निर्माण → पहला फ्रेम
-S फ्लैग के बिना ADB या StartupMode.WARM के साथ Macrobenchmark के माध्यम से मापा जाता है
अनुकूलन: SavedStateHandle, AsyncLayoutInflater, cache-then-network, ConstraintLayout
ViewModel Warm Start के दौरान संरक्षित रहता है (प्रक्रिया जीवित) — डेटा तुरंत उपलब्ध
Warm Start सभी ऐप लॉन्च का 40–80% होता है

हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे

IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।

परियोजना पर चर्चा करें

यह भी पढ़ें

LeakCanary — यह क्या है, Android में मेमोरी लीक का पता लगाना →

Cold Start — अर्थ, लॉन्च समय और Android में ऑप्टिमाइज़ेशन →

मोबाइल ऐप्स में Hot Start: यह क्या है, कारण और लॉन्च को कैसे तेज़ करें →

फ़ीचर क्रीप इन डेवलपमेंट — यह क्या है, कारण और इससे कैसे निपटें →

डेवलपमेंट में ट्रैश कोड — यह क्या है, संकेत और कैसे साफ करें →