Cold Start — ουσία, ψυχρή εκκίνηση και βελτιστοποίηση στο Android

Τι είναι το Cold Start

Cold Start (ψυχρή εκκίνηση) είναι ένα σενάριο κατά το οποίο η εφαρμογή Android ξεκινά από την πιο αρχική κατάσταση: το λειτουργικό σύστημα δημιουργεί μια νέα διεργασία (fork από το Zygote), δεσμεύει μνήμη, φορτώνει τον κώδικα 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 report, 2023), το 65% των χρηστών κλείνει την εφαρμογή εάν δεν ανοίξει μέσα σε 3 δευτερόλεπτα. Για τα κοινωνικά δίκτυα και τους αγγελιοφόρους, όπου ο χρήστης επιστρέφει δεκάδες φορές την ημέρα, το Cold Start επηρεάζει άμεσα τη διατήρηση. Στην κονσόλα Google Play, η μετρική Cold Start περιλαμβάνεται στην ενότητα Android Vitals και εμφανίζεται ως ένας από τους δείκτες ANR και απόδοσης. Μια εφαρμογή που υπερβαίνει το όριο "κακού" Cold Start (πάνω από 5 δευτερόλεπτα στο 25% των συσκευών) λαμβάνει προειδοποίηση στην κονσόλα και μπορεί να υποβαθμιστεί στην αναζήτηση.

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 αποθηκεύει προσωρινά μεταγλωττισμένες εικόνες κλάσεων (Image in Boot Profile) και η επαναφόρτωση DEX γίνεται ταχύτερη. Επομένως, η δεύτερη εκκίνηση μετά το πρώτο Cold Start είναι συνήθως 20–40% ταχύτερη. Εάν η εφαρμογή χρησιμοποιεί Baseline Profiles, τα προφίλ φορτώνονται κατά την πρώτη εκκίνηση και η δεύτερη εκκίνηση μπορεί να είναι ακόμα ταχύτερη: το Google Play, που δημοσίευσε τα Baseline Profiles, επιτάχυνε το Cold Start κατά 30% σε συσκευές με Android 12+.

Φάσεις ψυχρής εκκίνησης

Το Cold Start αποτελείται από αυστηρά καθορισμένες φάσεις, καθεμία από τις οποίες μπορεί να μετρηθεί και να βελτιστοποιηθεί ανεξάρτητα. Η γνώση των φάσεων βοηθά να προσδιοριστεί σε ποιο στάδιο η εφαρμογή χάνει χρόνο. Η Google διακρίνει τέσσερις κύριες φάσεις: δημιουργία διεργασίας, αρχικοποίηση Application, δημιουργία Activity και πρώτο καρέ.

Φάση 1: Δημιουργία διεργασίας (fork)

Το σύστημα Android (ActivityManagerService) δημιουργεί μια νέα διεργασία μέσω fork από τη διεργασία Zygote. Το Zygote είναι μια προφορτωμένη διεργασία με κοινές κλάσεις Android. Το fork εκτελείται σε 30–80 ms — αυτός είναι χρόνος που η εφαρμογή δεν μπορεί να ελέγξει. Μετά το fork, ξεκινά το ActivityThread — το στιγμιότυπο του κύριου βρόχου της εφαρμογής. Σε αυτό το στάδιο γίνεται επίσης φόρτωση κλάσεων μέσω ClassLoader, και το ART αρχίζει να ερμηνεύει τον πρώτο bytecode. Εάν η εφαρμογή χρησιμοποιεί πολλούς στατικούς αρχικοποιητές, αυτή η φάση μπορεί να παραταθεί.

Φάση 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, ξεκινά η πρώτη απόδοση: measure, layout, draw. Αυτή η στιγμή ονομάζεται TTFD (Time To First Draw). Εάν η εφαρμογή χρησιμοποιεί οθόνη εκκίνησης (μέσω SplashScreen API σε Android 12+ ή μέσω θέματος), η απόδοση μπορεί να γίνει ταχύτερα, αλλά ο χρήστης θα περιμένει μέχρι να εξαφανιστεί το splash. Το ιδανικό TTFD για Cold Start είναι λιγότερο από 1,5 δευτερόλεπτο.

Πώς να μετρήσετε το Cold Start

Η μέτρηση του Cold Start απαιτεί ειδικά εργαλεία, καθώς η συνηθισμένη καταγραφή (Log.d) αρχίζει να λειτουργεί μόνο μετά τη δημιουργία του Application, και ο χρονισμός του fork και της φόρτωσης κλάσεων παραμένει μη προσβάσιμος. Η Google συνιστά τρεις μεθόδους: εντολές ADB, Android Vitals και προσαρμοσμένα μακροεντολές perf.

Μέτρηση μέσω ADB

Ο απλούστερος και αναπαραγώγιμος τρόπος είναι η εντολή adb shell am start -S -W. Η σημαία -S σταματά αναγκαστικά την εφαρμογή πριν από την εκκίνηση (εγγυάται Cold Start). Η εντολή εξάγει τρεις μετρήσεις: ThisTime (χρόνος εκκίνησης Activity), TotalTime (συνολικός χρόνος συμπεριλαμβανομένης της εκκίνησης διεργασίας) και WaitTime (χρόνος συμπεριλαμβανομένων όλων των καθυστερήσεων του Activity Manager). Καθαρά μεγέθη: κάντε 5–7 μετρήσεις και πάρτε τη διάμεσο — οι μεμονωμένες μετρήσεις υπόκεινται σε θόρυβο (CPU throttling, φόρτο παρασκηνίου).

# Εξαναγκασμένο 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 συλλέγει ανώνυμες μετρικές από όλες τις συσκευές όπου είναι εγκατεστημένη η εφαρμογή. Στην ενότητα Android Vitals → Launch time, εμφανίζεται η διάμεση κατανομή του Cold Start ανά μοντέλο συσκευής και έκδοση Android. Αυτός είναι ο μόνος τρόπος να δείτε πραγματικές ενδείξεις στις συσκευές των χρηστών, όχι σε δοκιμαστικές συσκευές. Εάν στο Redmi 9A (2 GB RAM) το Cold Start υπερβαίνει τα 5 δευτερόλεπτα, και στο Pixel 8 — 1,2 δευτερόλεπτο, το πρόβλημα είναι στη χωρητικότητα μνήμης και στον αριθμό των κλάσεων. Η Google εμφανίζει επίσης την αντιληπτή καθυστέρηση χρήστη (user-perceptible delay) βάσει του 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 ειδοποιήσεις, στοιχεία DI — όλα μπορούν να αρχικοποιηθούν μετά την απόδοση της πρώτης οθόνης. Χρησιμοποιήστε Lazy (by lazy) σε Kotlin ή αρχικοποίηση ContentProvider με ρητή κλήση initialize(context). Σύμφωνα με την Google (Android Performance, 2023), η τεμπέλικη αρχικοποίηση μειώνει το Cold Start κατά 40–60% για εφαρμογές που χρησιμοποιούν 5+ SDK.

Baseline Profiles

Baseline Profiles είναι η μεταγλώττιση AOT κρίσιμων κλάσεων και μεθόδων που χρησιμοποιούνται κατά την εκκίνηση της εφαρμογής. Χωρίς Baseline Profiles, το ART ερμηνεύει τον κώδικα DEX ή τον μεταγλωττίζει με JIT, κάτι που παίρνει χρόνο. Με προφίλ, το ART μεταγλωττίζει τις καθορισμένες μεθόδους σε εγγενή κώδικα (AOT) κατά την εγκατάσταση της εφαρμογής. Η Google υποστηρίζει ότι τα Baseline Profiles επιταχύνουν το Cold Start κατά 15–40% σε Android 9+ και έως 60% με βελτιστοποιήσεις ART Android 12+. Για τη δημιουργία προφίλ, χρησιμοποιήστε το πρόσθετο androidx.benchmark:benchmark-baseline-profile-gradle-plugin.

App Startup Library

Η βιβλιοθήκη androidx.startup επιτρέπει την οργάνωση της αρχικοποίησης στοιχείων και την εκτέλεσή της σε ένα ContentProvider. Αντί για πολλαπλά ContentProvider από διαφορετικές βιβλιοθήκες (το καθένα προσθέτει 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 κλάσεις Reference Tracking, προσθέστε startup-priority μόνο για την πρώτη οθόνη. Κάθε επιπλέον μέθοδος στο DEX προσθέτει 0,5–2 ms στη φόρτωση, και για εφαρμογές με 50k+ μεθόδους (multidex με primary dex) — έως 300 ms.

Cold Start στο Android Vitals

Το Android Vitals στην κονσόλα Google Play (ενότητα Launch time) συλλέγει δεδομένα από όλες τις συσκευές όπου είναι εγκατεστημένη η εφαρμογή, υπό την προϋπόθεση ότι ο χρήστης συναίνεσε σε ανώνυμη διάγνωση. Οι μετρικές χωρίζονται σε τρεις κατηγορίες: "good" (καλό), "moderate" (μέτριο), "bad" (κακό), ανάλογα με τον χρόνο Cold Start.

Τιμές ορίου Google

Η Google ορίζει το "bad" Cold Start ως χρόνο που υπερβαίνει τα 5 δευτερόλεπτα σε οποιαδήποτε συσκευή. Στην πράξη, για συσκευές ναυαρχίδες (Snapdragon 8 Gen), ο καλός χρόνος είναι λιγότερο από 1,5 δευτερόλεπτο, για μεσαία κατηγορία — λιγότερο από 2,5 δευτερόλεπτα, για οικονομικές — λιγότερο από 4 δευτερόλεπτα. Το Android Vitals εμφανίζει τη διάμεσο ανά device model, επιτρέποντας να κατανοήσετε σε ποιες συσκευές η εφαρμογή εκκινεί αργά. Εάν το Cold Start είναι κακό σε συσκευές Samsung A-series ή Xiaomi Redmi, η αιτία είναι συνήθως η αδύναμη μνήμη flash και η χαμηλή RAM (η επιτάχυνση μέσω Baseline Profiles δίνει το μεγαλύτερο αποτέλεσμα ακριβώς σε τέτοιες συσκευές).

Πώς χρησιμοποιεί το Google Play τη μετρική

Εκτός από την εμφάνιση στην κονσόλα, η μετρική Cold Start επηρεάζει την αξιολόγηση ποιότητας της εφαρμογής στην αναζήτηση Google Play. Οι εφαρμογές με υψηλό ποσοστό "κακών" εκκινήσεων λαμβάνουν ετικέτα "Performance warning" στη σελίδα εγκατάστασης, η οποία μειώνει τη μετατροπή. Σύμφωνα με την 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 (λόγω νέας βιβλιοθήκης push ειδοποιήσεων), και στην έκδοση 3.2.1 — 200 ms (μετά τη διόρθωση).

Παραδείγματα κώδικα για βελτιστοποίηση

Ακολουθούν δύο πρακτικά παραδείγματα που επιταχύνουν άμεσα το Cold Start: μεταφορά αρχικοποίησης SDK μετά την εκκίνηση και χρήση SplashScreen API.

Μεταφορά αρχικοποίησης από το Application.onCreate

Τυπικό λάθος είναι η αρχικοποίηση όλων των SDK στο Application.onCreate. Παρακάτω φαίνεται πώς να μεταφέρετε μη κρίσιμες αρχικοποιήσεις σε ένα coroutine που ξεκινά μετά την απόδοση του πρώτου καρέ. Σημαντικό: τα Firebase, Crashlytics και Crash Reporting SDK πρέπει να αρχικοποιηθούν κατά την εκκίνηση — δεν μπορούν να αναβληθούν επειδή πιάνουν σφάλματα κατά την αρχικοποίηση άλλων στοιχείων. Για τα υπόλοιπα, χρησιμοποιήστε lifecycleScope στο πρώτο Activity.

// ❌ Κακό — όλη η αρχικοποίηση στο 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, το οποίο εμφανίζει system-splash (εικονίδιο εφαρμογής σε σκοτεινό/φωτεινό φόντο) αμέσως κατά την εκκίνηση της διεργασίας. Αυτό κρύβει τον χρόνο αρχικοποίησης από τον χρήστη — βλέπει splash, όχι λευκή οθόνη. Για παλαιότερες συσκευές, χρησιμοποιήστε theme-based splash (Theme.SplashScreen στα στυλ). Σημαντικό: το splash δεν πρέπει να διαρκεί περισσότερο από 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)
    }
}

// Theme-based splash (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>