Cold Start — कोल्ड लॉन्च और Android में ऑप्टिमाइज़ेशन

Cold Start क्या है

Cold Start (कोल्ड लॉन्च) एक परिदृश्य है जिसमें Android एप्लिकेशन सबसे प्रारंभिक स्थिति से लॉन्च होता है: ऑपरेटिंग सिस्टम एक नई प्रक्रिया बनाता है (Zygote से fork), मेमोरी आवंटित करता है, DEX कोड को ART में लोड करता है, क्लासेस को इनिशियलाइज़ करता है, और एक Application इंस्टेंस बनाता है, फिर पहली Activity। ऐप लॉन्च होने से पहले, डिवाइस मेमोरी में इसके बारे में कोई डेटा नहीं होता, सिवाय कैश की गई क्लास इमेजेज़ के यदि Background Dexopt का उपयोग किया जाता है।

Cold Start कब होता है

कोल्ड लॉन्च तीन मामलों में होता है: ऐप इंस्टॉलेशन के बाद पहले लॉन्च पर, डिवाइस रिबूट के बाद लॉन्च पर, और मेमोरी की कमी के कारण सिस्टम द्वारा प्रक्रिया को हटाने के बाद लॉन्च पर। 2–4 GB RAM वाले डिवाइसों पर, सिस्टम बैकग्राउंड प्रक्रियाओं को काफी आक्रामक रूप से हटाता है, इसलिए Cold Start हर बार हो सकता है जब उपयोगकर्ता कई घंटों की निष्क्रियता के बाद ऐप पर लौटता है। Android 12+ पर, सिस्टम एक फ़्रोज़न प्रक्रिया (freeze / cached) रख सकता है, लेकिन सक्रिय मेमोरी बचत (OOM-killer) के साथ, प्रक्रिया समाप्त कर दी जाएगी।

Cold Start एक महत्वपूर्ण मीट्रिक क्यों है

Google (Find My Device रिपोर्ट, 2023) के अनुसार, 65% उपयोगकर्ता ऐप बंद कर देते हैं यदि वह 3 सेकंड में नहीं खुलता। सोशल नेटवर्क और मैसेजिंग ऐप्स के लिए, जहां उपयोगकर्ता दिन में दर्जनों बार लौटते हैं, Cold Start सीधे प्रतिधारण को प्रभावित करता है। Google Play Console में, Cold Start मीट्रिक Android Vitals अनुभाग का हिस्सा है और इसे ANR और प्रदर्शन संकेतकों में से एक के रूप में प्रदर्शित किया जाता है। एक ऐप जो “खराब” Cold Start सीमा (25% डिवाइसों पर 5 सेकंड से अधिक) से अधिक है, कंसोल में चेतावनी प्राप्त करता है और खोज परिणामों में डाउनग्रेड किया जा सकता है।

Cold Start vs Warm Start vs Hot Start

Android तीन प्रकार के ऐप लॉन्च में अंतर करता है, प्रत्येक की अलग अवधि, UX प्रभाव और ऑप्टिमाइज़ेशन दृष्टिकोण होते हैं। अंतर को समझना सही प्रोफाइलिंग रणनीति चुनने के लिए आवश्यक है।

Warm Start तब होता है जब ऐप प्रक्रिया पहले से बैकग्राउंड में मौजूद है, लेकिन Activity नष्ट हो गई है (जैसे, उपयोगकर्ता लंबे विराम के बाद लौटा और सिस्टम ने Activity मेमोरी मुक्त कर दी)। Hot Start — जब उपयोगकर्ता ऐप को छोटा करता है और तुरंत फिर से खोलता है: Activity रुकी हुई है और पुनर्स्थापना में न्यूनतम समय लगता है। उपयोगकर्ता के लिए, Cold Start सबसे ध्यान देने योग्य लॉन्च प्रकार है, और इसका ऑप्टिमाइज़ेशन UX में सबसे बड़ा सुधार देता है।

प्रकारों के बीच संक्रमण

Cold Start Warm Start बन सकता है जब ऐप कम से कम एक बार लॉन्च हो चुका हो — ART संकलित क्लास इमेजेज़ (Boot Profile में Image) को कैश करता है और बाद में DEX लोडिंग तेज़ होती है। इसलिए, पहले Cold Start के बाद दूसरा लॉन्च आमतौर पर 20–40% तेज़ होता है। यदि ऐप Baseline Profiles का उपयोग करता है, तो प्रोफ़ाइल पहले लॉन्च पर लोड होती हैं और दूसरा स्टार्ट और भी तेज़ हो सकता है: Google Play, जिसने Baseline Profiles प्रकाशित कीं, ने Android 12+ वाले डिवाइसों पर Cold Start को 30% तक तेज़ किया।

कोल्ड लॉन्च के चरण

Cold Start में सख्ती से परिभाषित चरण होते हैं, जिनमें से प्रत्येक को स्वतंत्र रूप से मापा और ऑप्टिमाइज़ किया जा सकता है। चरणों को जानने से यह निर्धारित करने में मदद मिलती है कि ऐप किस चरण में समय खो रहा है। Google चार मुख्य चरणों की पहचान करता है: प्रक्रिया निर्माण, Application इनिशियलाइज़ेशन, Activity निर्माण, और पहला फ्रेम।

चरण 1: प्रक्रिया निर्माण (fork)

Android सिस्टम (ActivityManagerService) Zygote प्रक्रिया से fork करके एक नई प्रक्रिया बनाता है। Zygote सामान्य Android क्लासेस के साथ पहले से लोड की गई प्रक्रिया है। Fork में 30–80 ms लगते हैं — यह समय ऐप के नियंत्रण से बाहर है। Fork के बाद, ActivityThread शुरू होता है — एप्लिकेशन का मुख्य लूप इंस्टेंस। इस चरण में, ClassLoader के माध्यम से क्लास लोडिंग भी होती है, और ART पहले बाइटकोड की व्याख्या करना शुरू करता है। यदि ऐप कई स्टैटिक इनिशियलाइज़र का उपयोग करता है, तो यह चरण लंबा हो सकता है।

चरण 2: Application.onCreate

ActivityThread शुरू होने के तुरंत बाद, Application.onCreate कॉल किया जाता है। यहां डेवलपर अक्सर गलती करते हैं, सब कुछ एक साथ इनिशियलाइज़ करके: Crashlytics, Firebase, नेटवर्क क्लाइंट, डेटाबेस, Dagger घटक, DI कंटेनर। ऐसा प्रत्येक इनिशियलाइज़ेशन मुख्य थ्रेड पर अवरुद्ध समय है। यदि Application.onCreate में 500 ms लगते हैं, तो उपयोगकर्ता आधे सेकंड के लिए सफेद (या काली) स्क्रीन देखता है। मिड-रेंज डिवाइस पर इस चरण की इष्टतम अवधि 200 ms से कम है।

चरण 3: Activity.onCreate

Application इनिशियलाइज़ेशन के बाद, एक Activity इंस्टेंस बनाया जाता है (MainActivity या Launcher Activity)। Activity.onCreate कॉल किया जाता है, जहां setContentView, फ़्रैगमेंट इनिशियलाइज़ेशन, ViewModel सेटअप, और LiveData/Flow सब्सक्रिप्शन होते हैं। यदि onCreate मुख्य थ्रेड पर डेटा (SharedPreferences, SQLite, API) सिंक्रोनस रूप से लोड करता है, तो चरण बढ़ जाता है। लक्ष्य मिड-रेंज डिवाइस पर onCreate को 200–400 ms में रखना है।

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

OnCreate पूरा होने के बाद, पहला रेंडरिंग शुरू होता है: माप, लेआउट, ड्रॉ। इस क्षण को TTFD (Time To First Draw) कहा जाता है। यदि ऐप स्प्लैश स्क्रीन (Android 12+ पर SplashScreen API के माध्यम से या theme के माध्यम से) का उपयोग करता है, तो रेंडरिंग तेज़ हो सकती है, लेकिन उपयोगकर्ता अभी भी तब तक प्रतीक्षा करेगा जब तक स्प्लैश गायब न हो जाए। Cold Start के लिए आदर्श TTFD 1.5 सेकंड से कम है।

Cold Start कैसे मापें

Cold Start को मापने के लिए विशेष उपकरणों की आवश्यकता होती है, क्योंकि सामान्य लॉगिंग (Log.d) केवल Application निर्माण के बाद काम करना शुरू करती है, और fork टाइमिंग और क्लास लोडिंग दुर्गम रहती है। Google तीन विधियों की सिफारिश करता है: ADB कमांड, Android Vitals, और कस्टम परफ़ मैक्रोज़।

ADB के माध्यम से मापन

सबसे सरल और पुनरुत्पादक विधि adb shell am start -S -W कमांड है। -S फ़्लैग लॉन्च से पहले ऐप को जबरन रोकता है (Cold Start सुनिश्चित करता है)। कमांड तीन मीट्रिक आउटपुट करता है: ThisTime (Activity स्टार्ट समय), TotalTime (प्रक्रिया लॉन्च सहित कुल समय), और WaitTime (Activity Manager की सभी देरी सहित समय)। स्वच्छ माप के लिए, 5–7 रीडिंग लें और मीडियन का उपयोग करें — एकल रीडिंग शोर (CPU थ्रॉटलिंग, बैकग्राउंड लोड) के अधीन हैं।

# माप के साथ बलपूर्वक Cold Start
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# कमांड आउटपुट:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Google Play Console उन सभी डिवाइसों से गुमनाम मीट्रिक एकत्र करता है जहां ऐप इंस्टॉल है। Android Vitals → Launch time अनुभाग में, डिवाइस मॉडल और Android संस्करण के अनुसार Cold Start का मीडियन वितरण प्रदर्शित होता है। यह उपयोगकर्ता डिवाइसों पर वास्तविक मीट्रिक देखने का एकमात्र तरीका है, न कि केवल परीक्षण डिवाइसों पर। यदि Cold Start Redmi 9A (2 GB RAM) पर 5 सेकंड और Pixel 8 पर 1.2 सेकंड से अधिक है, तो समस्या मेमोरी आकार और क्लास गणना है। Google 25वें प्रतिशतक के आधार पर उपयोगकर्ता-बोधगम्य विलंब भी दिखाता है।

Macrobenchmark

Google Jetpack Macrobenchmark (androidx.benchmark लाइब्रेरी) इंस्ट्रूमेंटेड ऐप लॉन्च टेस्ट लिखने की अनुमति देता है। टेस्ट ऐप इंस्टॉल करता है, उसे कोल्ड स्टेट से लॉन्च करता है, और पहले फ्रेम तक का समय मापता है। Macrobenchmark स्वचालित रूप से 20 रन करता है, आउटलायर्स को हटाता है, और स्थिर प्रतिशतक दिखाता है। CI/CD के लिए, आप बेसलाइन और वर्तमान लॉन्च की तुलना कर सकते हैं — यदि समय बढ़ता है, तो CI पाइपलाइन विफल हो सकती है।

Cold Start को कैसे ऑप्टिमाइज़ करें

Cold Start को ऑप्टिमाइज़ करना एक व्यवस्थित कार्य है जो ऐप के कई स्तरों को प्रभावित करता है: कोड, संसाधन, बिल्ड कॉन्फ़िगरेशन, और इनिशियलाइज़ेशन आर्किटेक्चर। Google सबसे महंगे भाग — Application.onCreate — से शुरू करने और छोटे विवरणों की ओर बढ़ने की सिफारिश करता है।

लेज़ी इनिशियलाइज़ेशन (Lazy Init)

सभी इनिशियलाइज़ेशन जो स्टार्टअप पर आवश्यक नहीं है, Application.onCreate से पहले उपयोग बिंदु पर ले जाएं। Firebase, Crashlytics, analytics SDK, push-notifications, DI घटक — सब कुछ पहली स्क्रीन रेंडर होने के बाद इनिशियलाइज़ किया जा सकता है। Kotlin में Lazy (by lazy) या स्पष्ट initialize(context) कॉल के साथ ContentProvider इनिशियलाइज़ेशन का उपयोग करें। Google (Android Performance, 2023) के अनुसार, लेज़ी इनिशियलाइज़ेशन 5+ SDK का उपयोग करने वाले ऐप्स के लिए Cold Start को 40–60% कम करता है।

Baseline Profiles

Baseline Profiles ऐप स्टार्टअप पर उपयोग की जाने वाली महत्वपूर्ण क्लासेस और विधियों का AOT संकलन है। Baseline Profiles के बिना, ART DEX कोड की व्याख्या करता है या JIT के माध्यम से संकलित करता है, जिसमें समय लगता है। प्रोफ़ाइल के साथ, ART ऐप इंस्टॉलेशन के दौरान निर्दिष्ट विधियों को नेटिव कोड (AOT) में संकलित करता है। Google का दावा है कि Baseline Profiles Android 9+ पर Cold Start को 15–40% और Android 12+ ART ऑप्टिमाइज़ेशन के साथ 60% तक तेज़ करती हैं। प्रोफ़ाइल बनाने के लिए, androidx.benchmark:benchmark-baseline-profile-gradle-plugin प्लगइन का उपयोग करें।

App Startup Library

androidx.startup लाइब्रेरी घटक इनिशियलाइज़ेशन को क्रमबद्ध करने और इसे एक ContentProvider में निष्पादित करने की अनुमति देती है। विभिन्न लाइब्रेरीज़ के कई ContentProviders (प्रत्येक कोल्ड स्टार्ट में 1–2 ms जोड़ता है) के बजाय, App Startup उन्हें निर्भरता ग्राफ में मर्ज करता है और आवश्यकता के अनुसार सख्ती से इनिशियलाइज़ करता है। स्टार्टअप पर, केवल @Initializer से चिह्नित घटक जो पहली स्क्रीन के लिए आवश्यक हैं, निष्पादित होते हैं। बाकी के लिए, needEarlyInit = false फ़्लैग सेट किया जाता है — वे पहले रेंडर के बाद लॉन्च होते हैं।

// App Startup Initializer — स्टार्टअप के बाद इनिशियलाइज़ेशन
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// AndroidManifest.xml में वैकल्पिक के रूप में चिह्नित करें
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

DEX आकार कम करना

DEX फ़ाइल का आकार सीधे ART लोडिंग समय को प्रभावित करता है। ऑब्फ़स्केशन और मृत कोड हटाने के लिए R8/ProGuard का उपयोग करें (MinifyEnabled = true)। मेनिफ़ेस्ट में android:extractNativeLibs="false" सक्षम करें ताकि APK इंस्टॉलेशन पर .so फ़ाइलों को अनपैक न करे। 10+ रेफरेंस ट्रैकिंग वाली परियोजनाओं के लिए, केवल पहली स्क्रीन के लिए startup-priority जोड़ें। DEX में प्रत्येक अतिरिक्त विधि लोडिंग में 0.5–2 ms जोड़ती है, और 50k+ विधियों वाले ऐप्स के लिए (multidex के साथ primary dex) — 300 ms तक।

Android Vitals में Cold Start

Google Play Console में Android Vitals (Launch time अनुभाग) उन सभी डिवाइसों से डेटा एकत्र करता है जहां ऐप इंस्टॉल है, बशर्ते उपयोगकर्ता ने गुमनाम डायग्नोस्टिक्स के लिए सहमति दी हो। मीट्रिक Cold Start समय के आधार पर तीन श्रेणियों में विभाजित होते हैं: “अच्छा”, “मध्यम”, “खराब”।

Google सीमाएं

Google “खराब” Cold Start को किसी भी डिवाइस पर 5 सेकंड से अधिक समय के रूप में परिभाषित करता है। हालांकि, व्यवहार में, फ़्लैगशिप डिवाइसों (Snapdragon 8 Gen) के लिए, अच्छा समय 1.5 सेकंड से कम है, मिड-रेंज के लिए — 2.5 सेकंड से कम, बजट के लिए — 4 सेकंड से कम। Android Vitals प्रत्येक डिवाइस मॉडल के लिए मीडियन दिखाता है, जिससे यह समझने में मदद मिलती है कि किन डिवाइसों पर ऐप धीमा है। यदि Cold Start Samsung A-series या Xiaomi Redmi डिवाइसों पर खराब है, तो कारण अक्सर धीमी फ़्लैश मेमोरी और कम RAM है (Baseline Profiles के माध्यम से त्वरण ऐसे डिवाइसों पर सबसे अधिक प्रभाव देता है)।

Google Play मीट्रिक का उपयोग कैसे करता है

कंसोल में प्रदर्शित होने के अलावा, Cold Start मीट्रिक Google Play Search में ऐप गुणवत्ता रेटिंग को प्रभावित करता है। “खराब” स्टार्टअप के उच्च प्रतिशत वाले ऐप्स को इंस्टॉलेशन पेज पर “प्रदर्शन चेतावनी” लेबल मिलता है, जो रूपांतरण को कम करता है। Google (Android Performance Playbook, 2024) के अनुसार, Cold Start समस्याओं को हल करने वाले ऐप्स ने इंस्टॉलेशन रूपांतरण में औसतन 5% की वृद्धि और प्रतिधारण (D1) में 3–7% का सुधार किया।

Firebase Performance के साथ एकीकरण

अधिक विस्तृत निगरानी के लिए, Firebase Performance Monitoring का उपयोग करें। यह सत्र स्तर पर Cold Start को ट्रैक करता है, ऐप संस्करण और Android संस्करण के अनुसार विभाजित करता है। Android Vitals के विपरीत, Firebase चरण के अनुसार खर्च किए गए समय का ट्रेस आरेख दिखाता है। उदाहरण के लिए, आप देख सकते हैं कि संस्करण 3.2.0 पर, Application.onCreate में 800 ms लगे (एक नई पुश नोटिफिकेशन लाइब्रेरी के कारण), जबकि संस्करण 3.2.1 पर — 200 ms (फिक्स के बाद)।

ऑप्टिमाइज़ेशन के लिए कोड उदाहरण

नीचे दो व्यावहारिक उदाहरण दिए गए हैं जो सीधे Cold Start को तेज़ करते हैं: स्टार्टअप के बाद SDK इनिशियलाइज़ेशन को स्थानांतरित करना और SplashScreen API का उपयोग करना।

Application.onCreate से इनिशियलाइज़ेशन स्थानांतरित करना

एक सामान्य गलती सभी SDK को Application.onCreate में इनिशियलाइज़ करना है। नीचे दिखाया गया है कि गैर-महत्वपूर्ण इनिशियलाइज़ेशन को एक कोरूटीन में कैसे स्थानांतरित किया जाए जो पहले फ्रेम के ड्रॉ होने के बाद लॉन्च होता है। महत्वपूर्ण: Firebase, Crashlytics और Crash Reporting SDK को स्टार्टअप पर इनिशियलाइज़ किया जाना चाहिए — उन्हें स्थगित नहीं किया जा सकता क्योंकि वे अन्य घटकों के इनिशियलाइज़ेशन के दौरान क्रैश पकड़ते हैं। बाकी के लिए, पहली Activity में lifecycleScope का उपयोग करें।

// ❌ खराब — सारा इनिशियलाइज़ेशन Application.onCreate में
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // महत्वपूर्ण
        Analytics.init(this) // बाद में किया जा सकता है
        Database.init(this) // बाद में किया जा सकता है
        ImageLoader.init(this) // बाद में किया जा सकता है
    }
}

// ✅ अच्छा — Firebase स्टार्टअप पर, बाकी after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// पहले फ्रेम के बाद MainActivity में:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Android 12+ पर, आधिकारिक SplashScreen API का उपयोग करें जो प्रक्रिया शुरू होने पर तुरंत सिस्टम स्प्लैश (डार्क/लाइट बैकग्राउंड पर ऐप आइकन) दिखाता है। यह उपयोगकर्ता से इनिशियलाइज़ेशन समय छिपाता है — वे सफेद स्क्रीन के बजाय स्प्लैश देखते हैं। पुराने डिवाइसों के लिए, theme-based splash (स्टाइल में Theme.SplashScreen) का उपयोग करें। महत्वपूर्ण: स्प्लैश 300 ms से अधिक नहीं रहना चाहिए — यदि तब तक ऐप तैयार नहीं है, तो एक “स्थायी” कंकाल (shimmer) बनाएं और लोडिंग प्रगति दिखाएं।

// SplashScreen API — Android 12+
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val splashScreen = installSplashScreen()
        splashScreen.setKeepOnScreenCondition {
            isReady.value == false
        }
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

// थीम-आधारित स्प्लैश (Android 5-11)
// themes.xml में:
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/white</item>
//   <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
// </style>