Os emuladores Android agora são espelhados a 60 fps

Quando o Device MCP ganhou os emuladores Android, iPhones e simuladores do iOS já eram espelhados a 60 fps. Os emuladores, não. A rolagem parecia picotada, os vídeos engasgavam, e uma tela com muita coisa acontecendo podia cair para 10 fps.

Os emuladores Android agora são espelhados a 60 fps. O Device MCP mostra cada quadro que o emulador desenha, renderizado na GPU do seu Mac. Este é o mesmo vídeo do YouTube no mesmo emulador, antes e agora:

Os números no vídeo não foram digitados à mão. Eles contam as imagens novas em cada gravação, segundo a segundo.

O que medimos

Um emulador Pixel 9 Pro com Android 16, reproduzindo Big Buck Bunny em tela cheia no YouTube a 1080p60, em um MacBook Pro com M5 Max. Para cada configuração, lemos dois números: com que frequência o próprio Android colocou um novo quadro do vídeo na tela (pelos timestamps do próprio SurfaceFlinger) e quantas imagens novas chegaram ao Mac.

Vídeo é um teste justo, mas não o mais difícil. Uma página que redesenha a tela inteira, como uma animação em canvas, era desenhada a apenas 10 a 15 fps nas configurações por software. É daí que vinham os relatos de "10 fps".

Duas coisas seguravam o espelhamento antigo: como o emulador desenhava e como a imagem dele chegava ao Mac.

Problema um: desenhar por software

Um emulador Android pode desenhar com a GPU do seu Mac ou por software, na CPU. O Device MCP iniciava os emuladores com -no-window, porque o espelhamento dele fazia o papel da janela do emulador. Sem uma janela própria, o emulador escolhe um renderizador por software: SwiftShader ou Lavapipe.

O Android 16 piora as coisas. No Mac, a opção de gráficos Automatic do emulador também escolhe software para as imagens do Android 16 ("API level 36 requires GLES 3.1"). Ou seja, um emulador que você inicia pelo Android Studio com as configurações padrão também desenha por software. Isso basta para a maioria das telas, mas um vídeo ou uma animação em tela cheia consome todos os núcleos que conseguir.

Problema dois: codificar dentro do Android

O Device MCP usava o scrcpy para ver a tela. O scrcpy é excelente em um celular real: ele roda dentro do Android, captura a tela e a codifica em H.264 com o codificador de vídeo de hardware do celular.

Um emulador não tem codificador de hardware. O scrcpy recorre ao codificador por software do Android, que roda nas CPUs virtuais do próprio emulador, as mesmas CPUs que estão desenhando o app que você está vendo. No teste acima, o codificador usou mais CPU do que qualquer outra coisa no emulador, e o espelhamento recebeu cerca de metade dos quadros que o Android desenhou. Ativar a GPU não ajudou: o scrcpy passa a ter que copiar cada quadro de volta da GPU antes de codificá-lo, e o espelhamento caiu para 3 a 5 fps.

A solução: a tela do próprio emulador

O emulador Android já tem uma saída rápida. Ele roda um serviço gRPC no seu Mac, e uma das chamadas dele, streamScreenshot, envia cada novo quadro da tela como pixels RGB simples, no instante em que o emulador o desenha. É assim que o Android Studio mostra os emuladores na janela Running Devices.

O Device MCP agora faz o mesmo:

• Ele lê os quadros do emulador diretamente. Nada é codificado nem decodificado. O Device MCP encontra o serviço do emulador no arquivo de descoberta que todo emulador grava, converte cada quadro para o formato de pixel do Mac e o coloca na tela. Um quadro do Pixel 9 Pro tem 11 MB, então 60 por segundo dão cerca de 660 MB/s. É muito para uma rede, mas não é nada para um Mac conversando consigo mesmo.
• Ele inicia os emuladores com a janela oculta, na GPU. O Device MCP agora executa emulator -avd <name> -qt-hide-window -gpu host -grpc-use-token: as flags que o Android Studio usa nos emuladores embutidos dele, mais os gráficos por hardware. Se você configurou um AVD como Software no Android Studio, o Device MCP respeita isso.
• O scrcpy continua, só para a entrada. O servidor dele ainda envia seus cliques, teclas, texto e área de transferência, com o vídeo desligado. Os toques caem exatamente onde caíam antes.

O Inspector mostra qual caminho um espelhamento usa. Para um emulador, Mirror agora mostra emulator gRPC, e Quality mostra o painel completo, em RGB:

Emuladores que você iniciou em outro lugar

Você não precisa mudar nada. Quando o Device MCP vai espelhar um emulador que não consegue transmitir a 60 fps (um que o Android Studio iniciou por software, ou que um script iniciou com -no-window), ele reinicia esse emulador do jeito rápido, sozinho. A tela de inicialização aparece por 15 a 20 segundos, e a chamada MCP de um agente espera até ele voltar. Isso acontece uma vez por emulador a cada execução do Device MCP.

Algumas coisas para saber:

• A primeira reinicialização é uma inicialização a frio. Um snapshot do Quick Boot salvo enquanto o emulador desenhava por software não carrega na GPU, então o app que estava aberto é fechado. Os apps instalados e os dados deles continuam lá. As reinicializações seguintes mantêm o snapshot.
• A reinicialização encerra uma sessão de depuração. Se o Android Studio estava rodando ou depurando seu app nesse emulador, essa sessão termina quando o Device MCP o reinicia. A janela Running Devices do Android Studio volta a mostrar o emulador sozinha.
• Suas próprias flags prevalecem. Um emulador iniciado com opções que o Device MCP não usaria, como -writable-system, -http-proxy, -port ou um -gpu por software, fica exatamente como está. Ele é espelhado na velocidade que conseguir.

O que isso muda para os agentes

As capturas de tela do seu agente vêm do próprio Android, como antes. Mas o Device MCP também lê a imagem do espelhamento quando um agente pergunta o que há na tela e a árvore de acessibilidade não sabe dizer, por exemplo em um jogo ou em uma web view. Ele reconhece o texto na imagem. Essa imagem agora é o painel completo de 2856×1280, sem compressão, em vez de um quadro H.264 reduzido para 2048 pixels, então textos pequenos saem mais limpos.

Como medimos

O vídeo são duas gravações da janela do Device MCP, feitas uma depois da outra com o mesmo emulador, o mesmo vídeo do YouTube e a mesma configuração de qualidade, e depois alinhadas pelos cortes de cena do filme. O stream do emulador só envia um quadro quando a tela muda, então cada atualização conta como uma imagem nova. O decodificador do scrcpy também mostra quadros que quase não diferem do anterior, então, no caminho antigo, contamos só os quadros que mudam visivelmente. O próprio gravador de tela captura 57 ou 58 de cada 60 quadros, e é por isso que o contador do vídeo para um pouco antes de 60. A coluna "O Android desenha" vem dos timestamps de quadros do SurfaceFlinger, e os números do Android Studio vêm da leitura do mesmo stream que a janela Running Devices dele lê. Seus números vão variar conforme o Mac, o AVD e o que estiver na tela, mas a diferença se mantém.

Experimente

Atualize o Device MCP, inicie um emulador pela barra lateral e reproduza algo que se mexa.

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