Los emuladores de Android ahora se ven a 60 fps

Cuando Device MCP añadió los emuladores de Android, la duplicación de los iPhone y de los simuladores de iOS ya iba a 60 fps. La de los emuladores, no. El desplazamiento se veía entrecortado, los videos daban saltos y una pantalla con mucho movimiento podía bajar a 10 fps.

La pantalla de los emuladores de Android ahora se duplica a 60 fps. Device MCP muestra cada fotograma que dibuja el emulador, renderizado en la GPU de tu Mac. Este es el mismo video de YouTube en el mismo emulador, antes y ahora:

Los números del video no están escritos a mano. Cuentan las imágenes nuevas de cada grabación, segundo a segundo.

Qué medimos

Un emulador Pixel 9 Pro con Android 16, reproduciendo Big Buck Bunny a pantalla completa en YouTube a 1080p60, en un MacBook Pro con M5 Max. En cada configuración tomamos dos cifras: cada cuánto ponía Android en pantalla un fotograma nuevo del video (según las marcas de tiempo del propio SurfaceFlinger) y cuántas imágenes nuevas llegaban al Mac.

El video es una prueba razonable, pero no la más difícil. Una página que vuelve a dibujar toda la pantalla, como una animación en canvas, solo llegaba a entre 10 y 15 fps en las configuraciones por software. De ahí venían los "10 fps" que nos reportaron.

Dos cosas frenaban la duplicación anterior: cómo dibujaba el emulador y cómo llegaba su imagen al Mac.

Primer problema: dibujar por software

Un emulador de Android puede dibujar con la GPU de tu Mac o por software, en la CPU. Device MCP iniciaba los emuladores con -no-window, porque su duplicación hacía de ventana del emulador. Sin ventana propia, el emulador elige un renderizador por software: SwiftShader o Lavapipe.

Android 16 lo empeora. En un Mac, el ajuste de gráficos Automatic del emulador también elige software para las imágenes de Android 16 ("API level 36 requires GLES 3.1"). Así que un emulador que inicias desde Android Studio con la configuración predeterminada también dibuja por software. Para la mayoría de las pantallas no pasa nada, pero un video o una animación a pantalla completa acapara todos los núcleos que puede.

Segundo problema: codificar dentro de Android

Device MCP usaba scrcpy para ver la pantalla. scrcpy es excelente en un teléfono real: se ejecuta dentro de Android, captura la pantalla y la codifica en H.264 con el codificador de video por hardware del teléfono.

Un emulador no tiene codificador por hardware. scrcpy recurre entonces al codificador por software de Android, que se ejecuta en las CPU virtuales del propio emulador, las mismas que están dibujando la app que estás viendo. En la prueba anterior, el codificador consumía más CPU que cualquier otra cosa del emulador, y a la duplicación llegaba más o menos la mitad de los fotogramas que dibujaba Android. Activar la GPU no ayudó: scrcpy tiene que copiar entonces cada fotograma de vuelta desde la GPU antes de codificarlo, y la duplicación bajó a entre 3 y 5 fps.

La solución: la pantalla del propio emulador

El emulador de Android ya tiene una vía rápida para sacar su imagen. Ejecuta un servicio gRPC en tu Mac, y una de sus llamadas, streamScreenshot, envía cada fotograma nuevo de la pantalla como píxeles RGB sin más, en el momento en que el emulador lo dibuja. Así es como Android Studio muestra los emuladores en su ventana Running Devices.

Device MCP ahora hace lo mismo:

• Lee los fotogramas del emulador directamente. No se codifica ni se decodifica nada. Device MCP encuentra el servicio del emulador en el archivo de descubrimiento que escribe cada emulador, convierte cada fotograma al formato de píxeles del Mac y lo muestra en pantalla. Un fotograma de un Pixel 9 Pro ocupa 11 MB, así que 60 por segundo son unos 660 MB/s. Es mucho para una red, pero nada para un Mac que habla consigo mismo.
• Inicia los emuladores con una ventana oculta, en la GPU. Device MCP ahora ejecuta emulator -avd <name> -qt-hide-window -gpu host -grpc-use-token, las opciones que usa Android Studio para sus emuladores integrados, más gráficos por hardware. Si configuras un AVD en Software en Android Studio, Device MCP lo respeta.
• scrcpy se queda, solo para la entrada. Su servidor sigue enviando tus clics, teclas, texto y portapapeles, con su video desactivado. Los toques caen exactamente donde caían antes.

El Inspector muestra qué vía usa cada duplicación. En un emulador, Mirror ahora indica emulator gRPC, y Quality muestra el panel completo en RGB:

Emuladores que iniciaste en otro sitio

No tienes que cambiar nada. Cuando Device MCP va a duplicar un emulador que no puede transmitir a 60 fps (uno que Android Studio inició por software, o que un script inició con -no-window), lo reinicia por sí solo de la forma rápida. La pantalla de arranque se ve durante 15 a 20 segundos, y la llamada MCP de un agente espera hasta que vuelve. Ocurre una vez por emulador cada vez que se ejecuta Device MCP.

Algunas cosas que conviene saber:

• El primer reinicio es un arranque en frío. Una instantánea de Quick Boot guardada mientras dibujaba por software no se carga en la GPU, así que se cierra la app que estuviera abierta. Tus apps instaladas y sus datos se conservan. Los reinicios siguientes mantienen su instantánea.
• Termina la sesión de depuración. Si Android Studio estaba ejecutando o depurando tu app en ese emulador, esa sesión se detiene cuando Device MCP lo reinicia. La ventana Running Devices de Android Studio vuelve a mostrar el emulador por sí sola.
• Tus propias opciones mandan. Un emulador iniciado con opciones que Device MCP no usaría, como -writable-system, -http-proxy, -port o un -gpu por software, se deja exactamente como está. Su pantalla se duplica a la velocidad que pueda.

Qué significa para los agentes

Las capturas de pantalla de tu agente vienen del propio Android, como antes. Pero Device MCP también lee la imagen de la duplicación cuando un agente pregunta qué hay en pantalla y el árbol de accesibilidad no lo sabe, por ejemplo en un juego o en una vista web. Reconoce el texto de la imagen. Esa imagen ahora es el panel completo de 2856×1280, sin comprimir, en lugar de un fotograma H.264 reducido a 2048 píxeles, así que el texto pequeño se lee con más claridad.

Cómo lo medimos

El video son dos grabaciones de la ventana de Device MCP, hechas una después de la otra con el mismo emulador, el mismo video de YouTube y el mismo ajuste de calidad, y luego alineadas en los cortes de escena de la película. La transmisión del emulador solo envía un fotograma cuando la pantalla cambia, así que cada actualización cuenta como una imagen nueva. El decodificador de scrcpy también muestra fotogramas que apenas se diferencian del anterior, así que, para la vía antigua, solo contamos los fotogramas que cambian a simple vista. El propio grabador de pantalla capta 57 o 58 de cada 60 fotogramas, por eso el contador del video se queda justo por debajo de 60. La columna "Android dibuja" sale de las marcas de tiempo de los fotogramas de SurfaceFlinger, y las cifras de Android Studio, de leer la misma transmisión que lee su ventana Running Devices. Tus cifras variarán según tu Mac, el AVD y lo que haya en pantalla, pero la diferencia se mantiene.

Pruébalo

Actualiza Device MCP, inicia un emulador desde la barra lateral y reproduce algo que se mueva.

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