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

मोबाइल ऐप्स में Hot Start क्या है

Hot Start एक लॉन्च परिदृश्य है जहाँ ऐप की प्रक्रिया पहले से ही डिवाइस की RAM में मौजूद होती है। उपयोगकर्ता ऐप को छोटा करता है, फिर वापस आता है — और सिस्टम एक नई प्रक्रिया नहीं बनाता बल्कि मौजूदा प्रक्रिया को फिर से शुरू करता है। इस परिदृश्य में, OS लोडिंग, Application क्लास इनिशियलाइज़ेशन, या प्रक्रिया निर्माण की आवश्यकता नहीं होती है, जो UI के स्क्रीन पर दिखने तक के समय को नाटकीय रूप से कम करता है। Android दस्तावेज़ीकरण (2025) के अनुसार, Hot Start केवल 200–500 मिलीसेकंड लेता है, जबकि Cold Start 5 सेकंड या उससे अधिक तक पहुँच सकता है। गति का अंतर विशेष रूप से सीमित मेमोरी वाले उपकरणों पर ध्यान देने योग्य है, जहाँ सिस्टम अधिक बार बैकग्राउंड ऐप्स को अनलोड करता है।

Hot Start की मुख्य विशेषता कॉल किए जाने वाले जीवनचक्र विधियों का न्यूनतम सेट है। Android में, ये Activity.onCreate और Activity.onStart हैं; iOS में, यह applicationDidBecomeActive है। Cold Start के विपरीत, जहाँ Application.onCreate, ContentProvider.onCreate, Activity.onCreate और कई लाइब्रेरी इनिशियलाइज़ेशन क्रमिक रूप से कॉल किए जाते हैं, Hot Start इन सभी चरणों को छोड़ देता है। डेवलपर को समझना चाहिए कि हॉट स्टार्ट के दौरान विशेष रूप से कौन सा कोड निष्पादित होता है — अक्सर भारी SDK इनिशियलाइज़ेशन, एनालिटिक्स और DI कंटेनर Cold और Hot Start दोनों पर दोहराए जाते हैं, भले ही हॉट स्टार्ट के दौरान उनकी अब आवश्यकता न हो।

Cold Start, Warm Start और Hot Start: तुलना

तीन ऐप लॉन्च परिदृश्य इनिशियलाइज़ेशन गहराई में भिन्न होते हैं। Cold Start तब होता है जब ऐप इंस्टॉलेशन, डिवाइस रीबूट, या मेमोरी से हटाए जाने के बाद पहली बार लॉन्च किया जाता है। सिस्टम एक नई Linux प्रक्रिया बनाता है, Application क्लासेस लोड करता है, ContentProvider इंस्टेंस बनाता है, लाइब्रेरी इनिशियलाइज़ेशन करता है, और उसके बाद ही Activity रेंडर करता है। ऐप की जटिलता और डिवाइस विशेषताओं के आधार पर पूरी प्रक्रिया में 2–10 सेकंड लगते हैं।

Warm Start एक मध्यवर्ती परिदृश्य है। ऐप प्रक्रिया मेमोरी में जीवित है, लेकिन Activity नष्ट हो गई है और इसे फिर से बनाया जाना चाहिए। यह, उदाहरण के लिए, स्क्रीन रोटेशन पर या किसी अन्य ऐप से लौटने पर होता है जहाँ मेमोरी दबाव के कारण Activity हटा दी गई थी लेकिन प्रक्रिया बनी रही। Warm Start में Activity.onCreate और Activity.onStart कॉल करना शामिल है, लेकिन इसमें Application.onCreate या ContentProvider इनिशियलाइज़ेशन शामिल नहीं है। Warm Start का समय 500 मिलीसेकंड से 2 सेकंड है। Hot Start तीनों में सबसे तेज़ है: Activity पहले से ही बैक स्टैक में मौजूद है, प्रक्रिया जीवित है, और सिस्टम बस Activity.onRestart, onStart और onResume कॉल करता है। Hot Start का समय 200–500 मिलीसेकंड है। Warm Start से अंतर यह है कि Activity नए सिरे से नहीं बनाई जाती — इसे मौजूदा इंस्टेंस से पुनर्स्थापित किया जाता है।

Hot Start के दौरान Android जीवनचक्र

Android में, Hot Start तब शुरू होता है जब उपयोगकर्ता हाल की स्क्रीन के माध्यम से या न्यूनतम होने पर ऐप आइकन टैप करके ऐप पर लौटता है। सिस्टम जाँचता है कि प्रक्रिया जीवित है या नहीं, और यदि हाँ, तो क्रमिक रूप से Activity.onRestart, onStart और onResume कॉल करता है। Hot Start के दौरान onCreate विधि कॉल नहीं की जाती क्योंकि Activity इंस्टेंस पहले से मेमोरी में मौजूद है। यह Warm Start से एक महत्वपूर्ण अंतर है, जहाँ Activity विनाश के कारण onCreate अभी भी कॉल किया जाता है। Google I/O 2019 के अनुसार, Android में सामान्य Hot Start समय 200–400 मिलीसेकंड है, और इस चरण में कोई भी मंदी सीधे कथित लॉन्च समय को बढ़ाती है।

डेवलपर अक्सर अनदेखा करते हैं कि UI इनिशियलाइज़ेशन कोड, LiveData सब्सक्रिप्शन, या RecyclerView सेटअप न केवल onCreate में बल्कि onStart या onResume में भी किए जाते हैं। Hot Start के दौरान, ये कोड ब्लॉक फिर से निष्पादित होते हैं, भले ही UI पहले से कॉन्फ़िगर किया गया हो। एक बार के इनिशियलाइज़ेशन (savedInstanceState जाँच के साथ onCreate में) और फिर से शुरू करने योग्य तर्क (onStart/onResume) को अलग करने की सिफारिश की जाती है। उदाहरण के लिए, भारी संचालन — एडेप्टर सेटअप, सूची लोडिंग — को एक ब्लॉक में ले जाया जाना चाहिए जो onRestart के दौरान निष्पादित नहीं होता, या savedInstanceState की जाँच करें।

लॉन्च प्रकार ट्रैक करने का उदाहरण

निम्नलिखित Kotlin कोड लॉन्च परिदृश्य का पता लगाने और समय मापने का एक सरल तरीका प्रदर्शित करता है। launchTimeStamp चर लॉन्च शुरू होने के क्षण को कैप्चर करता है, और isColdStart कोल्ड और हॉट स्टार्ट के लिए तर्क को अलग करने की अनुमति देता है।

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // एक बार का इनिशियलाइज़ेशन
        } else {
            isColdStart = false
            // Hot Start — Activity पुनर्स्थापित होती है
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

हॉट लॉन्च के दौरान iOS जीवनचक्र

iOS में, Hot Start sceneDidBecomeActive (UIKit) या onAppear (SwiftUI) के माध्यम से बैकग्राउंड से ऐप पर लौटने से मेल खाता है। यदि ऐप निलंबित या पृष्ठभूमि स्थिति में था तो ऑपरेटिंग सिस्टम प्रक्रिया को पुनर्निर्मित नहीं करता है। हॉट लॉन्च के दौरान, AppDelegate में applicationDidBecomeActive कॉल किया जाता है, लेकिन applicationDidFinishLaunching कॉल नहीं किया जाता — यह Android के समान है जहाँ Application.onCreate को छोड़ दिया जाता है। iOS अधिक आक्रामक रूप से ऐप्स को मेमोरी से हटाता है: यदि डिवाइस में RAM की कमी है, तो सिस्टम एक बैकग्राउंड ऐप को हटा सकता है, और अगला लॉन्च Cold Start होगा। Apple Developer दस्तावेज़ीकरण के अनुसार, iOS में औसत Hot Start समय 300–600 मिलीसेकंड है।

iOS में एक मुख्य अंतर Android अर्थ में Warm Start के प्रत्यक्ष एनालॉग की कमी है। iOS में, जब ऐप को छोटा किया जाता है, sceneDidEnterBackground कॉल किया जाता है, और वापसी पर, sceneWillEnterForeground और sceneDidBecomeActive कॉल किए जाते हैं। यदि सिस्टम दृश्य को हटा देता है लेकिन प्रक्रिया को जीवित रखता है, तो अगला लॉन्च दृश्य के दृष्टिकोण से कोल्ड होगा लेकिन प्रक्रिया के दृष्टिकोण से हॉट होगा। इनिशियलाइज़ेशन कोड रखते समय डेवलपर को इसे ध्यान में रखना चाहिए: NotificationCenter की सदस्यता, UI अपडेट और स्थिति रीसेट sceneDidBecomeActive में होने चाहिए, न कि केवल viewDidLoad में।

iOS में Hot Start को संभालने का उदाहरण

यह Swift कोड दिखाता है कि हॉट लॉन्च की संख्या को कैसे ट्रैक किया जाए और तर्क को कैसे अलग किया जाए। काउंटर foregroundCount बैकग्राउंड से प्रत्येक वापसी पर बढ़ता है।

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — पूर्ण इनिशियलाइज़ेशन
            setupSDKs()
        } else {
            // Hot Start — केवल UI अपडेट
            refreshUI()
        }
    }

    private func refreshUI() {
        // स्क्रीन पर डेटा अपडेट करना
    }
}

Hot Start गति को प्रभावित करने वाले कारक

कारकों की कई श्रेणियां Hot Start गति को प्रभावित करती हैं। पहली है onStart और onResume जीवनचक्र विधियों में काम की मात्रा। यदि डेवलपर ने इन विधियों में नेटवर्क डेटा लोडिंग, JSON पार्सिंग, एडेप्टर इनिशियलाइज़ेशन, या भारी गणनाएँ रखी हैं, तो ऐसा प्रत्येक ब्लॉक स्टार्टअप समय में दसियों या सैकड़ों मिलीसेकंड जोड़ता है। Android Vitals के अनुसार, 800 मिलीसेकंड से अधिक Hot Start अवधि वाले ऐप्स वापसी पर 20% तक उपयोगकर्ता खो देते हैं।

दूसरी श्रेणी savedInstanceState से पुनर्स्थापित किए गए फ़्रैगमेंट और व्यू हैं। यदि फ़्रैगमेंट में भारी ViewPager2, WebView, या जटिल गहराई से नेस्टेड पदानुक्रम हैं, तो उनकी पुनर्स्थापना CPU संसाधनों की खपत करती है। Google I/O 2023 के अनुसार, प्रत्येक नेस्टेड ViewGroup Hot Start के दौरान रेंडरिंग समय में औसतन 2–5 मिलीसेकंड जोड़ता है। तीसरी श्रेणी तृतीय-पक्ष SDK हैं: एनालिटिक्स लाइब्रेरी, क्रैश-रिपोर्टिंग टूल, A/B परीक्षण फ्रेमवर्क और DEX लोडर बैकग्राउंड से प्रत्येक वापसी पर इनिशियलाइज़ेशन कर सकते हैं। यह जाँचने की सिफारिश की जाती है कि कौन से SDK विशेष रूप से onStart/onResume में कोड चलाते हैं और गैर-महत्वपूर्ण कार्यों को बैकग्राउंड थ्रेड पर स्थगित करें।

हॉट लॉन्च अनुकूलन विधियाँ

Hot Start अनुकूलन फिर से शुरू करने वाले जीवनचक्र विधियों में काम को कम करने पर केंद्रित है। पहली विधि आलसी इनिशियलाइज़ेशन है: पहले UI फ्रेम के लिए आवश्यक नहीं होने वाला कोई भी कोड onResume के बाद Handler.postDelayed या Coroutine.launch(Dispatchers.IO) के माध्यम से देरी से चलना चाहिए। दूसरी विधि व्यू स्थिति कैशिंग है: जब ऐप छोटा किया जाता है, तो डेटा को इन-मेमोरी कैश में सहेजें ताकि Hot Start के दौरान आपको इसे डेटाबेस या नेटवर्क से पुनः लोड न करना पड़े। तीसरी विधि पुनर्स्थापित डेटा की मात्रा को कम करने के लिए Android में SavedStateHandle और iOS में StateRestorationPolicy का उपयोग करना है।

Hot Start के बाद आलसी लोडिंग

इस उदाहरण में, Handler.postDelayed पहले फ्रेम रेंडर होने के 500 मिलीसेकंड बाद एनालिटिक्स इनिशियलाइज़ेशन को स्थगित करता है। यह कथित लॉन्च समय को प्रभावित नहीं करता क्योंकि उपयोगकर्ता पहले से ही इंटरफ़ेस देख रहा है।

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // पहले फ्रेम के बाद इनिशियलाइज़ेशन
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

App Startup लाइब्रेरी का उपयोग

AndroidX App Startup आपको लॉन्च पर घटकों के इनिशियलाइज़ेशन क्रम को नियंत्रित करने की अनुमति देता है। सभी ContentProvider Cold Start के दौरान स्वचालित रूप से इनिशियलाइज़ होते हैं, लेकिन आप Hot Start के दौरान आवश्यक नहीं होने वाले घटकों के लिए स्वचालित इनिशियलाइज़ेशन अक्षम कर सकते हैं।

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

लॉन्च समय निगरानी उपकरण

Hot Start समय मापने के लिए, प्लेटफ़ॉर्म के अंतर्निहित उपकरण और तृतीय-पक्ष समाधान दोनों मौजूद हैं। Android में, मुख्य उपकरण Google Play Console में Android Vitals है — यह डिवाइस मॉडल और OS संस्करण के अनुसार विभाजित सभी परिदृश्यों (Cold, Warm, Hot) के लिए स्वचालित रूप से लॉन्च समय मीट्रिक्स एकत्र करता है। इसके अतिरिक्त, आप AndroidX से Macrobenchmark का उपयोग कर सकते हैं — स्वचालित स्टार्टअप प्रदर्शन परीक्षण के लिए एक लाइब्रेरी। iOS में, समतुल्य MetricKit है, जो लॉन्च समय, फ्रेम दर और मेमोरी उपयोग पर डेटा एकत्र करता है।

विस्तृत हॉट स्टार्ट प्रोफाइलिंग के लिए, Firebase Performance Monitoring (कस्टम ट्रेस ट्रैक करता है) और लॉन्च समय डैशबोर्ड के साथ New Relic उपयुक्त हैं। मैन्युअल माप के लिए डेवलपर की ओर से, Android में reportFullyDrawn का उपयोग किया जाता है — एक API जो सिस्टम को सटीक क्षण बताता है जब UI रेंडर हो जाता है और इंटरैक्शन के लिए तैयार होता है। iOS में, समतुल्य MetricKit में endActivity है। इन उपकरणों को संयोजित करके, आप पहचान सकते हैं कि कौन सा SDK या कोड ब्लॉक विशिष्ट उपकरणों पर Hot Start को धीमा करता है।

Hot Start के लिए Macrobenchmark उदाहरण

Macrobenchmark लाइब्रेरी का उपयोग करके Kotlin कोड Cold और Hot Start मापने के लिए। परीक्षण Activity लॉन्च करता है और पूर्ण स्थिति तक के समय को मापता है।

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}