Un lecteur 4K pour les téléviseurs Samsung et LG

Un moteur de navigateur de 2015, dans un salon d'aujourd'hui

Les téléviseurs Samsung et LG exécutent des applications web, ce qui semble un terrain connu jusqu'à ce que l'on regarde sur quoi elles tournent. Un appareil vendu en 2018 est toujours en service, et son moteur correspond à peu près à Chromium 47. Il dispose d'une fraction de la mémoire d'un téléphone et d'un processeur à l'avenant, et on lui demande de décoder de la 4K en même temps qu'il affiche votre interface.

L'application dessine sur une zone fixe de 1920 sur 1080 que le téléviseur met à l'échelle de sa propre dalle : un écran 4K change la netteté et rien d'autre. Cette seule décision a supprimé toute une catégorie de bugs de mise en page avant qu'elle n'existe, et rendu comparables toutes nos mesures sur des matériels très différents.

• Pas de gap en flexbox : l'espacement est une marge sur l'enfant, à chaque fois.
• Pas de CSS grid : toute mise en page est en flexbox ou en positionnement absolu.
• Ni flou ni ombres lourdes : ils coûtent des images que le décodeur vidéo réclame.
• Seuls transform et opacity sont animés, car tout le reste déclenche un calcul de mise en page.

Des contraintes aussi fortes clarifient les choses. Il n'existe qu'une seule façon de construire l'essentiel de l'interface, et c'est la rapide.

La navigation est le produit

Une application mobile est jugée sur son apparence. Une application TV est jugée sur le fait que la télécommande fasse ce que le spectateur attendait. Pas de pointeur, pas de défilement, pas de geste : quatre directions, valider, retour et lecture. Chaque écran est une grille que le spectateur parcourt, et un seul déplacement de focus erroné agace davantage qu'une page lente.

Le focus est donc un modèle explicite, indexé, plutôt qu'une déduction à partir du DOM. Chaque surface sait quelle cellule est active, ce que signifie chaque direction depuis celle-ci, et comment amener le résultat dans le champ de vision. La recherche géométrique n'existe qu'en secours, pour les cas que le modèle ne décrit pas. La répétition des touches est limitée et ramenée à un déplacement par image, afin qu'une pression maintenue fasse défiler à vitesse lisible au lieu de dépasser de vingt lignes.

Des listes fluides sur un processeur de téléviseur

Les listes de chaînes comptent des milliers d'entrées. Les afficher toutes est exclu, et la virtualisation classique provoque encore un nouveau rendu à chaque déplacement du focus, ce qui suffit sur ce matériel à perdre des images.

La fenêtre visible est donc un ensemble fixe de lignes qui ne sont jamais démontées. Déplacer le focus écrit directement le nouveau texte et le nouvel état dans ces lignes, en contournant entièrement le cycle de rendu du framework. Sur un téléviseur réel, le profileur que nous avons intégré à l'application affichait zéro rendu de composant par seconde pendant le défilement : le travail avait quitté le cycle de rendu.

Mesurer sur l'appareil, parce que l'ordinateur portable ment

Tout paraissait instantané dans un navigateur de bureau et poussif sur un vrai téléviseur. Cet écart est la norme sur cette plateforme et explique pourquoi tant d'applications TV sortent lentes. Les téléviseurs du commerce n'offrent aucun outil de développement exploitable : nous avons donc intégré un indicateur de performance à l'application elle-même et l'avons lu depuis le canapé.

Il a immédiatement réorienté le travail. Les temps par image pendant la navigation se situaient entre 165 et 265 millisecondes avec l'aperçu vidéo désactivé, et entre 0,5 et 1,3 seconde avec celui-ci actif. Le goulet d'étranglement n'a jamais été l'interface, mais le décodeur en concurrence pour le même silicium, et aucune optimisation supplémentaire des composants n'y aurait changé quoi que ce soit.

Mesurer d'abord n'est pas une préférence de méthode sur ce type de matériel. C'est la différence entre une semaine de progrès réels et un mois passé à régler la mauvaise couche.

Le backend qu'exige un parc d'appareils

Derrière l'application se trouve un service Spring Boot en Java : registre des appareils, licences et activation, configuration par appareil, et un pipeline de réglages qui permet à un exploitant de modifier le comportement de téléviseurs déjà installés sans publier une nouvelle version.

L'appareil s'identifie une fois au démarrage et reçoit tout ce dont il a besoin en une seule réponse : indicateurs de fonctionnalités, limites, tarifs, l'ensemble. L'application met cela en cache dans IndexedDB et continue de fonctionner quand le réseau, lui, ne fonctionne plus. Les réglages sont cloisonnés par plateforme, si bien qu'un indicateur peut s'appliquer aux appareils Samsung et pas aux autres, et le panneau qui les édite est celui qu'utilise le support au quotidien. C'est du travail backend au service d'une décision produit : pouvoir changer d'avis une fois le logiciel hors de portée.

Passer la validation du magasin

Soumettre une application au magasin Samsung est un projet à part entière. Il exige des icônes et des captures aux dimensions exactes, une description qui survive à la relecture, une classification d'âge conforme à ce que fait réellement l'application, et des conditions légales énonçant clairement ce à quoi le logiciel sert et ce à quoi il ne sert pas.

Nous générons chaque ressource du magasin à partir d'un jeu unique de fichiers vectoriels via un script de build : un changement de marque régénère tout le lot à l'octet près au lieu d'être redessiné à la main. Cela compte plus qu'il n'y paraît. C'est à la deuxième soumission que la plupart des équipes perdent quinze jours.