La recopie des émulateurs Android passe à 60 fps

Quand Device MCP a ajouté les émulateurs Android, les iPhone et les simulateurs iOS étaient déjà recopiés à 60 fps. Pas les émulateurs. Le défilement était saccadé, la vidéo hachée, et un écran chargé pouvait tomber à 10 fps.

La recopie des émulateurs Android passe à 60 fps. Device MCP affiche chaque image que l’émulateur dessine, rendue sur le GPU de votre Mac. Voici la même vidéo YouTube sur le même émulateur, avant et maintenant :

Les chiffres de la vidéo ne sont pas saisis à la main. Ils comptent les nouvelles images de chaque enregistrement, seconde par seconde.

Ce que nous avons mesuré

Un émulateur Pixel 9 Pro sous Android 16, qui lit Big Buck Bunny en plein écran dans YouTube, en 1080p60, sur un MacBook Pro équipé d’une puce M5 Max. Pour chaque configuration, nous avons relevé deux chiffres : la fréquence à laquelle Android lui-même affichait une nouvelle image de la vidéo (d’après les horodatages de SurfaceFlinger), et le nombre de nouvelles images qui arrivaient sur le Mac.

La vidéo est un bon test, mais pas le plus exigeant. Une page qui redessine tout l’écran, comme une animation canvas, ne tournait qu’entre 10 et 15 fps dans les configurations logicielles. C’est de là que venaient les signalements de « 10 fps ».

Deux choses freinaient l’ancienne recopie : la façon dont l’émulateur dessinait, et le chemin que prenait son image jusqu’au Mac.

Premier problème : le rendu logiciel

Un émulateur Android peut dessiner avec le GPU de votre Mac ou en logiciel, sur le CPU. Device MCP démarrait les émulateurs avec -no-window, parce que sa recopie servait de fenêtre à l’émulateur. Sans fenêtre à lui, l’émulateur choisit un moteur de rendu logiciel : SwiftShader ou Lavapipe.

Android 16 aggrave les choses. Sur un Mac, le réglage graphique Automatic de l’émulateur choisit aussi le rendu logiciel pour les images système Android 16 (« API level 36 requires GLES 3.1 »). Un émulateur que vous lancez depuis Android Studio avec les réglages par défaut dessine donc lui aussi en logiciel. Cela suffit pour la plupart des écrans, mais une vidéo ou une animation en plein écran mobilise tous les cœurs disponibles.

Deuxième problème : l’encodage dans Android

Device MCP utilisait scrcpy pour voir l’écran. scrcpy est excellent sur un vrai téléphone : il s’exécute dans Android, capture l’écran et l’encode en H.264 avec l’encodeur vidéo matériel du téléphone.

Un émulateur n’a pas d’encodeur matériel. scrcpy se rabat sur l’encodeur logiciel d’Android, qui tourne sur les processeurs virtuels de l’émulateur, ceux-là mêmes qui dessinent l’app que vous regardez. Dans le test ci-dessus, l’encodeur consommait plus de CPU que tout le reste de l’émulateur, et la recopie recevait environ la moitié des images dessinées par Android. Activer le GPU n’arrangeait rien : scrcpy doit alors rapatrier chaque image depuis le GPU avant de l’encoder, et la recopie tombait entre 3 et 5 fps.

La solution : l’écran propre à l’émulateur

L’émulateur Android dispose déjà d’une voie rapide. Il fait tourner un service gRPC sur votre Mac, et l’un de ses appels, streamScreenshot, envoie chaque nouvelle image de l’écran sous forme de pixels RGB bruts, dès que l’émulateur la dessine. C’est ainsi qu’Android Studio affiche les émulateurs dans sa fenêtre Running Devices.

Device MCP fait désormais de même :

• Il lit directement les images de l’émulateur. Rien n’est encodé ni décodé. Device MCP trouve le service de l’émulateur dans le fichier de découverte que chaque émulateur écrit, convertit chaque image au format de pixels du Mac et l’affiche à l’écran. Une image de Pixel 9 Pro pèse 11 MB : 60 par seconde, cela fait environ 660 MB/s. C’est beaucoup pour un réseau, mais rien pour un Mac qui se parle à lui-même.
• Il démarre les émulateurs avec une fenêtre masquée, sur le GPU. Device MCP exécute désormais emulator -avd <name> -qt-hide-window -gpu host -grpc-use-token, les options qu’Android Studio utilise pour ses émulateurs intégrés, plus le rendu graphique matériel. Si vous avez réglé un AVD sur Software dans Android Studio, Device MCP respecte ce choix.
• scrcpy reste, mais seulement pour la saisie. Son serveur transmet toujours vos clics, vos touches, votre texte et le presse-papiers, avec sa vidéo désactivée. Les touchers arrivent exactement au même endroit qu’avant.

L’Inspector indique le chemin qu’emprunte une recopie. Pour un émulateur, Mirror affiche désormais emulator gRPC, et Quality indique la définition complète de l’écran, en RGB :

Les émulateurs lancés ailleurs

Vous n’avez rien à changer. Quand Device MCP s’apprête à recopier un émulateur qui ne peut pas diffuser à 60 fps (lancé en logiciel par Android Studio, ou par un script avec -no-window), il redémarre lui-même cet émulateur par la voie rapide. L’écran de démarrage s’affiche pendant 15 à 20 secondes, et l’appel MCP d’un agent attend que l’émulateur soit revenu. Cela arrive une fois par émulateur, à chaque lancement de Device MCP.

Quelques points à savoir :

• Le premier redémarrage est un démarrage à froid. Un instantané Quick Boot enregistré pendant un rendu logiciel ne se charge pas sur le GPU : l’app qui était ouverte se ferme. Vos apps installées et leurs données restent. Les redémarrages suivants conservent leur instantané.
• Il met fin à une session de débogage. Si Android Studio exécutait ou déboguait votre app sur cet émulateur, cette session s’arrête quand Device MCP le redémarre. La fenêtre Running Devices d’Android Studio retrouve l’émulateur d’elle-même.
• Vos propres options priment. Un émulateur lancé avec des options que Device MCP ne passerait pas, comme -writable-system, -http-proxy, -port ou un -gpu logiciel, reste exactement tel quel. Il est recopié aussi vite qu’il le peut.

Ce que cela change pour les agents

Les captures d’écran de votre agent viennent d’Android lui-même, comme avant. Mais Device MCP lit aussi l’image de la recopie quand un agent demande ce qui est à l’écran et que l’arborescence d’accessibilité ne peut pas le dire, par exemple dans un jeu ou une vue web. Il reconnaît alors le texte dans l’image. Cette image est désormais l’écran complet en 2856×1280, sans compression, au lieu d’une image H.264 réduite à 2048 pixels : les petits textes ressortent plus nettement.

Notre méthode de mesure

La vidéo réunit deux enregistrements de la fenêtre de Device MCP, réalisés l’un après l’autre avec le même émulateur, la même vidéo YouTube et le même réglage de qualité, puis alignés sur les changements de plan du film. Le flux de l’émulateur n’envoie une image que lorsque l’écran change : chaque mise à jour compte donc comme une nouvelle image. Le décodeur de scrcpy affiche aussi des images presque identiques à la précédente : pour l’ancien chemin, nous ne comptons donc que les images qui changent visiblement. L’enregistreur d’écran lui-même capte 57 ou 58 images sur 60, c’est pourquoi le compteur de la vidéo s’arrête juste en dessous de 60. La colonne « Android dessine » provient des horodatages d’images de SurfaceFlinger, et ceux d’Android Studio, de la lecture du flux même que lit sa fenêtre Running Devices. Vos chiffres varieront selon votre Mac, l’AVD et ce qui est à l’écran, mais l’écart demeure.

Essayez-le

Mettez à jour Device MCP, lancez un émulateur depuis la barre latérale et affichez quelque chose qui bouge.

Big Buck Bunny © copyright 2008, Blender Foundation, peach.blender.org, sous licence CC BY 3.0.