Em outubro de 2026, a pergunta “ARM vs x86” deixou de ser uma discussão académica entre engenheiros de silício e passou a ser uma decisão de compra real. Com o lançamento do Snapdragon G2 Gen 2 no ARC X1, do Snapdragon G1 Gen 2 no Anbernic RG 55G1, do Ryzen AI Max+ 388 no GPD WIN 5 e dos primeiros handhelds com Intel Arc G3 Extreme, há mais variedade de arquitetura num handheld de jogos do que em qualquer altura da última década. O problema é que a maioria das comparações entre ARM e x86 que circulam online baseia-se em folhas de especificações, não em números medidos no teu próprio dispositivo.

Este tutorial ensina-te a montar o teu próprio banco de testes ARM vs x86 em 12 passos, usando as mesmas ferramentas que os laboratórios de hardware usam: Geekbench 6, 3DMark Wild Life Extreme, scripts de monitorização térmica via ADB e um comparador em Python que tu próprio vais escrever. No final, vais ter dados concretos sobre qual arquitetura compensa para o teu caso de uso, seja emulação, jogos nativos para Windows ou jogos Android, em vez de confiares em afirmações genéricas sobre desempenho. O panorama de handhelds cobre agora desde o catálogo contínuo de novos lançamentos até dispositivos de referência acima dos 1.900 dólares, por isso vale a pena saber testar antes de gastar.

Google · Fontes preferidas

Não perca as novas histórias de tecnologia no Google

Adicione o Shattered uma vez na app Google e os nossos artigos passam a aparecer nas suas sugestões.

Adicionar agora

Porque é que a arquitetura voltou a ser uma guerra de handhelds em 2026

Durante anos, “handheld de jogos” foi sinónimo de x86, com a Valve a definir a categoria com o Steam Deck e fabricantes como a ASUS e a Lenovo a seguirem com chips AMD. O ARM ficava reservado a emuladores retro baratos. Isso mudou de forma visível em 2026. A Qualcomm não só lançou o Snapdragon G1 Gen 2 e o G2 Gen 2 como está a posicioná-los explicitamente para jogos Android, não apenas para emulação, com o ARC X1 a entrar em acesso antecipado a 2 de outubro de 2026. Isto é um sinal de que a Qualcomm quer competir diretamente nesta categoria, e não apenas servir o segmento de entrada mais barato.

Do lado x86, a resposta tem sido subir a fasquia em vez de competir em preço. O GPD WIN 5 com Ryzen AI Max+ 388 vem com a versão completa e não limitada da GPU Radeon 8060S, uma escolha que a AMD reserva normalmente para portáteis de gama alta, e a Intel entrou neste segmento com o Arc G3 Extreme, já disponível em quatro modelos distintos através da OneXPlayer. Há também um Intel Panther Lake mais barato para handhelds que já foi referido em fugas de informação, mas que continua sem lançamento oficial confirmado em outubro de 2026, por isso não deves tratá-lo como opção de compra real enquanto não houver disponibilidade confirmada em loja.

O resultado prático desta disputa é bom para quem compra: há agora opções ARM e x86 em praticamente todas as faixas de preço, desde os 139 dólares do Anbernic RG 55G1 até aos quase 2.000 dólares de um OneXPlayer topo de gama. Mas também significa que escolher “a melhor arquitetura” sem dados próprios é mais arriscado do que era há três anos, quando x86 era praticamente a única opção séria para quem queria jogar a biblioteca completa da Steam num dispositivo portátil.

Pré-requisitos: hardware, software e tempo necessário

Antes de arrancares, confirma que tens isto reunido. Não precisas dos três dispositivos mais caros do mercado, mas precisas de pelo menos um handheld ARM e um handheld x86 para a comparação fazer sentido.

  • Um handheld com chip ARM, por exemplo um Snapdragon G1 Gen 2, G2 Gen 2 ou um SoC Cortex-A78/A76 equivalente, com Android 13 ou superior
  • Um handheld com chip x86, por exemplo um Ryzen AI Max+ 388, Ryzen Z2 Extreme ou Intel Arc G3 Extreme, com Windows 11 24H2 ou superior
  • Geekbench 6.3 ou mais recente (versão Android e versão Windows, gratuitas para teste CPU, Pro paga para exportação CSV completa)
  • 3DMark Wild Life Extreme 2.3 para o teste de GPU cruzado entre plataformas
  • Android Platform Tools (ADB) 36.0 ou mais recente, instalado no computador que vai recolher os dados
  • Python 3.11 ou mais recente, com as bibliotecas json e csv (ambas nativas, sem instalação extra)
  • HWiNFO64 8.06 para monitorização térmica no lado x86
  • Um cronómetro ou a app de cronómetro do telemóvel, para os testes de autonomia
  • Entre 45 e 60 minutos de tempo livre, mais tempo de carregamento entre testes de bateria

Se ainda não tens um handheld x86 para comparar, vale a pena consultar o nosso comparativo entre o Steam Deck OLED e o ROG Ally X antes de decidires o que comprar para este teste.

Passo 1: Entende as diferenças reais entre ARM e x86

ARM e x86 são conjuntos de instruções (ISA) diferentes. O x86, usado pela AMD e pela Intel, é um conjunto de instruções complexo (CISC), construído sobre décadas de extensões sucessivas. O ARM é um conjunto de instruções reduzido (RISC), com instruções mais simples e previsíveis. Na prática de jogos, isto traduz-se em três diferenças que importam para o teu teste.

Primeiro, a eficiência energética. Os núcleos ARM, como o Cortex-A78 usado no Anbernic RG 55G1, consomem menos energia por instrução executada, o que normalmente resulta em mais horas de jogo com a mesma bateria. Segundo, a compatibilidade de software. Um jogo compilado para x86 não corre nativamente num chip ARM sem uma camada de tradução, e o inverso também é verdade. Terceiro, o ecossistema gráfico. Os handhelds x86 herdam décadas de drivers DirectX e Vulkan maduros, enquanto os handhelds ARM dependem normalmente de OpenGL ES e Vulkan em Android, com suporte mais recente e menos testado para jogos pesados.

Esta distinção importa porque qualquer benchmark de CPU ou GPU que corra nativamente em ambas as arquiteturas (como o Geekbench 6 ou o 3DMark) mede o desempenho em bruto do silício. Mas um jogo real, que pode precisar de tradução de código, mede algo diferente: a eficiência de toda a pilha de software por cima do chip. É por isso que este tutorial separa os dois tipos de teste em passos distintos, em vez de misturar tudo num único número.

CISC vs RISC: o que isto significa na prática do teu teste

Um núcleo x86 decodifica instruções de comprimento variável, o que exige mais transístores dedicados só à etapa de decodificação antes de qualquer cálculo começar. Um núcleo ARM trabalha com instruções de comprimento fixo, mais simples de decodificar, o que liberta espaço no chip para mais unidades de execução ou para um consumo mais baixo à mesma área de silício. Isto não significa que ARM seja sempre mais rápido, significa apenas que o ponto de partida arquitetural é diferente, e por isso a comparação justa é sempre ao nível do dispositivo completo, não ao nível do papel com especificações da ISA.

Porque a tradução de código tem sempre um custo

Quando um jogo compilado para x86 corre num chip ARM através de uma camada de tradução, cada instrução x86 tem de ser convertida, em tempo real, numa ou mais instruções ARM equivalentes. Esse trabalho extra consome ciclos de CPU que, de outra forma, estariam a correr lógica do próprio jogo. Camadas modernas como o Box64 usam técnicas de cache de tradução para reduzir este custo em código repetido, mas nunca o eliminam por completo. É por isso que o Passo 7 deste tutorial mede especificamente a perda de desempenho da tradução, em vez de assumir um número fixo que seria diferente para cada jogo e cada chip.

Passo 2: Escolhe os dispositivos de teste certos

A tabela seguinte resume os quatro handhelds mais relevantes para uma comparação ARM vs x86 em outubro de 2026, com preços e especificações confirmadas nos respetivos lançamentos. Usa-a para escolher qual par testar primeiro, dependendo do orçamento que tens disponível.

DispositivoArquiteturaChipPreço aproximadoSistema
Anbernic RG 55G1ARMSnapdragon G1 Gen 2 (Cortex-A78, Adreno A12)139 $Android 14
ARC X1ARMSnapdragon G2 Gen 2307 $Android
GPD WIN 5x86Ryzen AI Max+ 388 (Radeon 8060S)1.722 $Windows 11
OneXPlayer (Arc G3 Extreme)x86Intel Arc G3 Extremeaté 1.999 $Windows 11

Nota que há uma diferença de preço enorme entre os dois extremos: o RG 55G1 ARM custa menos de um décimo do OneXPlayer com Arc G3 Extreme. Isto por si só já é um dado relevante, porque significa que uma comparação direta de desempenho em bruto não conta a história completa. Se o teu objetivo é emulação retro ou jogos Android, o par ARM pode ser suficiente. Se o objetivo é correr a biblioteca Steam completa, o x86 continua a ser a escolha mais segura, como já detalhámos no comparativo entre o MSI Claw 8 AI+ e o Steam Deck OLED. A fabricante OneXPlayer já tem quatro modelos distintos com Arc G3 Extreme a enviar, o que mostra que o lado x86 de gama alta está a acelerar o lançamento de produtos este trimestre.

Passo 3: Prepara o ambiente de benchmark no dispositivo ARM

Liga o handheld ARM ao computador por USB, ativa as opções de programador e a depuração USB nas definições do Android, e confirma que o ADB reconhece o aparelho. Depois instala os três APKs de benchmark via linha de comandos, em vez da loja de aplicações, para garantir que usas exatamente a mesma versão em ambos os dispositivos.

adb devices
# devias ver o teu handheld ARM listado como "device", não "unauthorized"

adb install -r geekbench6-6.3.0.apk
adb install -r 3dmark-2.3.apk
adb install -r cpu-z-2.15.apk

# confirma que as três apps estão instaladas
adb shell pm list packages | grep -E "geekbench|3dmark|cpuz"

Antes de correr qualquer teste, fecha todas as apps em segundo plano e deixa o dispositivo em repouso durante dois minutos para a temperatura estabilizar. Um chip ARM que acabou de sair de uma sessão de jogo intensa vai dar resultados de benchmark mais baixos do que um chip em repouso, e isso vai inflacionar artificialmente a vantagem do x86 se não controlares esta variável.

Passo 4: Prepara o ambiente de benchmark no dispositivo x86

No handheld x86, instala o Geekbench 6, o 3DMark e o HWiNFO64 diretamente das páginas oficiais. Depois de instalado, abre o HWiNFO64 em modo sensores apenas, sem o resumo gráfico, para reduzir a carga do próprio software de monitorização sobre os resultados.

# PowerShell, a correr como administrador no handheld x86
winget install Primate-Labs.Geekbench.6
winget install HWiNFO.HWiNFO64

# desativa temporariamente o Windows Update durante os testes
# para não teres picos de CPU inesperados a meio de um benchmark
Stop-Service -Name wuauserv -Force

Liga o handheld x86 à corrente durante a instalação, mas desliga o carregador antes de correres qualquer teste de desempenho. Um dispositivo ligado à corrente pode manter clocks mais altos de forma artificial, o que distorce a comparação com o handheld ARM, que normalmente é testado só com a bateria.

Passo 5: Benchmark de CPU com o Geekbench 6 lado a lado

Corre o teste de CPU do Geekbench 6 três vezes em cada dispositivo, com dois minutos de intervalo entre corridas, e guarda sempre o resultado do meio, não o primeiro nem o melhor. O primeiro teste tende a ser penalizado pelo arranque a frio dos clocks, e o melhor resultado tende a refletir um pico de turbo que não se sustenta durante uma sessão de jogo real.

# recolhe o resultado do Geekbench diretamente do dispositivo ARM
adb shell am start -n com.primatelabs.geekbench6/.HomeActivity
# corre o teste manualmente na app, depois exporta o link do resultado

adb shell dumpsys package com.primatelabs.geekbench6 | grep versionName
# confirma a versão exata usada, para documentares no teu relatório final

Regista sempre quatro números por dispositivo: a pontuação single-core, a pontuação multi-core, a frequência base anunciada pelo fabricante e a temperatura ambiente da sala onde fizeste o teste. A temperatura ambiente importa mais do que a maioria das pessoas pensa, porque um handheld num quarto a 28°C vai sofrer throttling mais cedo do que o mesmo dispositivo a 20°C, e isso afeta sobretudo os chips x86 de maior densidade térmica.

Para jogos, a pontuação single-core importa mais do que a maioria dos compradores assume. Muitos motores de jogo ainda dependem fortemente de um único núcleo para a lógica principal e para a física, enquanto a pontuação multi-core pesa mais em tarefas como compressão de texturas em tempo real ou streaming de mundo aberto. Se jogas sobretudo títulos indie ou 2D, dá mais peso à pontuação single-core na tua decisão final. Se jogas títulos de mundo aberto recentes, a pontuação multi-core tende a prever melhor a experiência real.

Passo 6: Benchmark de GPU com o 3DMark Wild Life Extreme

O 3DMark Wild Life Extreme é hoje a ferramenta mais próxima de um teste cross-platform real para GPU, porque corre uma cena 3D idêntica tanto em Android como em Windows através da API Vulkan. Corre o teste “Extreme Stress Test”, não apenas o teste único, porque este modo repete a cena vinte vezes e dá-te uma percentagem de estabilidade, que é o número mais importante para jogos de sessão longa.

Um resultado de estabilidade acima de 95% indica que o dispositivo mantém o desempenho sem throttling relevante. Resultados abaixo de 80% indicam que o chip está a reduzir clocks de forma agressiva depois dos primeiros minutos, o que normalmente se nota mais nos handhelds x86 de fator de forma mais fino, onde a dissipação de calor tem menos espaço físico disponível do que num chip ARM de menor consumo.

Tabela de referência: como ler a percentagem de estabilidade

Estabilidade no stress testO que significaRecomendação prática
95% a 100%Sem throttling relevante, desempenho sustentadoBom para sessões longas sem perda percetível
85% a 94%Throttling leve depois de vários minutosAceitável para a maioria dos jogos, pode notar-se em títulos exigentes
70% a 84%Throttling moderado, queda de clocks visívelConsidera melhorar a ventilação ou baixar definições gráficas
Abaixo de 70%Throttling agressivo, perda de FPS percetível em jogoVerifica a pasta térmica, poeira nas grelhas ou um perfil de energia mais conservador

Passo 7: Testa a tradução x86-para-ARM e a emulação de jogos

Esta é a parte do teste que separa a teoria da prática. Um handheld ARM pode ter números de Geekbench competitivos e ainda assim correr jogos de forma inconsistente, porque a maioria dos jogos Windows precisa de uma camada de tradução para correr em ARM. Se o teu handheld ARM corre Android nativamente, testa diretamente os jogos da Play Store, que já vêm compilados para ARM e não precisam de tradução nenhuma. Se quiseres testar jogos PC em Android, precisas de uma camada como o Winlator, que já explicámos em detalhe num tutorial anterior, e que usa o Box64 para traduzir instruções x86 para ARM em tempo real.

# confirma se o dispositivo ARM suporta a extensão de virtualização
# necessária para correr camadas de tradução com aceleração
adb shell getprop ro.board.platform
adb shell cat /proc/cpuinfo | grep Features

# no lado x86, confirma que não há nenhuma camada de tradução ativa
# (o x86 deve correr tudo nativamente, sem overhead de tradução)
wmic cpu get Name,Architecture

Regista a perda de desempenho em percentagem entre o jogo nativo (quando disponível em ambas as plataformas, como títulos multiplataforma com versão Android e versão Windows) e a versão traduzida. Esta percentagem é o custo real da arquitetura ARM em cenários de compatibilidade, e tende a ser mais alto em jogos com física complexa ou muitos cálculos de ponto flutuante, e mais baixo em jogos 2D ou turn-based.

Passo 8: Mede o throttling térmico sob carga de 30 minutos

Os benchmarks de poucos minutos escondem o problema mais relevante para quem joga a sério: o que acontece ao fim de meia hora. Cria um script que registe a temperatura e a frequência da CPU a cada 30 segundos, enquanto corres um jogo pesado ou um stress test em loop.

Escolhemos 30 minutos como janela de teste porque é aproximadamente a duração de uma sessão de jogo curta mas realista, e é tempo suficiente para qualquer chip moderno, ARM ou x86, sair do seu estado de turbo inicial e estabilizar numa frequência sustentada. Testes mais curtos, de cinco ou dez minutos, tendem a favorecer dispositivos com um turbo inicial agressivo mas pouco sustentável, o que dá uma imagem otimista a mais do desempenho real que vais sentir numa sessão de jogo típica.

#!/bin/bash
# thermal_log.sh - regista temperatura e clock do dispositivo ARM durante 30 min
echo "timestamp,temp_celsius,cpu_freq_mhz" > thermal_log.csv

for i in $(seq 1 60); do
  TS=$(date +%s)
  TEMP=$(adb shell cat /sys/class/thermal/thermal_zone0/temp)
  TEMP_C=$((TEMP / 1000))
  FREQ=$(adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
  FREQ_MHZ=$((FREQ / 1000))
  echo "$TS,$TEMP_C,$FREQ_MHZ" >> thermal_log.csv
  sleep 30
done
echo "Registo completo: thermal_log.csv"

Corre o mesmo princípio no lado x86 com o HWiNFO64 em modo de registo contínuo, exportando para CSV com o mesmo intervalo de 30 segundos. No final, compara os dois ficheiros CSV num gráfico simples: o dispositivo que mantém a frequência mais estável ao longo dos 30 minutos, não o que arranca mais alto, é o que vai dar-te a melhor experiência numa sessão de jogo longa.

Passo 9: Mede a autonomia da bateria durante uma sessão real

Carrega ambos os dispositivos a 100%, desliga o Wi-Fi e o Bluetooth em ambos, fixa o brilho do ecrã no mesmo nível percentual nos dois, e corre o mesmo jogo (ou o jogo mais próximo disponível em ambas as plataformas) até a bateria chegar a 20%. Regista o tempo total em minutos.

# regista o nível de bateria do dispositivo ARM a cada 5 minutos
while true; do
  BATT=$(adb shell dumpsys battery | grep level | awk '{print $2}')
  echo "$(date +%H:%M:%S),$BATT" >> battery_log_arm.csv
  if [ "$BATT" -le 20 ]; then
    echo "Bateria chegou a 20%, teste concluído"
    break
  fi
  sleep 300
done

Divide os 80 pontos percentuais de bateria consumidos pelo tempo total em minutos, e obténs um número de “percentagem por minuto” que podes comparar diretamente entre os dois dispositivos, mesmo que tenham capacidades de bateria diferentes em mAh. Esta normalização é importante, porque comparar minutos absolutos entre um handheld com bateria de 6.000 mAh e outro com 10.000 mAh não te diz nada sobre a eficiência real do chip.

Por exemplo, se o dispositivo ARM gastar os 80 pontos percentuais em 240 minutos, isso dá 0,33% por minuto. Se o dispositivo x86 gastar a mesma percentagem em 160 minutos, isso dá 0,50% por minuto, ou seja, cerca de 50% mais consumo por minuto de jogo. Esta forma de apresentar o resultado é mais útil do que dizer apenas “o ARM durou mais 80 minutos”, porque continua válida mesmo se um dia testares um terceiro dispositivo com uma bateria de capacidade totalmente diferente.

Passo 10: Constrói um script Python para comparar e pontuar os resultados

Depois de teres os números de CPU, GPU, térmica e bateria dos dois dispositivos, o passo mais útil é consolidá-los num único relatório. Este script lê os teus dados num ficheiro JSON simples e produz uma tabela de comparação com uma pontuação ponderada, para que não fiques só com uma lista de números soltos sem conseguires tirar uma conclusão.

# compare_arm_x86.py
import json

def carregar_resultados(caminho):
    with open(caminho, "r", encoding="utf-8") as f:
        return json.load(f)

def pontuar(dados, pesos):
    total = 0
    for metrica, peso in pesos.items():
        total += dados.get(metrica, 0) * peso
    return round(total, 2)

# pesos ajustáveis: aumenta "bateria" se jogas sobretudo fora de casa,
# aumenta "gpu" se jogas sobretudo títulos 3D exigentes
pesos = {
    "cpu_multicore": 0.25,
    "gpu_score": 0.30,
    "estabilidade_termica_pct": 0.25,
    "bateria_pct_por_minuto_invertido": 0.20,
}

arm = carregar_resultados("resultados_arm.json")
x86 = carregar_resultados("resultados_x86.json")

pontuacao_arm = pontuar(arm, pesos)
pontuacao_x86 = pontuar(x86, pesos)

print(f"Pontuação ARM:  {pontuacao_arm}")
print(f"Pontuação x86:  {pontuacao_x86}")
vencedor = "ARM" if pontuacao_arm > pontuacao_x86 else "x86"
print(f"Melhor equilíbrio para o teu perfil de uso: {vencedor}")

Um exemplo ilustrativo de saída, só para veres o formato esperado (os teus números vão ser diferentes, dependendo dos dispositivos que testares):

Pontuação ARM:  71.4
Pontuação x86:  78.9
Melhor equilíbrio para o teu perfil de uso: x86

Guarda os teus dois ficheiros resultados_arm.json e resultados_x86.json com a mesma estrutura de chaves, só muda os valores. Isto significa que podes voltar a correr este mesmo script sempre que atualizares para um novo handheld, sem reescrever nada.

Passo 11 e 12: Testa a compatibilidade de jogos e tira as conclusões finais

Antes de decidires, faz uma lista de pelo menos dez jogos que realmente jogas, e marca se correm nativamente, correm via tradução, ou não correm de todo em cada arquitetura. Esta matriz é mais importante do que qualquer pontuação sintética, porque um chip com 20% menos desempenho em bruto mas 100% de compatibilidade com a tua biblioteca vale mais do que um chip mais rápido que não corre metade dos teus jogos.

Categoria de jogoARM (nativo Android)ARM (via tradução)x86 (Windows nativo)
Jogos mobile/Play StoreSim, suporte totalNão aplicávelNão suportado
Jogos indie 2D levesDepende do porteNormalmente funcionalSim, suporte total
Jogos AAA recentesRaramente disponívelInstável, perda de FPSSim, suporte total
Emulação retro (16-bit e anteriores)Sim, muito eficienteNão aplicávelSim, mas menos eficiente por watt
Jogos com anticheat em kernelNormalmente bloqueadoNormalmente bloqueadoSim, suporte total

Com estes 12 passos completos, cruza a matriz de compatibilidade com a pontuação do script Python. Se jogas principalmente títulos com anticheat ou AAA recentes, o x86 continua a ser a escolha mais segura, como o próprio caso da Nintendo Switch 2 demonstra ao optar por um SoC ARM customizado focado em eficiência em vez de compatibilidade PC. Se o teu uso é emulação, jogos mobile ou títulos indie mais leves, o ganho de autonomia do ARM pode compensar a perda de compatibilidade, tal como mostra o comparativo entre o Retroid Pocket Nova e o AYN Odin 3.

Não existe uma resposta universal a “ARM ou x86”, só existe a resposta certa para a tua lista de jogos e para o teu orçamento. É exatamente por isso que vale mais a pena correr este processo de 12 passos do que ler mais um artigo de opinião sobre qual arquitetura “vai ganhar” o mercado de handhelds nos próximos anos.

Erros comuns ao comparar ARM e x86 (e como os evitar)

  • Comparar benchmarks sintéticos sem testar jogos reais. O Geekbench mede instruções por segundo, não frames por segundo numa cena com física e IA ativas. Usa sempre os dois tipos de teste, nunca só um.
  • Testar com o carregador ligado só num dos dispositivos. Isto infla artificialmente o resultado de quem está ligado à corrente, e é o erro mais comum em comparações feitas à pressa.
  • Ignorar o estado térmico inicial. Um chip que acabou de sair de uma sessão de jogo intensa vai sempre pontuar pior do que o mesmo chip em repouso, independentemente da arquitetura.
  • Usar versões diferentes do mesmo benchmark em cada plataforma. O Geekbench 6.3 no Android e a versão 6.1 no Windows não produzem números comparáveis, porque os algoritmos internos mudam entre versões.
  • Assumir que o preço reflete sempre o desempenho. O OneXPlayer com Arc G3 Extreme custa mais do que dez vezes o Anbernic RG 55G1, mas isso não significa que seja dez vezes “melhor” para o teu caso de uso específico.
  • Esquecer de documentar a temperatura ambiente. Um teste feito em agosto numa sala sem ar condicionado não é comparável a um teste feito em janeiro, e isto afeta mais os chips x86 de maior densidade térmica.
  • Deixar apps em segundo plano a consumir CPU durante o teste. No Android, apps de rede social ou de sincronização de fotos continuam a correr mesmo minimizadas, e no Windows, o Windows Update ou o OneDrive podem arrancar sem aviso a meio de um benchmark. Usa sempre o modo avião combinado com Wi-Fi ligado manualmente, nunca dados móveis em segundo plano.
  • Comparar um dispositivo novo com um dispositivo usado há dois anos. A pasta térmica degrada-se com o tempo, e isso penaliza injustamente o dispositivo mais antigo, independentemente da arquitetura. Se possível, compara sempre dispositivos com idade de utilização semelhante.

Resolução de problemas: 8 cenários reais

  • O ADB não reconhece o dispositivo ARM. Confirma que a depuração USB está ativada, revoga as autorizações USB anteriores nas opções de programador, e volta a ligar o cabo. Em alguns handhelds ARM é preciso também ativar “instalar via USB” separadamente.
  • O Geekbench 6 recusa-se a correr e fecha sozinho. Normalmente é falta de memória livre. Fecha todas as apps em segundo plano e reinicia o dispositivo antes de voltar a tentar.
  • O 3DMark dá um erro de “API Vulkan não suportada”. Confirma que o driver gráfico do teu chip ARM está atualizado através da loja de aplicações do fabricante, não apenas da Play Store.
  • Os resultados de CPU variam mais de 15% entre corridas no mesmo dispositivo. Isto é normalmente throttling térmico entre testes. Aumenta o intervalo de descanso entre corridas de dois para cinco minutos.
  • O script de registo térmico em bash devolve valores de temperatura absurdos, como 85000. O caminho do sensor térmico varia entre fabricantes ARM. Corre adb shell cat /sys/class/thermal/thermal_zone*/type para encontrares a zona térmica correta da CPU no teu modelo específico.
  • O HWiNFO64 não aparece na lista de processos ao exportar CSV. Confirma que escolheste “Sensors-only” no arranque e não “Summary only”, que é o modo que não gera ficheiros de registo contínuo.
  • O script Python dá erro de “KeyError” ao carregar o JSON. As chaves nos dois ficheiros JSON têm de ter exatamente os mesmos nomes. Confirma que escreveste cpu_multicore e não cpu_multi_core ou outra variante nos dois ficheiros.
  • O teste de bateria não termina sozinho ao chegar aos 20%. Confirma que o comando dumpsys battery está a devolver um número e não texto vazio, o que acontece se o dispositivo entrar em suspensão durante o loop. Usa adb shell svc power stayon true antes de começares o teste de autonomia.
  • O 3DMark dá pontuações muito diferentes entre corridas no mesmo dispositivo x86. Confirma no HWiNFO64 se o perfil de energia do Windows está definido para “Alto desempenho” nas duas corridas. Um dispositivo que alterna entre perfis de energia automaticamente vai dar resultados inconsistentes, mesmo com o mesmo chip.
  • O dispositivo ARM aquece muito mais rápido do que esperavas num teste de 30 minutos. Confirma se a capa ou suporte do handheld está a bloquear alguma grelha de ventilação traseira. Muitos handhelds ARM mais baratos, como o RG 55G1, dependem de dissipação passiva, e qualquer obstrução física tem um impacto desproporcional nestes modelos.

Dicas avançadas para ires mais além

Depois de dominares o processo básico, há três formas de tornar os teus próprios testes ainda mais fiáveis. A primeira é correr cada benchmark em dias diferentes, não só em corridas diferentes no mesmo dia, para captar variação de voltagem da rede elétrica e de temperatura ambiente ao longo do tempo. A segunda é guardar todos os ficheiros CSV e JSON num repositório Git simples, mesmo que privado, para conseguires comparar resultados ao longo de meses, por exemplo depois de uma atualização de firmware que prometa melhorias de eficiência.

A terceira dica avançada é expandir o script Python do Passo 10 para gerar gráficos automaticamente com a biblioteca matplotlib, em vez de só imprimir números na consola. Isto é especialmente útil se pensas escrever um relatório para partilhar online, porque um gráfico de linha mostrando o throttling térmico ao longo de 30 minutos comunica muito mais do que uma tabela de números isolados. Também vale a pena consultar o catálogo de especificações de handhelds em bases de dados independentes como o Retro Catalog, que agrega especificações verificadas de centenas de dispositivos ARM e x86, útil para confirmares dados antes de comprares um modelo que ainda não testaste pessoalmente.

A quarta dica avançada é automatizar a recolha de logs térmicos e de bateria num único script que corra os dois em paralelo, em vez de teres de lançar manualmente dois terminais separados. Isto reduz o risco de esqueceres de iniciar um dos registos a meio da sessão de teste, que é um erro fácil de cometer quando estás também a jogar ao mesmo tempo para gerar a carga de trabalho. Se testares vários dispositivos ao longo do tempo, considera também normalizar o nome dos ficheiros com a data e o modelo do dispositivo, por exemplo 2026-10-18_arc-x1_thermal.csv, para não teres de abrir cada ficheiro para saberes a que teste corresponde.

Projeto completo: o teu laboratório de testes ARM vs x86

No final deste tutorial, deves ter uma pasta de projeto com esta estrutura: thermal_log.sh e battery_log.sh para a recolha de dados térmicos e de autonomia, dois ficheiros resultados_arm.json e resultados_x86.json com os números de CPU e GPU, o script compare_arm_x86.py para gerar a pontuação final, e dois ficheiros CSV com os registos térmicos completos de cada dispositivo.

Este conjunto de ficheiros é reutilizável. Sempre que um novo handheld chegar ao mercado, seja com um Snapdragon de próxima geração ou com um Ryzen AI Max ainda mais potente, basta correr o mesmo processo de 12 passos e comparar o novo ficheiro JSON com os que já tens guardados. É o mesmo princípio que redatores especializados em handhelds usam quando publicam listas atualizadas de dispositivos portáteis de jogos, só que agora tens os teus próprios dados, medidos no teu ambiente, em vez de depender só de especificações de catálogo.

Quanto custa escolher a arquitetura errada, e porque vale a pena testar primeiro

Este processo demora cerca de 60 minutos de trabalho ativo, espalhados por dois ou três dias se contares o tempo de carregamento entre testes de bateria. Compara isso com o custo de comprar o dispositivo errado. Entre o Anbernic RG 55G1 a 139 dólares e o OneXPlayer com Arc G3 Extreme a quase 2.000 dólares, há uma diferença de preço que só compensa se corresponder a uma diferença real na forma como vais usar o dispositivo no dia a dia.

Há ainda um terceiro fator que poucas comparações mencionam: a maioria das lojas online tem políticas de devolução limitadas para eletrónica aberta, e um handheld de 1.700 ou 1.900 dólares que não corre os teus jogos preferidos não é fácil de revender sem perda significativa de valor. Os 60 minutos deste tutorial são, na prática, o seguro mais barato que podes comprar antes de gastares centenas ou milhares de dólares num dispositivo que pode não servir o teu caso de uso específico. E se já tens um dispositivo e só queres confirmar se vale a pena atualizar, o mesmo processo funciona para comparar o teu handheld atual com o que estás a considerar comprar a seguir.

Perguntas frequentes

ARM é sempre mais eficiente do que x86 em handhelds de jogos?
Na maioria dos casos sim, em termos de consumo por instrução executada, mas a eficiência real de um dispositivo depende também do sistema operativo, do software de gestão de energia e da camada gráfica. Um handheld x86 bem otimizado, como os baseados em Ryzen AI Max+, consegue reduzir essa diferença em cenários de jogo sustentado.

Preciso de testar os dois dispositivos no mesmo dia?
Não é obrigatório, mas é recomendado para controlar variáveis como a temperatura ambiente. Se testares em dias diferentes, regista sempre a temperatura da sala em cada sessão para poderes ajustar a comparação depois.

O Geekbench 6 é suficiente, ou preciso de outros benchmarks de CPU?
O Geekbench 6 é um bom ponto de partida por correr em ambas as plataformas com a mesma metodologia, mas para uma visão mais completa vale a pena complementar com testes de jogos reais, como descrito no Passo 7, já que benchmarks sintéticos não captam o custo de tradução de código entre arquiteturas.

Os jogos Windows correm bem em handhelds ARM com Android?
Depende muito do jogo. Títulos leves em 2D ou com pouca exigência de física costumam correr de forma aceitável através de camadas de tradução como o Box64, mas jogos AAA recentes ou com anticheat em modo kernel normalmente não funcionam, ou funcionam com perdas significativas de desempenho.

Vale a pena testar a autonomia da bateria se já sei que o ARM é mais eficiente?
Sim, porque a diferença real varia muito por dispositivo e por jogo. Um handheld ARM com má otimização de software pode gastar bateria mais rápido do que um x86 bem otimizado, por isso medir é sempre melhor do que assumir.

Posso usar este processo para comparar mais de dois dispositivos ao mesmo tempo?
Sim. O script Python do Passo 10 aceita qualquer número de ficheiros JSON, basta ajustares o código para percorrer uma lista de dispositivos em vez de comparar só dois, e ordenares os resultados do mais alto para o mais baixo.

O que é mais importante para emulação: CPU ou GPU?
Depende da consola que estás a emular. Consolas mais antigas, como as de 8 e 16 bits, dependem sobretudo de desempenho de CPU single-core. Consolas de geração posterior, como PlayStation 2 ou GameCube, dependem muito mais de desempenho de GPU e de largura de banda de memória.

Preciso de root ou jailbreak no handheld ARM para correr estes testes?
Não. Todos os comandos deste tutorial usam o ADB em modo de utilizador normal, sem acesso root. Root só seria necessário se quisesses alterar diretamente as curvas de voltagem ou de clock do chip, o que está fora do âmbito deste tutorial.

Os resultados deste teste mantêm-se válidos depois de uma atualização de firmware?
Não necessariamente. Fabricantes como a Qualcomm e a AMD lançam regularmente atualizações de firmware e de driver gráfico que alteram a gestão de energia e, por vezes, o desempenho sustentado. É por isso que o Passo 10 guarda os resultados em ficheiros JSON separados por data, o que te permite voltar a correr o mesmo teste depois de cada atualização relevante e confirmar se algo mudou.