Android-Emulatoren spiegeln jetzt mit 60 fps

Als Device MCP Android-Emulatoren dazubekam, wurden iPhones und iOS-Simulatoren schon mit 60 fps gespiegelt. Emulatoren nicht. Scrollen wirkte abgehackt, Videos ruckelten, und ein Bildschirm mit viel Bewegung konnte auf 10 fps fallen.

Android-Emulatoren spiegeln jetzt mit 60 fps. Device MCP zeigt jedes Bild, das der Emulator zeichnet, gerendert auf der GPU deines Macs. Hier siehst du dasselbe YouTube-Video auf demselben Emulator, vorher und jetzt:

Die Zahlen im Video sind nicht von Hand eingetragen. Sie zählen Sekunde für Sekunde die neuen Bilder in jeder Aufnahme.

Was wir gemessen haben

Ein Pixel 9 Pro-Emulator mit Android 16 spielt Big Buck Bunny in YouTube im Vollbild mit 1080p60 ab, auf einem MacBook Pro mit M5 Max. Für jedes Setup haben wir zwei Zahlen erfasst: wie oft Android selbst ein neues Bild des Videos auf den Bildschirm gebracht hat (laut den Zeitstempeln von SurfaceFlinger) und wie viele neue Bilder beim Mac ankamen.

Video ist ein fairer Test, aber nicht der schwerste. Eine Seite, die den ganzen Bildschirm neu zeichnet, etwa eine Canvas-Animation, kam in den Software-Setups nur auf 10 bis 15 fps. Daher stammen die Berichte über „10 fps“.

Zwei Dinge haben die alte Spiegelung ausgebremst: wie der Emulator gezeichnet hat und wie sein Bild zum Mac kam.

Problem eins: Zeichnen per Software

Ein Android-Emulator kann mit der GPU deines Macs zeichnen oder per Software auf der CPU. Device MCP hat Emulatoren bisher mit -no-window gestartet, weil seine Spiegelung das Fenster des Emulators ersetzt hat. Ohne eigenes Fenster wählt der Emulator einen Software-Renderer: SwiftShader oder Lavapipe.

Android 16 macht es noch schlimmer. Auf einem Mac wählt die Grafikeinstellung Automatic des Emulators auch für Android-16-Images Software („API level 36 requires GLES 3.1“). Ein Emulator, den du in Android Studio mit den Standardeinstellungen startest, zeichnet also ebenfalls per Software. Für die meisten Bildschirme reicht das, aber ein Video oder eine Animation im Vollbild beansprucht jeden Kern, den es gibt.

Problem zwei: Encodieren innerhalb von Android

Device MCP hat scrcpy genutzt, um den Bildschirm zu sehen. Auf einem echten Smartphone ist scrcpy hervorragend: Es läuft innerhalb von Android, nimmt das Display auf und encodiert es mit dem Hardware-Video-Encoder des Smartphones in H.264.

Ein Emulator hat keinen Hardware-Encoder. scrcpy weicht dann auf den Software-Encoder von Android aus, der auf den virtuellen CPUs des Emulators läuft, also auf denselben CPUs, die gerade die App zeichnen, die du dir ansiehst. Im Test oben hat der Encoder mehr CPU verbraucht als alles andere im Emulator, und bei der Spiegelung kam nur etwa die Hälfte der Bilder an, die Android gezeichnet hat. Die GPU einzuschalten half nicht: scrcpy muss dann jedes Bild erst von der GPU zurückkopieren, bevor es encodiert wird, und die Spiegelung fiel auf 3 bis 5 fps.

Die Lösung: der eigene Bildschirm des Emulators

Der Android-Emulator hat schon einen schnellen Ausweg eingebaut. Er betreibt auf deinem Mac einen gRPC-Dienst, und einer seiner Aufrufe, streamScreenshot, schickt jedes neue Bild des Bildschirms als einfache RGB-Pixel, sobald der Emulator es zeichnet. So zeigt Android Studio Emulatoren in seinem Fenster Running Devices an.

Device MCP macht jetzt dasselbe:

• Es liest die Bilder des Emulators direkt. Nichts wird encodiert oder dekodiert. Device MCP findet den Dienst des Emulators in der Discovery-Datei, die jeder Emulator schreibt, wandelt jedes Bild in das Pixelformat des Macs um und bringt es auf den Bildschirm. Ein Bild des Pixel 9 Pro ist 11 MB groß, 60 davon pro Sekunde sind also etwa 660 MB/s. Für ein Netzwerk ist das viel, aber nichts für einen Mac, der mit sich selbst spricht.
• Es startet Emulatoren mit verstecktem Fenster, auf der GPU. Device MCP führt jetzt emulator -avd <name> -qt-hide-window -gpu host -grpc-use-token aus, also die Flags, die Android Studio für seine eingebetteten Emulatoren nutzt, plus Hardware-Grafik. Wenn du ein AVD in Android Studio auf Software stellst, respektiert Device MCP das.
• scrcpy bleibt, aber nur für die Eingabe. Sein Server überträgt weiterhin deine Klicks, Tasten, Texte und die Zwischenablage, mit abgeschaltetem Video. Berührungen landen genau da, wo sie vorher gelandet sind.

Der Inspector zeigt, welchen Weg eine Spiegelung nimmt. Bei einem Emulator steht unter Mirror jetzt emulator gRPC, und Quality zeigt die volle Displayauflösung in RGB:

Emulatoren, die du anderswo gestartet hast

Du musst nichts ändern. Wenn Device MCP einen Emulator spiegeln soll, der nicht mit 60 fps streamen kann (einen, den Android Studio per Software gestartet hat, oder einen, den ein Skript mit -no-window gestartet hat), startet es diesen Emulator von selbst neu, auf dem schnellen Weg. Der Startbildschirm ist 15 bis 20 Sekunden zu sehen, und der MCP-Aufruf eines Agenten wartet, bis der Emulator wieder da ist. Das passiert für jeden Emulator einmal, solange Device MCP läuft.

Gut zu wissen:

• Der erste Neustart ist ein Kaltstart. Ein Quick-Boot-Snapshot, der beim Zeichnen per Software gespeichert wurde, lädt nicht auf der GPU, deshalb schließt sich die App, die gerade offen war. Deine installierten Apps und ihre Daten bleiben erhalten. Spätere Neustarts behalten ihren Snapshot.
• Er beendet eine Debug-Sitzung. Wenn Android Studio deine App auf diesem Emulator ausgeführt oder debuggt hat, endet diese Sitzung, sobald Device MCP den Emulator neu startet. Das Fenster Running Devices in Android Studio übernimmt den Emulator danach von selbst wieder.
• Deine eigenen Flags haben Vorrang. Ein Emulator, der mit Optionen gestartet wurde, die Device MCP nicht setzen würde, etwa -writable-system, -http-proxy, -port oder -gpu mit einem Software-Renderer, bleibt genau so, wie er ist. Er spiegelt so schnell, wie er eben kann.

Was das für Agenten bedeutet

Die Bildschirmfotos deines Agenten kommen wie bisher von Android selbst. Device MCP liest aber auch das Bild der Spiegelung, wenn ein Agent fragt, was auf dem Bildschirm ist, und der Accessibility-Baum es nicht sagen kann, etwa in einem Spiel oder einer Web-View. Es erkennt dann den Text im Bild. Dieses Bild hat jetzt die volle Displayauflösung von 2856×1280, unkomprimiert, statt eines auf 2048 Pixel verkleinerten H.264-Frames, deshalb wird kleiner Text sauberer erkannt.

Wie wir gemessen haben

Das Video besteht aus zwei Aufnahmen des Fensters von Device MCP, direkt nacheinander gemacht mit demselben Emulator, demselben YouTube-Video und derselben Qualitätseinstellung und dann an den Szenenschnitten des Films ausgerichtet. Der Stream des Emulators schickt nur dann ein Bild, wenn sich der Bildschirm ändert, deshalb zählt jede Aktualisierung als neues Bild. Der Decoder von scrcpy zeigt auch Bilder, die sich kaum vom vorherigen unterscheiden, deshalb zählen wir beim alten Weg nur Bilder, die sich sichtbar ändern. Die Bildschirmaufnahme selbst erfasst 57 oder 58 von 60 Bildern, deshalb bleibt der Zähler im Video knapp unter 60. Die Spalte „Android zeichnet“ stammt aus den Frame-Zeitstempeln von SurfaceFlinger, die Zahlen für Android Studio aus demselben Stream, den sein Fenster Running Devices liest. Deine Zahlen hängen von deinem Mac, dem AVD und dem Bildschirminhalt ab, aber der Abstand bleibt.

Probier es aus

Aktualisiere Device MCP, starte einen Emulator über die Seitenleiste und spiel etwas ab, das sich bewegt.

Big Buck Bunny © Copyright 2008, Blender Foundation, peach.blender.org, lizenziert unter CC BY 3.0.