Pourquoi nous avons abandonné notre app Flutter pour reconstruire Cliqer Remote en natif, sur un cœur Rust

Le 26 septembre, nous avons commencé à développer Cliqer Remote, notre application mobile pour présentateurs, en Flutter. Cinq jours plus tard, elle était sur TestFlight et sur la piste de test interne de Google Play, avec toutes les fonctionnalités de l'interface web du présentateur : la télécommande de présentation, l'écran en direct, l'annotation, le chat, les notes et les appels. Elle fonctionnait. Puis nous l'avons mesurée sur de vrais téléphones, nous avons vu l'un d'eux atteindre une température de surface de 42 °C rien qu'en affichant un écran partagé, et nous l'avons jetée.

Personne en dehors de notre équipe n'a jamais vu cette application. Ce que vous obtenez à la place, c'est une application native sur chaque plateforme : SwiftUI sur iPhone, iPad et Apple Watch, Kotlin et Jetpack Compose sur Android et Wear OS, et un seul moteur en dessous, écrit une fois pour toutes en Rust. Voici pourquoi, avec les chiffres que nous avons mesurés en chemin.

Une télécommande est une application étrange à concevoir

La plupart des applications s'utilisent par courtes séquences. Pas une télécommande de présentation. Elle reste dans une main pendant toute une intervention, souvent sous les projecteurs, écran allumé, radio sollicitée en permanence. Sur Cliqer, elle affiche aussi une image en direct de l'écran du présentateur, dessine des annotations sur les diapositives, transporte le chat et les notes, et peut mettre le présentateur à l'image lorsque l'hôte l'invite.

Ce cahier des charges impose trois règles :

1. Chaque pression doit arriver, tout de suite. Un clic qui arrive en retard, c'est un intervenant planté en silence devant son public.
2. Le téléphone doit rester froid. Un téléphone chaud se bride, et un téléphone bridé perd des images, décode la vidéo en retard et vide sa batterie plus vite. Il est aussi désagréable à tenir pendant une heure.
3. L'application doit être légère et démarrer vite. Les gens l'installent sur place, souvent sur le Wi-Fi de la conférence, quelques minutes avant de monter sur scène.

Flutter sait faire les trois pour la plupart des applications. La nôtre s'est révélée être le genre d'application où il coûte plus qu'il n'apporte.

Ce que Flutter a bien fait

Rendons à César ce qui est à César. Flutter nous a menés d'un dossier vide à une application complète sur les deux stores en cinq jours, avec une seule base de code, le hot reload, d'excellents outils de test et une interface identique partout. Nous avons écrit 266 tests pour elle. Si vous développez une application de formulaires et de listes, un tableau de bord ou une boutique, nous le recommanderions encore sans hésiter.

Il nous a aussi beaucoup appris. Presque toutes les découvertes de cet article viennent du traçage de cette version Flutter sur un vrai téléphone, et certains correctifs font désormais partie de tous les clients Cliqer, web compris.

Là où ça a fait mal : le verre coûte un écran entier par image

Le style de Cliqer, c'est le verre dépoli : des panneaux translucides qui floutent ce qui se trouve derrière eux. Sur iPhone et iPad, c'était peu coûteux. Sur notre téléphone de test Android, un Galaxy S24+ avec un écran 120 Hz, ce n'était pas le cas. À 120 Hz, une image dispose de 8,3 ms pour être dessinée, en tout et pour tout.

Nous avons tracé le GPU sur l'appareil et trouvé la cause dans la façon dont le moteur de rendu lit l'arrière-plan : chaque panneau de verre copiait l'écran entier, à chaque image, avec en plus du multi-échantillonnage. L'écran d'accès comptait neuf panneaux de verre, donc neuf copies plein écran par image. Le GPU de ce téléphone est une architecture de classe desktop qui ne fonctionne pas par tuiles : il n'a aucun moyen économique de relire ce qu'il vient de dessiner, et chaque nouvelle taille de texture impliquait une nouvelle allocation mémoire que le noyau remet d'abord à zéro. Dans une trace, 71 % du temps du thread de rastérisation était consacré à l'allocation de mémoire graphique.

Nous l'avons corrigé, écran par écran. Nous sommes passés à une préversion du moteur afin de pouvoir limiter un flou à son panneau (de 41 ms à 17 ms). Nous avons regroupé les neuf panneaux de l'écran d'accès en une seule lecture partagée (de 19,8 ms à 5,7 ms). Nous avons cessé d'animer la taille de toute surface en verre, car chaque nouvelle taille signifiait une nouvelle allocation, et simulé les animations avec des calques de taille fixe. La pire image du lecteur de QR code est passée de 285 ms à 18 ms.

Chacun de ces correctifs contournait une limite du moteur, sans apporter la moindre fonctionnalité à un présentateur. Et avec le verre représentant 80 à 90 % du temps GPU dans une salle, nous étions toujours à un nouveau panneau de recommencer à perdre des images.

Là où ça a vraiment fait mal : la vidéo, et la chaleur qu'elle produit

L'écran partagé est l'élément le plus lourd qu'affiche l'application. Dans la version Flutter, chaque image vidéo décodée était transmise à l'interface sous forme de texture, ce qui signifiait que l'interface se redessinait à chaque image vidéo : la salle, le verre, les commandes, tout, 45 fois par seconde, simplement pour faire bouger les pixels à l'intérieur d'un rectangle.

Nous l'avons d'abord mesuré sur le Galaxy avec des traces système le 1er octobre. Pendant la lecture de la vidéo, le GPU tournait autour de 440 MHz. Lors d'un changement de diapositive, les images prenaient de 25 à 33 ms et le GPU atteignait son plafond de 800 MHz pendant plus de la moitié de la transition. Le téléphone était au statut thermique « modéré » du système, avec une température de surface de 42 °C, et il bridait son propre GPU pour tenir le coup. La chaleur faussait aussi nos mesures : un téléphone chaud affichait des résultats environ 20 % plus lents qu'un téléphone froid, si bien que chaque comparaison devait alterner les versions à température égale.

Nous avons alors tenté l'expérience évidente : placer la vidéo sur un calque natif que le système d'exploitation compose lui-même, en dehors de l'interface. Même téléphone, même application, même salle : l'interface a cessé de se redessiner pour la vidéo, la fréquence du GPU est tombée de 440 à 121 MHz, et l'image lors d'un changement de diapositive est passée de 25 à 33 ms à 3 à 7 ms. Nous avons livré ce correctif dans l'application Flutter le 1er octobre. Il nous a aussi montré où se trouvait la vraie réponse : dans une application native, la vidéo vit toujours sur un calque système, sur iPhone comme sur Android, donc toute cette catégorie de problèmes disparaît par conception plutôt que par contournement.

Même téléphone, même salle, dix minutes

Les affirmations sur la chaleur ne coûtent rien, alors nous l'avons mesurée. Le 5 octobre, nous avons installé trois versions sur le même Galaxy S24+, l'une après l'autre, chacune pendant dix minutes, sans câble, dans la même salle, en regardant le même écran partagé animé. Avant chaque essai, le téléphone refroidissait.

1. Flutter, première version : l'application telle que nous l'avions d'abord construite, avec la vidéo dessinée par l'interface.
2. Flutter, optimisée : la même application après les correctifs de verre et de vidéo décrits ci-dessus.
3. Native : le nouveau Cliqer Remote.

La première version Flutter redessinait toute son interface 47,6 fois par seconde simplement pour afficher une vidéo, maintenait le GPU à 366 MHz en moyenne et utilisait 1,47 seconde de temps CPU par seconde. L'application native n'a pas dessiné une seule image d'interface en dix minutes : seul le calque vidéo bougeait. Son GPU tournait en moyenne à 129 MHz, son CPU à 0,69 seconde par seconde, et elle a consommé 86 mAh de batterie contre 168 mAh. C'est moitié moins de batterie pour le même travail.

Et la chaleur. En dix minutes, la première version Flutter a fait passer la batterie de 36,2 °C à 42,1 °C, et le téléphone a commencé à se brider. La version Flutter optimisée a pris 1,9 °C. L'application native a pris 0,2 °C. Une intervention dure plus de dix minutes, et c'est cette différence que vous sentez dans votre main.

Pour être juste envers la version Flutter optimisée : elle s'en est approchée. Nos propres correctifs dans Flutter ont éliminé l'essentiel du coût, et le natif ne l'a battue que d'une marge plus faible, 12 % de CPU et 25 % de batterie en moins. Tout tient au point de départ de chacune. La première version correspondait à une bonne application Flutter telle qu'elle se présente d'origine ; le natif obtient un téléphone froid sans contournements.

Notre méthode de mesure, pour que vous puissiez la reproduire : traces Perfetto sur l'appareil (chronologie des images, fréquence du GPU, compteurs de batterie), temps CPU du processus fourni par le noyau, et température de batterie mesurée par le téléphone lui-même, avec la même animation à 60 fps sur l'écran partagé pour chaque essai. Un téléphone et un essai par version : considérez donc ces chiffres comme un test de terrain rigoureux, pas comme un benchmark de laboratoire. L'essai natif a aussi démarré environ 2 °C plus frais, c'est pourquoi nous comparons la hausse.

Ce que nous avons construit à la place

Le nouveau Cliqer Remote est natif sur chaque plateforme, construit sur un seul moteur partagé.

L'interface est native sur chaque plateforme. Sur iPhone et iPad, c'est SwiftUI avec le Liquid Glass du système. Sur Android, c'est Jetpack Compose, avec un véritable flou d'arrière-plan là où la plateforme le permet. Les applications Apple Watch et Wear OS sont natives elles aussi, assez légères pour mettre Suivant et Précédent à votre poignet.

Le moteur est écrit une seule fois, en Rust. Rejoindre une salle, se reconnecter et reprendre après un changement de réseau, recevoir la vidéo de l'écran, envoyer les clics, le laser et l'annotation, le chat, les notes, le minuteur, les appels et l'appairage d'un téléphone avec un ordinateur : tout cela vit dans une seule bibliothèque Rust partagée par les deux applications. Chaque application se contente de dessiner l'interface, de décoder la vidéo avec le décodeur matériel du système et de dialoguer avec la caméra et le micro. Un correctif de protocole est appliqué une fois et livré sur les deux plateformes, et les deux applications ne peuvent pas diverger.

Rust était le choix naturel pour ce moteur : aucun ramasse-miettes qui met une image en pause, la sécurité mémoire sans runtime, et une compilation en une seule petite bibliothèque pour iOS comme pour Android. Il est rapide là où cela compte. Sur Mac, notre moteur met en paquets une image H.264 de 20 Ko en 31 µs, effectue une négociation sécurisée en 198 µs de chaque côté et, dans nos tests, transmet une image vidéo de 100 Ko à l'interface Android en 46 µs (il fallait 440 µs avant que nous optimisions cette frontière). Via un relais, un aller-retour prenait une médiane de 13 à 16 ms dans nos tests.

Plus léger, en plus

Nous avons mesuré les deux versions de la même façon. L'application iPhone telle qu'envoyée à Apple est passée de 27,6 Mo à 10,8 Mo, et ce avec l'application Apple Watch (1,5 Mo) incluse. Le téléchargement pour un téléphone Android, mesuré avec l'outil bundletool de Google pour le même téléphone 64 bits, est passé de 15,6 Mo à 5,8 Mo. Environ un tiers de l'ancienne taille, cela compte quand quelqu'un installe l'application sur le Wi-Fi du lieu à cinq minutes de son passage.

La chasse aux millisecondes ne s'est pas arrêtée au téléphone

Une application mobile plus rapide ne représente que la moitié d'un clic. L'autre moitié, c'est l'ordinateur qui fait tourner la présentation, et pendant la reconstruction des applications, nous nous sommes aussi attaqués à ce côté-là.

Clics : d'une demi-seconde à un dixième

Quand un clic atteint l'application de bureau Cliqer, elle doit faire avancer la présentation, puis indiquer à tout le monde dans la salle quelle diapositive est affichée. Cette seconde étape demandait auparavant son numéro de diapositive à l'application de présentation après chaque clic, et cette requête était lente.

Cliqer 2.3 garde une connexion ouverte avec PowerPoint ou Keynote et lit la position directement à partir de l'étape qu'il vient d'exécuter. Sur Mac, sur 20 essais, le délai médian du clic à la diapositive est passé de 509 ms à 48 ms dans PowerPoint et de 408 ms à 42 ms dans Keynote. Dix pressions rapides, comme celles d'un présentateur qui saute une section, mettaient auparavant 5,3 secondes à se stabiliser. Elles fusionnent désormais en un seul mouvement et aboutissent en 254 ms.

Une vidéo qui suit, même sur un mauvais Wi-Fi

Plus tôt cette année, nous avons découvert pourquoi un écran partagé pouvait se figer plusieurs secondes sur Wi-Fi. Dans Cliqer, la vidéo de l'écran circule sur un canal de données fiable, et la norme sur laquelle repose ce canal attend au moins une seconde entière avant de renvoyer un paquet perdu, en doublant à chaque nouvelle tentative. Chrome utilise 400 ms. Toutes les images derrière celle perdue faisaient la queue, l'hôte forçait ensuite un rafraîchissement complet dans cette même file, et sur une liaison lente il le refaisait encore et encore.

Nous avons aligné les temporisations de renvoi sur les valeurs de Chrome et empêché les rafraîchissements de faire la queue derrière l'arriéré. Dans une simulation réseau avec un modèle de pertes Wi-Fi, un partage en 1080p est passé de 15 à 22 gels d'une seconde ou plus toutes les deux minutes à 0 à 2, et le retard médian sur le direct de 2,3 secondes au maximum à 12 ms. Nous avons aussi plafonné les rafraîchissements complets à un par flux toutes les demi-secondes, car chacun d'eux part vers chaque spectateur : avant ce plafond, un spectateur pouvait recevoir 19 rafraîchissements complets par seconde, soit environ 40 Mbit/s.

Côté téléphone, le décodeur vidéo matériel du Galaxy retenait une image ordinaire pendant environ 60 ms, à peu près une fois par seconde. Demander au décodeur de fonctionner à pleine vitesse a ramené cela à zéro image en retard en 50 secondes. Ce correctif est intégré à l'application Android native.

Ce que nous dirions à une autre équipe

Si vous développez quoi que ce soit en temps réel sur mobile, ces leçons nous ont coûté des jours à apprendre et prennent quelques minutes à appliquer :

1. Mesurez sur votre pire appareil réel, pas sur l'émulateur. Notre émulateur tournait à 60 Hz sur un autre backend graphique et ne pouvait montrer aucun des problèmes de verre.
2. Alternez les versions à température égale. Un téléphone chaud affichait des résultats environ 20 % plus lents. Comparer un essai à froid avec un essai à chaud vous induira en erreur.
3. Comptez vos lectures de flou. Chaque flou d'arrière-plan peut coûter une copie plein écran par image. Regroupez-les, délimitez-les, et n'animez jamais la taille d'une surface floutée.
4. Ne redessinez jamais votre interface pour la vidéo. Placez la vidéo sur un calque composé par le système. C'est de loin le gain le plus important que nous ayons mesuré en GPU, en batterie et en chaleur.
5. Demandez au décodeur matériel une vitesse temps réel. Sur Android, définissez le débit de fonctionnement (operating rate) du décodeur. Une seule ligne a supprimé un blocage de 60 ms chaque seconde.
6. Vérifiez les temporisations de votre transport. Les canaux de données fiables héritent des temporisations de renvoi de normes plus anciennes. Un minimum d'une seconde est une éternité pour de la vidéo en direct.
7. Traitez les rafraîchissements complets comme les images coûteuses qu'ils sont. Plafonnez-les par flux, car chacun part vers chaque spectateur.
8. Fusionnez les rafales d'entrées. Dix pressions doivent donner un seul mouvement de dix, pas dix allers-retours.
9. Lisez ce que vos outils écrivent dans votre build. Une chaîne d'outils en préversion a activé un indicateur de rendu dans notre manifeste Android sans rien demander.

Ce que cela change pour vous

Cliqer Remote est natif sur iPhone, iPad, Android, Apple Watch et Wear OS. Les clics sont plus rapides, le téléphone reste froid et consomme moitié moins de batterie que notre première version, la vidéo est dessinée comme le téléphone est conçu pour la dessiner, et l'application fait environ un tiers de son ancienne taille. L'interface web du présentateur fonctionne toujours dans n'importe quel navigateur, sans aucune installation, pour que personne dans votre salle ne soit jamais laissé de côté.

FAQ