Γιατί πετάξαμε την εφαρμογή μας σε Flutter και ξαναφτιάξαμε το Cliqer Remote native, πάνω σε πυρήνα Rust

Στις 26 Σεπτεμβρίου ξεκινήσαμε να φτιάχνουμε σε Flutter το Cliqer Remote, την εφαρμογή κινητού μας για ομιλητές. Πέντε μέρες αργότερα ήταν στο TestFlight και στο internal track του Google Play, με κάθε λειτουργία της web εφαρμογής για ομιλητές: το τηλεχειριστήριο παρουσιάσεων, τη ζωντανή οθόνη, το μελάνι, τη συνομιλία, τις σημειώσεις και τις κλήσεις. Λειτουργούσε. Μετά τη μετρήσαμε σε πραγματικά τηλέφωνα, είδαμε ένα από αυτά να φτάνει σε θερμοκρασία επιφάνειας 42 °C απλώς δείχνοντας μια κοινόχρηστη οθόνη, και την πετάξαμε.

Κανείς εκτός της ομάδας μας δεν είδε ποτέ εκείνη την εφαρμογή. Αντί γι' αυτήν, παίρνετε μια native εφαρμογή σε κάθε πλατφόρμα: SwiftUI σε iPhone, iPad και Apple Watch, Kotlin και Jetpack Compose σε Android και Wear OS, και από κάτω μία μηχανή, γραμμένη μία φορά σε Rust. Αυτή είναι η ιστορία του γιατί, με τους αριθμούς που μετρήσαμε στην πορεία.

Το τηλεχειριστήριο είναι μια ιδιόρρυθμη εφαρμογή

Οι περισσότερες εφαρμογές χρησιμοποιούνται για λίγο κάθε φορά. Ένα τηλεχειριστήριο παρουσιάσεων όχι. Μένει στο ένα χέρι για ολόκληρη την ομιλία, συχνά κάτω από τα φώτα της σκηνής, με την οθόνη αναμμένη και τον ασύρματο απασχολημένο όλη την ώρα. Στο Cliqer δείχνει επίσης ζωντανή εικόνα της οθόνης του ομιλητή, σχεδιάζει μελάνι πάνω στις διαφάνειες, μεταφέρει συνομιλία και σημειώσεις, και μπορεί να βάλει τον ομιλητή στην κάμερα όταν τον προσκαλέσει ο οικοδεσπότης.

Αυτό το «καθηκοντολόγιο» θέτει τρεις κανόνες:

1. Κάθε πάτημα πρέπει να φτάνει, αμέσως. Ένα κλικ που φτάνει αργά σημαίνει έναν ομιλητή που στέκεται σιωπηλός μπροστά στο κοινό.
2. Το τηλέφωνο πρέπει να μένει δροσερό. Ένα ζεστό τηλέφωνο περιορίζει την απόδοσή του, και ένα τηλέφωνο με περιορισμένη απόδοση χάνει καρέ, αποκωδικοποιεί το βίντεο με καθυστέρηση και αδειάζει τη μπαταρία του πιο γρήγορα. Είναι επίσης δυσάρεστο να το κρατά κανείς για μία ώρα.
3. Η εφαρμογή πρέπει να είναι μικρή και να ξεκινά γρήγορα. Οι άνθρωποι την εγκαθιστούν στον χώρο της εκδήλωσης, συχνά μέσω του Wi-Fi του συνεδρίου, λίγα λεπτά πριν ανέβουν στη σκηνή.

Το Flutter τα καταφέρνει και στα τρία για τις περισσότερες εφαρμογές. Η δική μας αποδείχθηκε το είδος εφαρμογής όπου κοστίζει περισσότερα απ' όσα δίνει.

Τι έκανε σωστά το Flutter

Ας αναγνωρίσουμε ό,τι του αξίζει. Το Flutter μάς πήγε από έναν άδειο φάκελο σε μια πλήρη εφαρμογή και στα δύο καταστήματα σε πέντε μέρες, με έναν ενιαίο κώδικα, hot reload, εξαιρετική υποστήριξη για tests και ένα UI που έμοιαζε ίδιο παντού. Γράψαμε 266 tests γι' αυτό. Αν φτιάχνετε μια εφαρμογή με φόρμες και λίστες, ένα dashboard ή ένα ηλεκτρονικό κατάστημα, θα το προτείναμε ακόμη χωρίς δεύτερη σκέψη.

Μάθαμε επίσης πολλά από αυτό. Σχεδόν κάθε εύρημα αυτού του άρθρου προήλθε από την ανίχνευση εκείνης της έκδοσης Flutter σε πραγματικό τηλέφωνο, και ορισμένες από τις διορθώσεις ζουν πλέον σε κάθε client του Cliqer, μαζί και στο web.

Πού πόνεσε: το γυαλί κοστίζει μια ολόκληρη οθόνη ανά καρέ

Η εμφάνιση του Cliqer είναι παγωμένο γυαλί: ημιδιαφανή πάνελ που θολώνουν ό,τι βρίσκεται πίσω τους. Σε iPhone και iPad αυτό κόστιζε ελάχιστα. Στο τηλέφωνο δοκιμών μας με Android, ένα Galaxy S24+ με οθόνη 120 Hz, όχι. Στα 120 Hz ένα καρέ έχει 8,3 ms για να σχεδιαστεί, ολόκληρο.

Ανιχνεύσαμε τη GPU στη συσκευή και βρήκαμε την αιτία στον τρόπο που η μηχανή απόδοσης γραφικών διαβάζει το φόντο: κάθε γυάλινο πάνελ αντέγραφε ολόκληρη την οθόνη, σε κάθε καρέ, με multisampling από πάνω. Η οθόνη συμμετοχής είχε εννέα γυάλινα πάνελ, άρα εννέα αντίγραφα ολόκληρης της οθόνης ανά καρέ. Η GPU αυτού του τηλεφώνου είναι σχεδίαση επιπέδου υπολογιστή που δεν είναι tiler: δεν έχει φθηνό τρόπο να διαβάσει πίσω ό,τι μόλις σχεδίασε, και κάθε νέο μέγεθος υφής σήμαινε νέα δέσμευση μνήμης που ο kernel πρώτα μηδενίζει. Σε μία ανίχνευση, το 71% του χρόνου του νήματος raster δαπανήθηκε σε δέσμευση μνήμης γραφικών.

Το διορθώσαμε, οθόνη προς οθόνη. Περάσαμε σε μια προέκδοση της μηχανής ώστε ένα θόλωμα να περιορίζεται στο πάνελ του (από 41 ms σε 17 ms). Ομαδοποιήσαμε τα εννέα πάνελ της οθόνης συμμετοχής σε μία κοινή ανάγνωση (από 19,8 ms σε 5,7 ms). Σταματήσαμε να κινούμε το μέγεθος οποιασδήποτε γυάλινης επιφάνειας, επειδή κάθε νέο μέγεθος ήταν μια νέα δέσμευση, και μιμηθήκαμε τα animations με επίπεδα σταθερού μεγέθους. Το χειρότερο καρέ του σαρωτή QR έπεσε από 285 ms σε 18 ms.

Κάθε μία από αυτές τις διορθώσεις ήταν μια παράκαμψη για τη μηχανή, όχι μια λειτουργία για τον ομιλητή. Και με το γυαλί να αποτελεί το 80 έως 90% του χρόνου GPU σε ένα δωμάτιο, απείχαμε πάντα ένα νέο πάνελ από το να ξαναχάσουμε καρέ.

Πού πόνεσε πραγματικά: το βίντεο και η ζέστη που προκαλεί

Η κοινόχρηστη οθόνη είναι το πιο βαρύ πράγμα που δείχνει η εφαρμογή. Στην έκδοση Flutter, κάθε αποκωδικοποιημένο καρέ βίντεο παραδιδόταν στο UI ως υφή, που σήμαινε ότι το UI ξανασχεδιαζόταν για κάθε καρέ βίντεο: το δωμάτιο, το γυαλί, τα χειριστήρια, τα πάντα, 45 φορές το δευτερόλεπτο, μόνο για να μετακινηθούν τα pixel μέσα σε ένα ορθογώνιο.

Το μετρήσαμε πρώτη φορά στο Galaxy με ανιχνεύσεις συστήματος την 1η Οκτωβρίου. Όσο έπαιζε το βίντεο, η GPU κινούνταν γύρω στα 440 MHz. Όταν άλλαζε μια διαφάνεια, τα καρέ χρειάζονταν 25 έως 33 ms και η GPU έφτανε στο ανώτατο όριο των 800 MHz για πάνω από τη μισή μετάβαση. Το τηλέφωνο βρισκόταν στη θερμική κατάσταση «μέτρια» του συστήματος με θερμοκρασία επιφάνειας 42 °C, και περιόριζε μόνο του τη GPU του για να αντεπεξέλθει. Η ζέστη έκανε επίσης τις μετρήσεις μας να λένε ψέματα: ένα ζεστό τηλέφωνο έδινε μετρήσεις περίπου 20% πιο αργές από ένα δροσερό, οπότε κάθε σύγκριση έπρεπε να εναλλάσσει τις εκδόσεις στην ίδια θερμοκρασία.

Μετά κάναμε το προφανές πείραμα: βάλαμε το βίντεο σε ένα native επίπεδο που συνθέτει το ίδιο το λειτουργικό σύστημα, έξω από το UI. Ίδιο τηλέφωνο, ίδια εφαρμογή, ίδιο δωμάτιο: το UI σταμάτησε να ξανασχεδιάζεται για το βίντεο, το ρολόι της GPU έπεσε από 440 σε 121 MHz, και το καρέ κατά την αλλαγή διαφάνειας πήγε από 25 έως 33 ms σε 3 έως 7 ms. Κυκλοφορήσαμε αυτή τη διόρθωση μέσα στην εφαρμογή Flutter την 1η Οκτωβρίου. Μας έδειξε επίσης πού βρισκόταν η πραγματική απάντηση: σε μια native εφαρμογή, το βίντεο ζει πάντα σε επίπεδο συστήματος, σε iPhone και σε Android, οπότε όλη αυτή η κατηγορία προβλημάτων εξαφανίζεται εκ κατασκευής και όχι με παρακάμψεις.

Ίδιο τηλέφωνο, ίδιο δωμάτιο, δέκα λεπτά

Οι ισχυρισμοί για τη ζέστη δεν κοστίζουν τίποτα, γι' αυτό τη μετρήσαμε. Στις 5 Οκτωβρίου βάλαμε τρεις εκδόσεις στο ίδιο Galaxy S24+, τη μία μετά την άλλη, για δέκα λεπτά η καθεμία, εκτός φόρτισης, στο ίδιο δωμάτιο, να δείχνουν την ίδια κινούμενη κοινόχρηστη οθόνη. Πριν από κάθε δοκιμή το τηλέφωνο κρύωνε ξανά.

1. Flutter, πρώτη έκδοση: η εφαρμογή όπως την πρωτοφτιάξαμε, με το βίντεο να σχεδιάζεται από το UI.
2. Flutter, βελτιστοποιημένη: η ίδια εφαρμογή μετά τις διορθώσεις γυαλιού και βίντεο που περιγράψαμε παραπάνω.
3. Native: το νέο Cliqer Remote.

Η πρώτη έκδοση Flutter ξανασχεδίαζε ολόκληρο το περιβάλλον της 47,6 φορές το δευτερόλεπτο μόνο για να δείξει ένα βίντεο, κρατούσε τη GPU σε μέσο όρο 366 MHz και χρησιμοποιούσε 1,47 δευτερόλεπτα χρόνου CPU κάθε δευτερόλεπτο. Η native εφαρμογή δεν σχεδίασε ούτε ένα καρέ περιβάλλοντος σε δέκα λεπτά: κινούνταν μόνο το επίπεδο του βίντεο. Η GPU της είχε μέσο όρο 129 MHz, η CPU της 0,69 δευτερόλεπτα ανά δευτερόλεπτο, και κατανάλωσε 86 mAh μπαταρίας έναντι 168 mAh. Δηλαδή τη μισή μπαταρία για την ίδια δουλειά.

Και η ζέστη. Σε δέκα λεπτά η πρώτη έκδοση Flutter ανέβασε τη μπαταρία από 36,2 °C σε 42,1 °C, και το τηλέφωνο άρχισε να περιορίζει την απόδοσή του. Με τη βελτιστοποιημένη έκδοση Flutter η άνοδος ήταν 1,9 °C. Με τη native εφαρμογή ήταν 0,2 °C. Μια ομιλία διαρκεί περισσότερο από δέκα λεπτά, και αυτή είναι η διαφορά που νιώθετε στο χέρι σας.

Για να είμαστε δίκαιοι με τη βελτιστοποιημένη έκδοση Flutter: έφτασε κοντά. Οι δικές μας διορθώσεις μέσα στο Flutter αφαίρεσαν το μεγαλύτερο μέρος του κόστους, και η native την ξεπέρασε με μικρότερη διαφορά, 12% λιγότερη CPU και 25% λιγότερη μπαταρία. Το θέμα είναι από πού ξεκινά η καθεμία. Η πρώτη έκδοση ήταν αυτό που είναι μια καλή εφαρμογή Flutter χωρίς καμία παρέμβαση· η native φτάνει στο δροσερό αποτέλεσμα χωρίς τις παρακάμψεις.

Πώς μετρήσαμε, ώστε να μπορείτε να το επαναλάβετε: ανιχνεύσεις Perfetto στη συσκευή (χρονολόγιο καρέ, συχνότητα GPU, μετρητές μπαταρίας), χρόνος CPU της διεργασίας από τον kernel, και η θερμοκρασία μπαταρίας του ίδιου του τηλεφώνου, με το ίδιο animation 60 fps στην κοινόχρηστη οθόνη σε κάθε δοκιμή. Ένα τηλέφωνο και μία δοκιμή ανά έκδοση, οπότε δείτε τους αριθμούς ως προσεκτική δοκιμή πεδίου, όχι ως εργαστηριακό benchmark. Η native δοκιμή ξεκίνησε επίσης περίπου 2 °C πιο δροσερή, γι' αυτό συγκρίνουμε την άνοδο.

Τι φτιάξαμε στη θέση της

Το νέο Cliqer Remote είναι native σε κάθε πλατφόρμα, χτισμένο πάνω σε μία κοινή μηχανή.

Το περιβάλλον είναι native σε κάθε πλατφόρμα. Σε iPhone και iPad είναι SwiftUI με το Liquid Glass του ίδιου του συστήματος. Σε Android είναι Jetpack Compose, με πραγματικό θόλωμα φόντου όπου το επιτρέπει η πλατφόρμα. Οι εφαρμογές Apple Watch και Wear OS είναι επίσης native, αρκετά μικρές ώστε να έχετε το Επόμενο και το Πίσω στον καρπό σας.

Η μηχανή γράφεται μία φορά, σε Rust. Η συμμετοχή σε ένα δωμάτιο, η επανασύνδεση και η συνέχιση μετά από αλλαγή δικτύου, η λήψη του βίντεο της οθόνης, η αποστολή κλικ, laser και μελανιού, η συνομιλία, οι σημειώσεις, το χρονόμετρο, οι κλήσεις και η σύζευξη τηλεφώνου με υπολογιστή ζουν όλα σε μία βιβλιοθήκη Rust που μοιράζονται και οι δύο εφαρμογές. Κάθε εφαρμογή απλώς σχεδιάζει το περιβάλλον, αποκωδικοποιεί το βίντεο με τον αποκωδικοποιητή υλικού του συστήματος και επικοινωνεί με την κάμερα και το μικρόφωνο. Μια διόρθωση πρωτοκόλλου γίνεται μία φορά και φτάνει και στις δύο πλατφόρμες, και οι δύο εφαρμογές δεν μπορούν να αποκλίνουν μεταξύ τους.

Η Rust ήταν η φυσική επιλογή για αυτή τη μηχανή: κανένας garbage collector που να παγώνει ένα καρέ, ασφάλεια μνήμης χωρίς runtime, και μεταγλώττιση σε μία μικρή βιβλιοθήκη τόσο για iOS όσο και για Android. Είναι γρήγορη εκεί που μετράει. Σε Mac, η μηχανή μας πακετάρει ένα καρέ H.264 20 KB σε 31 µs, ολοκληρώνει μια ασφαλή χειραψία σε 198 µs ανά πλευρά, και στις δοκιμές μας παραδίδει ένα καρέ βίντεο 100 KB στο περιβάλλον του Android σε 46 µs (χρειαζόταν 440 µs πριν βελτιστοποιήσουμε αυτό το σημείο διασύνδεσης). Μέσω relay, ένας κύκλος μετ' επιστροφής είχε διάμεσο 13 έως 16 ms στις δοκιμές μας.

Και μικρότερη

Μετρήσαμε και τις δύο εκδόσεις με τον ίδιο τρόπο. Η εφαρμογή iPhone, όπως ανέβηκε στην Apple, πήγε από 27,6 MB σε 10,8 MB, και αυτό μαζί με την εφαρμογή Apple Watch (1,5 MB) μέσα της. Η λήψη για τηλέφωνο Android, μετρημένη με το bundle tool της ίδιας της Google για το ίδιο τηλέφωνο 64-bit, πήγε από 15,6 MB σε 5,8 MB. Περίπου το ένα τρίτο του παλιού μεγέθους κάνει τη διαφορά όταν κάποιος εγκαθιστά την εφαρμογή μέσω του Wi-Fi του χώρου πέντε λεπτά πριν ανέβει στη σκηνή.

Το κυνήγι των χιλιοστών του δευτερολέπτου δεν σταμάτησε στο τηλέφωνο

Μια πιο γρήγορη εφαρμογή τηλεφώνου είναι μόνο το μισό ενός κλικ. Το άλλο μισό είναι ο υπολογιστής που τρέχει την παρουσίαση, και όσο ξαναχτίζονταν οι εφαρμογές κυνηγήσαμε και αυτή την πλευρά.

Κλικ: από μισό δευτερόλεπτο σε ένα δέκατο

Όταν ένα κλικ φτάνει στην εφαρμογή υπολογιστή του Cliqer, πρέπει να προχωρήσει την παρουσίαση και μετά να ενημερώσει όλους στο δωμάτιο για το ποια διαφάνεια εμφανίζεται. Αυτό το δεύτερο μέρος ρωτούσε την εφαρμογή παρουσίασης για τον αριθμό διαφάνειας μετά από κάθε κλικ, και αυτή η ερώτηση ήταν αργή.

Το Cliqer 2.3 κρατά ανοιχτή μία σύνδεση με το PowerPoint ή το Keynote και διαβάζει τη θέση απευθείας από το βήμα που μόλις έκανε. Σε Mac, σε 20 δοκιμές, ο διάμεσος χρόνος από κλικ σε διαφάνεια έπεσε από 509 ms σε 48 ms στο PowerPoint και από 408 ms σε 42 ms στο Keynote. Δέκα γρήγορα πατήματα, όπως αυτά που κάνει ένας ομιλητής για να προσπεράσει μια ενότητα, χρειάζονταν 5,3 δευτερόλεπτα για να ολοκληρωθούν. Τώρα συγχωνεύονται σε μία κίνηση και ολοκληρώνονται σε 254 ms.

Βίντεο που προλαβαίνει ακόμη και σε κακό Wi-Fi

Νωρίτερα φέτος βρήκαμε γιατί μια κοινόχρηστη οθόνη μπορούσε να παγώνει για δευτερόλεπτα σε Wi-Fi. Το βίντεο οθόνης στο Cliqer ταξιδεύει μέσω ενός αξιόπιστου καναλιού δεδομένων, και το πρότυπο πάνω στο οποίο βασίζεται αυτό το κανάλι περιμένει τουλάχιστον ένα ολόκληρο δευτερόλεπτο πριν ξαναστείλει ένα χαμένο πακέτο, διπλασιάζοντας την αναμονή σε κάθε επανάληψη. Το Chrome χρησιμοποιεί 400 ms. Κάθε καρέ πίσω από το χαμένο περίμενε στην ουρά, ο υπολογιστής οικοδεσπότη μετά επέβαλλε πλήρη ανανέωση στην ίδια ουρά, και σε αργή σύνδεση το έκανε ξανά και ξανά.

Ρυθμίσαμε τους χρονομετρητές επαναποστολής στις τιμές του Chrome και σταματήσαμε τις ανανεώσεις από το να μπαίνουν στην ουρά πίσω από τα εκκρεμή δεδομένα. Σε προσομοίωση δικτύου με μοντέλο απωλειών Wi-Fi, ένας διαμοιρασμός 1080p πήγε από 15 έως 22 παγώματα του ενός δευτερολέπτου ή περισσότερο ανά δύο λεπτά σε 0 έως 2, και η διάμεση καθυστέρηση σε σχέση με το ζωντανό από έως και 2,3 δευτερόλεπτα σε 12 ms. Περιορίσαμε επίσης τις πλήρεις ανανεώσεις σε μία ανά ροή κάθε μισό δευτερόλεπτο, επειδή καθεμία πηγαίνει σε κάθε θεατή: πριν από αυτό το όριο, ένας θεατής μπορούσε να λάβει 19 πλήρεις ανανεώσεις το δευτερόλεπτο, περίπου 40 Mbit/s.

Από την πλευρά του τηλεφώνου, ο αποκωδικοποιητής βίντεο υλικού του Galaxy κρατούσε πίσω ένα συνηθισμένο καρέ για περίπου 60 ms, σχεδόν μία φορά το δευτερόλεπτο. Όταν ζητήσαμε από τον αποκωδικοποιητή να τρέχει σε πλήρη ταχύτητα, αυτό έπεσε σε μηδέν καθυστερημένα καρέ σε 50 δευτερόλεπτα. Αυτή η διόρθωση περιλαμβάνεται στη native εφαρμογή Android.

Τι θα λέγαμε σε μια άλλη ομάδα

Αν φτιάχνετε οτιδήποτε πραγματικού χρόνου σε τηλέφωνα, αυτά μας κόστισαν μέρες για να τα μάθουμε και θέλουν λεπτά για να εφαρμοστούν:

1. Μετρήστε στη χειρότερη πραγματική συσκευή σας, όχι στον εξομοιωτή. Ο εξομοιωτής μας έτρεχε στα 60 Hz σε διαφορετικό backend γραφικών και δεν μπορούσε να δείξει ούτε ένα από τα προβλήματα του γυαλιού.
2. Εναλλάσσετε τις εκδόσεις στην ίδια θερμοκρασία. Ένα ζεστό τηλέφωνο έδινε μετρήσεις περίπου 20% πιο αργές. Αν συγκρίνετε μια κρύα δοκιμή με μια ζεστή, τα αποτελέσματα θα σας παραπλανήσουν.
3. Μετρήστε τις αναγνώσεις θολώματος. Κάθε θόλωμα φόντου μπορεί να κοστίσει ένα αντίγραφο ολόκληρης της οθόνης ανά καρέ. Ομαδοποιήστε τα, περιορίστε τα, και μην κινείτε ποτέ το μέγεθος μιας θολωμένης επιφάνειας.
4. Μην ξανασχεδιάζετε ποτέ το UI σας για το βίντεο. Βάλτε το βίντεο σε ένα επίπεδο που συνθέτει το σύστημα. Ήταν το μεγαλύτερο μεμονωμένο κέρδος σε GPU, μπαταρία και θερμότητα που μετρήσαμε.
5. Ζητήστε από τον αποκωδικοποιητή υλικού ταχύτητα πραγματικού χρόνου. Σε Android, ορίστε το operating rate του αποκωδικοποιητή. Μία γραμμή εξάλειψε μια καθυστέρηση 60 ms κάθε δευτερόλεπτο.
6. Ελέγξτε τους χρονομετρητές του transport σας. Τα αξιόπιστα κανάλια δεδομένων κληρονομούν χρονομετρητές επαναποστολής από παλαιότερα πρότυπα. Ένα ελάχιστο ενός δευτερολέπτου είναι αιωνιότητα για ζωντανό βίντεο.
7. Αντιμετωπίστε τις πλήρεις ανανεώσεις ως τα ακριβά καρέ που είναι. Περιορίστε τις ανά ροή, επειδή καθεμία πηγαίνει σε κάθε θεατή.
8. Συγχωνεύστε τις ριπές εισόδου. Δέκα πατήματα πρέπει να γίνουν μία κίνηση δέκα βημάτων, όχι δέκα κύκλοι μετ' επιστροφής.
9. Διαβάστε τι γράφουν τα εργαλεία σας μέσα στο build σας. Ένα toolchain σε προέκδοση ενεργοποίησε μια σημαία απόδοσης γραφικών στο Android manifest μας χωρίς να ρωτήσει.

Τι σημαίνει αυτό για εσάς

Το Cliqer Remote είναι native σε iPhone, iPad, Android, Apple Watch και Wear OS. Τα κλικ είναι πιο γρήγορα, το τηλέφωνο μένει δροσερό και καταναλώνει τη μισή μπαταρία σε σχέση με την πρώτη μας έκδοση, το βίντεο σχεδιάζεται με τον τρόπο που το τηλέφωνο είναι φτιαγμένο να το σχεδιάζει, και η εφαρμογή έχει περίπου το ένα τρίτο του παλιού της μεγέθους. Η web εφαρμογή για ομιλητές εξακολουθεί να λειτουργεί σε κάθε πρόγραμμα περιήγησης χωρίς καμία εγκατάσταση, οπότε κανείς στο δωμάτιό σας δεν μένει ποτέ εκτός.

Συχνές ερωτήσεις