Hot Start σε εφαρμογές κινητών: τι είναι, παράγοντες και πώς να επιταχύνετε

Τι είναι το Hot Start σε εφαρμογές κινητών

Hot Start — είναι ένα σενάριο εκκίνησης εφαρμογής όπου η διεργασία της υπάρχει ήδη στη μνήμη RAM της συσκευής. Ο χρήστης ελαχιστοποιεί την εφαρμογή, στη συνέχεια επιστρέφει — και το σύστημα δεν δημιουργεί νέα διεργασία, αλλά συνεχίζει μια υπάρχουσα. Σε αυτό το σενάριο δεν απαιτείται φόρτωση του λειτουργικού συστήματος, αρχικοποίηση της κλάσης Application και δημιουργία διεργασίας, γεγονός που μειώνει δραστικά τον χρόνο έως την εμφάνιση του UI στην οθόνη. Σύμφωνα με την τεκμηρίωση Android (2025), το Hot Start διαρκεί μόλις 200–500 ms, ενώ το Cold Start μπορεί να φτάσει τα 5 δευτερόλεπτα ή περισσότερο. Η διαφορά στην ταχύτητα είναι ιδιαίτερα αισθητή σε συσκευές με περιορισμένη μνήμη, όπου το σύστημα εκφορτώνει συχνότερα εφαρμογές παρασκηνίου.

Το κύριο χαρακτηριστικό του Hot Start — το ελάχιστο σύνολο μεθόδων lifecycle που καλούνται. Στο 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 ms έως 2 δευτερόλεπτα. Hot Start — το ταχύτερο από τα τρία: το Activity υπάρχει ήδη στη στοίβα επιστροφής, η διεργασία είναι ζωντανή και το σύστημα απλώς καλεί τα Activity.onRestart, onStart και onResume. Ο χρόνος Hot Start — 200–500 ms. Η διαφορά από το Warm Start είναι ότι το Activity δεν δημιουργείται εκ νέου — αποκαθίσταται από ένα υπάρχον στιγμιότυπο.

Android Lifecycle κατά το Hot Start

Στο Android το Hot Start ξεκινά όταν ο χρήστης επιστρέφει στην εφαρμογή μέσω της οθόνης Recents ή κάνοντας κλικ στο εικονίδιο σε ελαχιστοποιημένη κατάσταση. Το σύστημα ελέγχει αν η διεργασία είναι ζωντανή, και αν ναι — καλεί διαδοχικά τα Activity.onRestart, onStart και onResume. Η μέθοδος onCreate δεν καλείται κατά το Hot Start, επειδή το στιγμιότυπο Activity υπάρχει ήδη στη μνήμη. Αυτή είναι μια σημαντική διαφορά από το Warm Start, όπου το onCreate εξακολουθεί να καλείται λόγω της καταστροφής του Activity. Σύμφωνα με το Google I/O 2019, ο τυπικός χρόνος Hot Start στο Android είναι 200–400 ms, και οποιαδήποτε επιβράδυνση σε αυτό το στάδιο αυξάνει άμεσα τον αντιληπτό χρόνο εκκίνησης.

Οι προγραμματιστές συχνά δεν παρατηρούν ότι ο κώδικας αρχικοποίησης UI, εγγραφής στο LiveData ή ρύθμισης RecyclerView εκτελείται όχι μόνο στο onCreate, αλλά και στο onStart ή onResume. Κατά το Hot Start αυτά τα μπλοκ κώδικα εκτελούνται ξανά, παρόλο που το UI έχει ήδη ρυθμιστεί. Συνιστάται ο διαχωρισμός της εφάπαξ αρχικοποίησης (στο onCreate με έλεγχο savedInstanceState) και της επαναλαμβανόμενης λογικής (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 Lifecycle κατά τη θερμή εκκίνηση

Στο iOS το Hot Start αντιστοιχεί στην επιστροφή της εφαρμογής από το παρασκήνιο μέσω sceneDidBecomeActive (UIKit) ή onAppear (SwiftUI). Το λειτουργικό σύστημα δεν δημιουργεί ξανά τη διεργασία αν η εφαρμογή ήταν σε κατάσταση Suspended ή Background. Κατά τη θερμή εκκίνηση καλείται το applicationDidBecomeActive στο AppDelegate, αλλά δεν καλείται το applicationDidFinishLaunching — αυτό είναι ανάλογο με το Android, όπου το Application.onCreate παραλείπεται. Το iOS εκφορτώνει πιο επιθετικά τις εφαρμογές από τη μνήμη: αν η συσκευή δεν έχει αρκετή RAM, το σύστημα μπορεί να εκφορτώσει την εφαρμογή παρασκηνίου, και τότε η επόμενη εκκίνηση θα είναι Cold Start. Σύμφωνα με την τεκμηρίωση Apple Developer, ο μέσος χρόνος Hot Start στο iOS είναι 300–600 ms.

Η βασική διαφορά του iOS — η απουσία άμεσου αναλόγου του Warm Start με την έννοια του Android. Στο iOS κατά την ελαχιστοποίηση της εφαρμογής καλείται το sceneDidEnterBackground, και κατά την επιστροφή — sceneWillEnterForeground και sceneDidBecomeActive. Αν το σύστημα εκφορτώσει τη σκηνή αλλά αφήσει τη διεργασία ζωντανή, η επόμενη εκκίνηση θα είναι Cold από την άποψη της σκηνής, αλλά Hot από την άποψη της διεργασίας. Ο προγραμματιστής πρέπει να το λαμβάνει υπόψη κατά την τοποθέτηση κώδικα αρχικοποίησης: η εγγραφή στο NotificationCenter, η ενημέρωση UI και η επαναφορά καταστάσεων πρέπει να γίνονται ακριβώς στο sceneDidBecomeActive, όχι μόνο στο viewDidLoad.

Παράδειγμα χειρισμού Hot Start στο iOS

Αυτός ο κώδικας σε 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 επηρεάζουν διάφορες κατηγορίες παραγόντων. Πρώτη — ο όγκος εργασίας στις μεθόδους lifecycle onStart και onResume. Αν ο προγραμματιστής έχει τοποθετήσει σε αυτές τις μεθόδους φόρτωση δεδομένων από το δίκτυο, ανάλυση JSON, αρχικοποίηση προσαρμογέων ή βαριούς υπολογισμούς, κάθε τέτοιο μπλοκ προσθέτει δεκάδες και εκατοντάδες χιλιοστά του δευτερολέπτου στον χρόνο εκκίνησης. Σύμφωνα με δεδομένα του εργαλείου Android Vitals, εφαρμογές με διάρκεια Hot Start μεγαλύτερη από 800 ms χάνουν έως και 20% των χρηστών κατά την επαναλαμβανόμενη επιστροφή.

Δεύτερη κατηγορία — τμήματα και Views που αποκαθίστανται από το savedInstanceState. Αν τα τμήματα περιέχουν βαριά ViewPager2, WebView ή σύνθετες ιεραρχίες με βαθιά φωλιάσματα, η αποκατάστασή τους καταναλώνει πόρους CPU. Σύμφωνα με το Google I/O 2023, κάθε ένθετο ViewGroup προσθέτει κατά μέσο όρο 2–5 ms στον χρόνο απόδοσης κατά το Hot Start. Τρίτη κατηγορία — SDK τρίτων: βιβλιοθήκες αναλυτικών στοιχείων, crash-reporting, A/B-testing και φορτωτές DEX μπορεί να εκτελούν αρχικοποίηση σε κάθε επιστροφή από το παρασκήνιο. Συνιστάται να ελέγχετε ποια SDK εκτελούν κώδικα ακριβώς στα onStart/onResume, και να αναβάλλετε μη κρίσιμες εργασίες σε ένα νήμα παρασκηνίου.

Μέθοδοι βελτιστοποίησης της θερμής εκκίνησης

Η βελτιστοποίηση του Hot Start συνοψίζεται στην ελαχιστοποίηση της εργασίας στις μεθόδους lifecycle συνέχισης. Πρώτη μέθοδος — τεμπέλικη αρχικοποίηση: όλος ο κώδικας που δεν χρειάζεται για το πρώτο καρέ UI πρέπει να εκτελείται μετά την κλήση του onResume με καθυστέρηση μέσω Handler.postDelayed ή Coroutine.launch(Dispatchers.IO). Δεύτερη μέθοδος — προσωρινή αποθήκευση κατάστασης View: κατά την ελαχιστοποίηση της εφαρμογής αποθηκεύστε δεδομένα σε προσωρινή μνήμη, ώστε κατά το Hot Start να μην χρειάζεται να τα φορτώνετε ξανά από τη βάση δεδομένων ή το δίκτυο. Τρίτη μέθοδος — χρήση του SavedStateHandle στο Android και του StateRestorationPolicy στο iOS για ελαχιστοποίηση του όγκου των δεδομένων που αποκαθίστανται.

Τεμπέλικη φόρτωση μετά το Hot Start

Σε αυτό το παράδειγμα, το Handler.postDelayed καθυστερεί την αρχικοποίηση των αναλυτικών στοιχείων κατά 500 ms μετά την απόδοση του πρώτου καρέ. Αυτό δεν επηρεάζει τον αντιληπτό χρόνο εκκίνησης, καθώς ο χρήστης βλέπει ήδη τη διεπαφή.

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 το βασικό εργαλείο είναι το Android Vitals στην κονσόλα Google Play — συλλέγει αυτόματα μετρήσεις χρόνου εκκίνησης για όλα τα σενάρια (Cold, Warm, Hot) με ανάλυση ανά μοντέλο συσκευής και έκδοση OS. Επιπλέον, μπορεί να χρησιμοποιηθεί το Macrobenchmark από το AndroidX — μια βιβλιοθήκη για αυτοματοποιημένο έλεγχο απόδοσης εκκίνησης. Στο iOS το αντίστοιχο είναι το MetricKit, το οποίο συλλέγει δεδομένα σχετικά με τον χρόνο εκκίνησης, τη συχνότητα καρέ και τη χρήση μνήμης.

Για λεπτομερή προφίλ της θερμής εκκίνησης είναι κατάλληλα τα Firebase Performance Monitoring (παρακολουθεί custom traces) και New Relic με πίνακες ελέγχου χρόνου εκκίνησης. Από την πλευρά του προγραμματιστή για χειροκίνητη μέτρηση χρησιμοποιείται το reportFullyDrawn στο Android — ένα API που ενημερώνει το σύστημα για την ακριβή στιγμή που το UI έχει αποδοθεί και είναι έτοιμο για αλληλεπίδραση. Στο iOS το αντίστοιχο είναι το endActivity στο MetricKit. Συνδυάζοντας αυτά τα εργαλεία, μπορείτε να εντοπίσετε ποιο SDK ή μπλοκ κώδικα επιβραδύνει το Hot Start σε συγκεκριμένες συσκευές.

Παράδειγμα Macrobenchmark για Hot Start

Κώδικας σε Kotlin χρησιμοποιώντας τη βιβλιοθήκη Macrobenchmark για μέτρηση Cold και Hot Start. Η δοκιμή εκκινεί το Activity και μετρά τον χρόνο έως την κατάσταση complete.

@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()
        }
    }
}