Firebase Performance: τι είναι, μετρήσεις και πώς να παρακολουθείτε

Τι είναι το Firebase Performance Monitoring

Firebase Performance Monitoring είναι ένα SDK και πλατφόρμα νέφους για συλλογή, συγκέντρωση και οπτικοποίηση μετρήσεων απόδοσης εφαρμογών κινητών. Το SDK ενσωματώνεται στην εφαρμογή και αυτόματα εργαλειοποιεί βασικά σημεία: τον κύκλο ζωής Activity (Android) ή ViewController (iOS), αιτήματα δικτύου μέσω URLSession (iOS) ή OkHttp (Android) και κλήσεις συστήματος. Τα συλλεγμένα δεδομένα αποστέλλονται στον διακομιστή Firebase, όπου συγκεντρώνονται ανά έκδοση εφαρμογής, συσκευή, χώρα και άλλα χαρακτηριστικά.

Η αρχιτεκτονική του Performance SDK βασίζεται στην αρχή του ελάχιστου φόρτου: η εργαλειοποίηση προσθέτει όχι περισσότερο από 1–2% στον χρόνο εκτέλεσης των μετρούμενων λειτουργιών. Τα δεδομένα συλλέγονται ασύγχρονα και αποθηκεύονται προσωρινά στη συσκευή πριν από την αποστολή, εξαλείφοντας την επίδραση στην απόδοση του νήματος UI. Η αποστολή δεδομένων γίνεται σύμφωνα με το χρονοδιάγραμμα (από προεπιλογή κάθε 30 λεπτά) ή όταν επιτευχθεί το προσωρινό μέγεθος των 100 KB.

Η βασική διαφορά του Firebase Performance από τους προφίλερ Android Studio (CPU Profiler) ή Xcode Instruments είναι η παρακολούθηση παραγωγής. Το Firebase Performance συλλέγει δεδομένα από πραγματικές συσκευές χρηστών, όχι μόνο από συσκευές προγραμματιστών. Αυτό επιτρέπει τον εντοπισμό προβλημάτων που εμφανίζονται μόνο σε συγκεκριμένα μοντέλα, εκδόσεις OS ή σε συγκεκριμένες περιοχές — δηλαδή προβλήματα που δεν μπορούν να αναπαραχθούν σε ελεγχόμενο περιβάλλον.

Πώς το SDK συλλέγει δεδομένα χωρίς αλλαγή κώδικα

Αυτόματη εργαλειοποίηση είναι το κύριο χαρακτηριστικό του Firebase Performance. Για Android, το SDK καταγράφει αυτόματα ActivityLifecycleCallbacks και μετρά τον χρόνο μεταξύ onCreate και onResume (χρόνος απόδοσης οθόνης). Για iOS — κάνει swizzle στις μεθόδους viewDidLoad και viewDidAppear. Τα αιτήματα δικτύου παρεμποδίζονται σε επίπεδο OkHttpInterceptor (Android) ή NSURLProtocol (iOS). Ο προγραμματιστής δεν χρειάζεται να προσθέσει κλήσεις start/stop για τυπικές μετρήσεις.

Ενεργοποίηση και απενεργοποίηση του Performance SDK διαχειρίζεται μέσω του πρόσθετου Google Services (Android) ή του Info.plist (iOS). Για εντοπισμό σφαλμάτων, μπορεί να ενεργοποιηθεί η λεπτομερής καταγραφή του Performance SDK, η οποία θα δείξει ποιες μετρήσεις συλλέγονται και αποστέλλονται. Στην παραγωγή συνιστάται η διατήρηση της καταγραφής σε επίπεδο warning για να μην γεμίζουν τα αρχεία καταγραφής με περιττές πληροφορίες. Για έργα σε Flutter ή React Native, η αυτόματη εργαλειοποίηση μπορεί να είναι περιορισμένη — περισσότερες λεπτομέρειες στην ενότητα παραδειγμάτων κώδικα.

Δωρεάν όρια και χρέωση

Το Firebase Performance προσφέρεται στο δωρεάν πακέτο Spark χωρίς περιορισμούς στον αριθμό ιχνών ή τον όγκο δεδομένων. Το πληρωμένο πακέτο Blaze επίσης δεν χρεώνει για το Performance Monitoring — είναι μία από τις λίγες υπηρεσίες Firebase εντελώς δωρεάν και στα δύο πακέτα. Υπάρχει μόνο ένας περιορισμός: τα δεδομένα αποθηκεύονται για 30 ημέρες (στο Spark) και έως 365 ημέρες (στο Blaze). Για μακροπρόθεσμη ανάλυση, εξάγετε δεδομένα μέσω BigQuery export.

Η έλλειψη χρέωσης καθιστά το Firebase Performance ιδανική επιλογή για κάθε έργο — από πρωτότυπο έως εφαρμογή επιχειρηματικού επιπέδου με εκατομμύρια χρήστες. Το μοναδικό στοιχείο κόστους είναι η εξερχόμενη κίνηση δεδομένων του Performance SDK, αλλά είναι αμελητέα σε σύγκριση με άλλες λειτουργίες δικτύου της εφαρμογής (λιγότερο από 1 MB ανά μήνα ανά συσκευή). Στο BigQuery export υπάρχουν χρεώσεις για αποθήκευση και ερωτήματα, αλλά το ίδιο το Performance SDK είναι δωρεάν.

Αυτόματες μετρήσεις: τι μετριέται χωρίς κώδικα

Το Firebase Performance συλλέγει αυτόματα πέντε κατηγορίες μετρήσεων χωρίς ούτε μία γραμμή κώδικα: χρόνος εκκίνησης εφαρμογής (app start), αργά αιτήματα (slow HTTP requests), ταχύτητα απόδοσης οθόνης (screen rendering), χρήση μνήμης (memory usage, μόνο Android) και ρυθμός καρέ (frame rate, μόνο Android). Αυτές οι μετρήσεις είναι διαθέσιμες στην κονσόλα Firebase αμέσως μετά τη σύνδεση του SDK και την πρώτη συνεδρία χρήστη.

App Start Time — χρόνος από την έναρξη της διεργασίας έως την πλήρη ετοιμότητα του UI για αλληλεπίδραση. Διακρίνεται σε ψυχρή εκκίνηση (η εφαρμογή ξεκινά από το μηδέν) και θερμή εκκίνηση (η εφαρμογή επαναφέρεται από κατάσταση παρασκηνίου). Η ψυχρή εκκίνηση περιλαμβάνει φόρτωση αρχείων DEX, αρχικοποίηση στατικών πεδίων, κλήση Application.onCreate και Activity.onCreate. Το Firebase ταξινομεί αυτόματα τον τύπο εκκίνησης και εμφανίζει την κατανομή χρόνου για κάθε τύπο.

Screen Rendering Time — χρόνος από την έναρξη φόρτωσης οθόνης (onCreate για Android, viewDidLoad για iOS) έως ότου η οθόνη είναι έτοιμη για αλληλεπίδραση (onResume, viewDidAppear). Το Firebase συγκεντρώνει δεδομένα για κάθε οθόνη (ανά όνομα κλάσης ή προσαρμοσμένο όνομα οθόνης), επιτρέποντας τον προσδιορισμό της πιο αργής οθόνης. Για Android μετριούνται επιπλέον τα dropped frames — ο αριθμός καρέ που παραλείπονται κατά την απόδοση οθόνης (jank).

Αιτήματα δικτύου (HTTP/HTTPS)

Το Performance SDK παρεμποδίζει και μετρά αυτόματα κάθε αίτημα HTTP/HTTPS που αποστέλλεται από την εφαρμογή μέσω URLSession, OkHttp ή URLConnection. Για κάθε αίτημα καταγράφονται: URL (διαδρομή χωρίς παραμέτρους ερωτήματος για ασφάλεια), μέθοδος HTTP, κωδικός απόκρισης, μέγεθος απόκρισης σε byte, διάρκεια αιτήματος και ταχύτητα σύνδεσης (WiFi, Cellular). Τα δεδομένα συγκεντρώνονται στον πίνακα ελέγχου „Network Requests” της κονσόλας Firebase.

Slow Requests — αιτήματα των οποίων η διάρκεια υπερβαίνει το καθορισμένο όριο. Το προεπιλεγμένο όριο για “αργό αίτημα” είναι 4000 ms. Αυτή η μέτρηση είναι κρίσιμη για τον εντοπισμό προβλημάτων με την πλευρά του διακομιστή: εάν μετά από ενημέρωση του backend ο αριθμός των αργών αιτημάτων αυξηθεί από 1% σε 15%, αυτό είναι σήμα για άμεση ανάλυση των αρχείων καταγραφής του διακομιστή. Οι χρήστες δεν θα περιμένουν απάντηση για περισσότερο από 5 δευτερόλεπτα — τα δεδομένα Firebase δείχνουν ότι το 53% των χρηστών κλείνει την εφαρμογή εάν ένα αίτημα διαρκέσει περισσότερο από 3 δευτερόλεπτα.

Περιορισμοί αυτόματης εργαλειοποίησης

Περιορισμοί iOS: στο iOS, το Performance SDK δεν μπορεί να μετρήσει dropped frames (αυτό είναι ιδιωτικό API). Για μέτρηση jank στο iOS χρησιμοποιήστε MetricKit ή CADisplayLink. Επίσης στο iOS, το SDK δεν παρεμποδίζει αιτήματα που εκτελούνται μέσω πελατών HTTP τρίτων που δεν χρησιμοποιούν URLSession (π.χ. SwiftNIO). Για τέτοιες περιπτώσεις χρησιμοποιήστε προσαρμοσμένα ίχνη με χαρακτηριστικά HTTP.

Περιορισμοί Android: στο Android, η αυτόματη μέτρηση μνήμης είναι διαθέσιμη μόνο σε συσκευές με Android 8.0+ (API 26+). Για παλαιότερες εκδόσεις χρησιμοποιήστε προσαρμοσμένα ίχνη με λήψη δεδομένων μέσω Debug.getMemoryInfo(). Το SDK επίσης δεν παρεμποδίζει συνδέσεις WebSocket — για αυτές χρειάζονται ξεχωριστά ίχνη. Παρά τους περιορισμούς, οι αυτόματες μετρήσεις καλύπτουν το 80% των αναγκών παρακολούθησης απόδοσης.

Προσαρμοσμένα ίχνη και χαρακτηριστικά HTTP

Προσαρμοσμένα ίχνη (custom traces) είναι ονομασμένα χρονικά διαστήματα που ο προγραμματιστής δημιουργεί χειροκίνητα για τη μέτρηση της απόδοσης συγκεκριμένων σεναρίων: φόρτωση ροής ειδήσεων, επεξεργασία εικόνας, συγχρονισμός δεδομένων, εκτέλεση σύνθετου ερωτήματος βάσης δεδομένων. Τα προσαρμοσμένα ίχνη συμπληρώνουν τις αυτόματες μετρήσεις και επιτρέπουν τη μέτρηση ακριβώς εκείνων των τμημάτων κώδικα που ο προγραμματιστής θεωρεί κρίσιμα για την απόδοση.

Κάθε ίχνος έχει όνομα (μέγιστο 100 χαρακτήρες) και μπορεί να περιέχει έως 5 προσαρμοσμένες μετρήσεις (metrics) — αριθμητικές τιμές που καταγράφονται εντός του ίχνους. Για παράδειγμα, στο ίχνος „image_processing” μπορούν να μετρηθούν οι μετρήσεις „original_file_size” και „processed_file_size”. Οι μετρήσεις εμφανίζονται στην κονσόλα Firebase ως κατανομές (min, max, average, εκατοστημόρια), επιτρέποντας ανάλυση όχι μόνο της διάρκειας αλλά και των χαρακτηριστικών της λειτουργίας.

Χαρακτηριστικά HTTP είναι ένας ειδικός τύπος προσαρμοσμένων ιχνών για αιτήματα δικτύου που δεν παρεμποδίστηκαν αυτόματα από το SDK (π.χ. μέσω WebSocket ή βιβλιοθηκών τρίτων). Τα χαρακτηριστικά HTTP περιλαμβάνουν URL, μέθοδο HTTP, κωδικό απόκρισης και μέγεθος απόκρισης. Το Firebase τα εμφανίζει στην ενότητα „Network Requests” μαζί με αυτόματα συλλεγμένα αιτήματα, παρέχοντας μια ενοποιημένη εικόνα των αλληλεπιδράσεων δικτύου.

Πότε να χρησιμοποιείτε προσαρμοσμένα ίχνη

Τα προσαρμοσμένα ίχνη είναι απαραίτητα για τη μέτρηση: χρόνου φόρτωσης δεδομένων από τοπική βάση δεδομένων (Room, CoreData), διάρκειας σύνθετων υπολογισμών (κρυπτογράφηση, συμπίεση), απόδοσης κινούμενων σχεδίων και μεταβάσεων, χρόνου απόκρισης SDK τρίτων (χάρτες, πληρωμές, αναλυτικά). Για κάθε τέτοιο σενάριο δημιουργήστε ένα ίχνος, τυλίξτε τον μετρούμενο κώδικα σε start/stop και προσθέστε χαρακτηριστικά για μεταγενέστερη τμηματοποίηση.

Μην κάνετε κατάχρηση των προσαρμοσμένων ιχνών. Κάθε ίχνος σημαίνει πρόσθετη κατανάλωση μπαταρίας και δεδομένων. Συνιστάται όχι περισσότερα από 10–15 ενεργά ίχνη στην έκδοση παραγωγής της εφαρμογής. Για εντοπισμό σφαλμάτων μπορούν να προστεθούν περισσότερα ίχνη, αλλά πριν από την κυκλοφορία απενεργοποιήστε τα περιττά μέσω Remote Config (χρησιμοποιήστε τη σημαία performance_tracing_enabled). Αυτό επιτρέπει τη λεπτομερή παρακολούθηση μόνο για επιλεγμένους χρήστες ή συνεδρίες.

Χαρακτηριστικά ιχνών για τμηματοποίηση

Προσαρμοσμένα χαρακτηριστικά (custom attributes) είναι ζεύγη κλειδιού-τιμής που μπορούν να προστεθούν σε ένα ίχνος για μεταγενέστερο φιλτράρισμα στην κονσόλα Firebase. Για παράδειγμα, στο ίχνος „feed_load” μπορούν να προστεθούν τα χαρακτηριστικά „feed_type” (main, explore, following) και „cache_status” (cold, warm). Στην κονσόλα, τα δεδομένα ίχνους μπορούν να φιλτραριστούν βάσει αυτών των χαρακτηριστικών για να προσδιοριστεί ποιος τύπος ροής φορτώνεται πιο αργά.

Περιορισμοί: κάθε ίχνος μπορεί να έχει έως 5 προσαρμοσμένα χαρακτηριστικά. Η τιμή χαρακτηριστικού είναι συμβολοσειρά έως 100 χαρακτήρες. Τα χαρακτηριστικά πρέπει να οριστούν πριν από την έναρξη του ίχνους· η αλλαγή χαρακτηριστικού μετά την έναρξη αγνοείται. Αυτός ο περιορισμός σχετίζεται με την απόδοση: ο ορισμός χαρακτηριστικών μετά την έναρξη θα απαιτούσε πρόσθετο συγχρονισμό.

Όρια απόδοσης και ειδοποιήσεις

Όρια (thresholds) είναι παραμετροποιήσιμες οριακές τιμές μετρήσεων, στις οποίες όταν ξεπεραστούν το Firebase Performance δημιουργεί προειδοποίηση. Τα όρια ορίζονται στην κονσόλα Firebase (ενότητα Performance > Thresholds) για κάθε αυτόματη μέτρηση: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Μπορούν να οριστούν καθολικά όρια για όλες τις εκδόσεις εφαρμογής ή συγκεκριμένα για ορισμένες εκδόσεις.

Ειδοποιήσεις (alerts) είναι αυτόματες ειδοποιήσεις που στέλνει το Firebase κατά την υπέρβαση ορίου. Οι ειδοποιήσεις μπορούν να ρυθμιστούν για email, Slack webhook, PagerDuty ή Cloud Functions (για προσαρμοσμένη επεξεργασία). Κάθε ειδοποίηση περιέχει: όνομα μέτρησης, τρέχουσα τιμή, τιμή ορίου, έκδοση εφαρμογής, τμήμα (συσκευή, χώρα). Οι ειδοποιήσεις επιτρέπουν αντίδραση στην υποβάθμιση απόδοσης πριν γίνει αντιληπτή από τους χρήστες.

Συνιστώμενα όρια σύμφωνα με το βιομηχανικό πρότυπο (Google I/O 2025): ψυχρή εκκίνηση — λιγότερο από 2 δευτερόλεπτα, θερμή εκκίνηση — λιγότερο από 1 δευτερόλεπτο, απόδοση οθόνης — λιγότερο από 500 ms, διάρκεια αιτήματος HTTP — λιγότερο από 3000 ms (95ο εκατοστημόριο), ποσοστό αργών αιτημάτων — λιγότερο από 5%. Για εφαρμογές υψηλού ανταγωνισμού (Social, E-commerce) τα όρια στόχου μπορεί να είναι αυστηρότερα: ψυχρή εκκίνηση < 1,5 δευτερόλεπτα, HTTP < 1000 ms.

Ρύθμιση ορίων στην κονσόλα Firebase

Στην κονσόλα Firebase μεταβείτε στην ενότητα Performance, ανοίξτε την καρτέλα Thresholds. Για κάθε μέτρηση ορίστε την επιθυμητή τιμή ορίου και το ποσοστό χρηστών που πρέπει να επηρεάζονται από την υπέρβαση. Για παράδειγμα: “θεωρούμε την ψυχρή εκκίνηση αργή εάν υπερβαίνει τα 2 δευτερόλεπτα για περισσότερο από το 10% των χρηστών”. Το Firebase θα εμφανίσει τις τρέχουσες τιμές μετρήσεων και το ιστορικό υπερβάσεων για να βοηθήσει στην επιλογή ρεαλιστικών ορίων.

Σημαντικό: τα όρια δεν επηρεάζουν τη συλλογή δεδομένων, διαχειρίζονται μόνο τη δημιουργία ειδοποιήσεων. Εάν το όριο είναι πολύ χαμηλό (π.χ. ψυχρή εκκίνηση 1 δευτερόλεπτο, ενώ το 50% των συσκευών εκκινεί σε 3 δευτερόλεπτα), οι ειδοποιήσεις θα έρχονται συνεχώς και θα γίνουν “θόρυβος” που οι προγραμματιστές θα σταματήσουν να παρατηρούν. Ορίστε τα όρια βάσει τρεχόντων δεικτών και στη συνέχεια σταδιακά αυστηροποιήστε τα καθώς βελτιστοποιείτε την εφαρμογή.

Πίνακας ελέγχου Performance στην κονσόλα Firebase

Ο πίνακας ελέγχου Performance εμφανίζει τις βασικές μετρήσεις ως χρονοσειρές με ανάλυση ανά έκδοση εφαρμογής, συσκευή, χώρα, τύπο σύνδεσης και έκδοση OS. Για κάθε μέτρηση είναι διαθέσιμα: μέσος όρος, διάμεσος, 95ο εκατοστημόριο, 99ο εκατοστημόριο. Το 95ο εκατοστημόριο είναι η πιο κατατοπιστική μέτρηση για την αξιολόγηση απόδοσης, καθώς δείχνει πώς λειτουργεί η εφαρμογή σε “αδύναμες συσκευές”, αγνοώντας τις ακραίες τιμές.

Ο πίνακας ελέγχου υποστηρίζει σύγκριση εκδόσεων: επιλέξτε δύο εκδόσεις εφαρμογής (τρέχουσα και προηγούμενη) για οπτική σύγκριση μετρήσεων. Εάν μετά από ενημέρωση το 95ο εκατοστημόριο του χρόνου εκκίνησης αυξήθηκε από 2,1 σε 3,4 δευτερόλεπτα — η υποβάθμιση είναι προφανής και πρέπει να βρεθεί το commit που προκάλεσε την επιβράδυνση. Το Firebase Performance ενσωματώνεται με GitHub, GitLab και Bitbucket, επιτρέποντας τη σύνδεση αλλαγών μετρήσεων με συγκεκριμένα commits.

Παραδείγματα κώδικα για Performance Monitoring

Ας εξετάσουμε παραδείγματα ενσωμάτωσης του Firebase Performance Monitoring σε εφαρμογή Android σε Kotlin. Ο κώδικας δείχνει τη δημιουργία προσαρμοσμένου ίχνους για μέτρηση φόρτωσης ροής ειδήσεων, προσθήκη χαρακτηριστικού HTTP για μη αυτόματα παρεμποδισμένο αίτημα και χρήση Trace για μέτρηση χρόνου επεξεργασίας εικόνας. Όλα τα παραδείγματα λαμβάνουν υπόψη τη δυνατότητα απενεργοποίησης παρακολούθησης μέσω Remote Config.

Πριν από τη χρήση προσθέστε την εξάρτηση: implementation("com.google.firebase:firebase-perf") μέσω Firebase BOM. Για αυτόματη εργαλειοποίηση δεν απαιτείται πρόσθετη διαμόρφωση — το SDK παρεμποδίζει αυτόματα τις τυπικές λειτουργίες μετά τη σύνδεση της εξάρτησης.

Προσαρμοσμένο ίχνος για φόρτωση ροής

Το πρώτο παράδειγμα — μέτρηση χρόνου φόρτωσης ροής ειδήσεων από τον διακομιστή. Το ίχνος τυλίγει την ασύγχρονη λειτουργία fetchFeed, η οποία λαμβάνει δεδομένα από το δίκτυο και αναλύει JSON. Στο ίχνος προστέθηκαν προσαρμοσμένα χαρακτηριστικά: πηγή δεδομένων (cache ή network) και αριθμός ληφθέντων αναρτήσεων. Αυτό επιτρέπει την τμηματοποίηση δεδομένων και την κατανόηση υπό ποιες συνθήκες η ροή φορτώνεται πιο αργά.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

Η συνάρτηση loadFeedWithTrace δέχεται την παράμετρο source (“cache” ή “network”), η οποία χρησιμοποιείται ως χαρακτηριστικό ίχνους. Μετά την ολοκλήρωση της ασύγχρονης λειτουργίας, το ίχνος σταματά στο μπλοκ finally, εγγυώμενο τη διακοπή ακόμα και σε περίπτωση εξαίρεσης. Η μέτρηση items_count επιτρέπει την ανάλυση του πώς ο αριθμός των αναρτήσεων επηρεάζει τον χρόνο φόρτωσης. Στην κονσόλα Firebase, τα ίχνη μπορούν να φιλτραριστούν βάσει του χαρακτηριστικού source και να φανεί ότι η φόρτωση από το δίκτυο είναι 3 φορές πιο αργή από την προσωρινή μνήμη.

Χαρακτηριστικό HTTP για μη τυπικό αίτημα

Το δεύτερο παράδειγμα — χαρακτηριστικό HTTP για αίτημα που εκτελείται μέσω WebSocket (δεν παρεμποδίζεται αυτόματα). Χρησιμοποιείται η κλάση HttpMetric, η οποία επιτρέπει τη μη αυτόματη καταγραφή ενός αιτήματος URL, της μεθόδου του, του κωδικού απόκρισης και του μεγέθους. Το Firebase θα εμφανίσει αυτό το αίτημα στην ενότητα Network Requests μαζί με τα αυτόματα παρεμποδισμένα.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

Στο παράδειγμα, η sendWithHttpMetric χρησιμοποιεί το newHttpMetric για καταγραφή μιας μη τυπικής κλήσης HTTP. Το SDK δεν την παρεμποδίζει αυτόματα, επομένως ο προγραμματιστής ορίζει χειροκίνητα το URL, τη μέθοδο, τον κωδικό απόκρισης και τα μεγέθη. Είναι σημαντικό να ορίσετε το URL χωρίς παραμέτρους ερωτήματος (για ασφάλεια και συγκέντρωση) — δηλαδή /data, όχι /data?token=abc. Το Firebase ομαδοποιεί αυτόματα παρόμοια μοτίβα URL.

Μέτρηση χρόνου επεξεργασίας εικόνας

Το τρίτο παράδειγμα δείχνει τη μέτρηση χρόνου επεξεργασίας εικόνας (συμπίεση, αλλαγή μεγέθους) με χρήση προσαρμοσμένου ίχνους. Σε αυτήν την περίπτωση, το ίχνος τυλίγει μια σύγχρονη λειτουργία, αλλά για παραγωγή χρησιμοποιήστε coroutines ή RxJava για να μην μπλοκάρετε το νήμα UI.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

Η συνάρτηση compressImage μετρά τον χρόνο συμπίεσης εικόνας σε JPEG με ποιότητα 80%. Το χαρακτηριστικό format επιτρέπει μελλοντική σύγκριση χρόνου συμπίεσης JPEG έναντι WebP. Η μέτρηση output_size_kb δείχνει πόσο αποτελεσματική είναι η συμπίεση. Στην κονσόλα Firebase μπορεί να φανεί η κατανομή: σε αδύναμες συσκευές (οικονομικά Android) η συμπίεση διαρκεί 4 φορές περισσότερο από ό,τι σε κορυφαίες συσκευές, που μπορεί να είναι η αιτία καθυστερήσεων κατά την αποστολή εικόνων στον διακομιστή.

Πώς να βελτιώσετε την απόδοση βάσει δεδομένων

Το Firebase Performance παρέχει δεδομένα, αλλά δεν δίνει έτοιμες λύσεις. Η ανάλυση μετρήσεων απαιτεί κατανόηση των τυπικών αιτιών υποβάθμισης απόδοσης για κάθε μέτρηση. Ας εξετάσουμε τα κύρια μοτίβα χειροτέρευσης και τις μεθόδους διάγνωσής τους βάσει δεδομένων Performance Monitoring. Προσέγγιση: βρείτε ανωμαλία στη μέτρηση → ελέγξτε τυπικές αιτίες → εφαρμόστε βελτιστοποίηση → ελέγξτε το αποτέλεσμα σε μία εβδομάδα.

Αργή ψυχρή εκκίνηση (> 2 δευτερόλεπτα): αιτίες — βαριά αρχικοποίηση SDK στο Application.onCreate (αναλυτικά, crash reporting, map SDK), φόρτωση μεγάλων πόρων (γραμματοσειρές, θέματα), σύγχρονες λειτουργίες στο κύριο νήμα κατά την εκκίνηση. Λύσεις: τεμπέλης αρχικοποίηση SDK, αναβαλλόμενη φόρτωση πόρων, χρήση SplashScreen API (Android 12+) για εμφάνιση placeholder κατά την αρχικοποίηση. Το Firebase Performance θα δείξει ποια έκδοση εφαρμογής άρχισε να εκκινεί πιο αργά — ελέγξτε ποιες εξαρτήσεις προστέθηκαν ή ενημερώθηκαν.

Αργή απόδοση οθόνης (> 500 ms): αιτίες — σύνθετη ιεραρχία View (φωλιασμένα ConstraintLayout, πολλά Fragment), φόρτωση δεδομένων στο νήμα UI (δίκτυο ή δίσκος), βαριές λειτουργίες draw (μεγάλες εικόνες, προσαρμοσμένα View). Λύσεις: βελτιστοποίηση ιεραρχίας διάταξης (Layout Inspector στο Android Studio), μεταφορά δεδομένων σε νήμα παρασκηνίου, προσωρινή αποθήκευση εικόνων μέσω Glide ή Coil. Χρησιμοποιήστε το φίλτρο Screen Rendering στο Firebase για να βρείτε την πιο αργή οθόνη και να τη βελτιστοποιήσετε πρώτα.

Βελτιστοποίηση αιτημάτων δικτύου

Αργά αιτήματα HTTP (> 3 δευτερόλεπτα): αιτίες — αργός διακομιστής, μεγάλα payloads, έλλειψη προσωρινής αποθήκευσης, μη βέλτιστο πρωτόκολλο (HTTP/1.1 αντί HTTP/2), ανάλυση DNS. Λύσεις: ελέγξτε την πλευρά του διακομιστή (uptime, latency), μειώστε το μέγεθος απόκρισης (σελιδοποίηση, GraphQL, protobuf αντί JSON), ενεργοποιήστε την προσωρινή αποθήκευση μέσω κεφαλίδων HTTP (Cache-Control), χρησιμοποιήστε OkHttp Interceptor για προσθήκη χρονικών ορίων και λογικής επανάληψης.

Το Firebase Performance δείχνει την κατανομή χρόνου του αιτήματος: ανάλυση DNS, χειραψία TCP, χειραψία TLS, αποστολή αιτήματος, λήψη απόκρισης. Εάν το μεγαλύτερο μέρος του χρόνου αφιερώνεται στο DNS — χρησιμοποιήστε προφόρτωση DNS (OkHttp DNS-over-HTTPS). Εάν στο TLS — χρησιμοποιήστε επανάληψη συνόδου και ρύθμιση cipher suites. Εάν στη λήψη απόκρισης — ελέγξτε το μέγεθος απόκρισης και την ταχύτητα δικτύου του χρήστη. Τα δεδομένα Firebase επιτρέπουν τον εντοπισμό του προβλήματος σε επίπεδο πρωτοκόλλου, όχι απλώς να πούμε “το αίτημα είναι αργό”.

Ενσωμάτωση Remote Config για απενεργοποίηση παρακολούθησης

Για παραγωγή συνιστάται η προσθήκη σημαίας Remote Config performance_tracing_enabled, η οποία επιτρέπει την εξ αποστάσεως απενεργοποίηση προσαρμοσμένων ιχνών. Εάν το Firebase Performance SDK στον πελάτη παράγει πάρα πολλά δεδομένα ή επηρεάζει την απόδοση (σε αδύναμες συσκευές), μπορείτε να απενεργοποιήσετε τα ίχνη για όλους τους χρήστες, αφήνοντας μόνο τις αυτόματες μετρήσεις που έχουν ελάχιστο φόρτο.

Παράδειγμα λογικής: κατά την εκκίνηση της εφαρμογής ελέγχουμε την παράμετρο Remote Config performance_tracing_enabled. Εάν είναι false — όλες οι κλήσεις Firebase.performance.newTrace() επιστρέφουν ένα αντικείμενο stub που δεν συλλέγει δεδομένα. Αυτό υλοποιείται μέσω μιας κλάσης wrapper που ελέγχει τη σημαία πριν από τη δημιουργία ίχνους. Μια τέτοια προσέγγιση επιτρέπει τη λεπτομερή παρακολούθηση για συγκεκριμένους χρήστες (beta testers, προγραμματιστές) χωρίς να επηρεάζεται ολόκληρο το κοινό.