Teste de performance em jogos mobile ao atualizar a engine

Um crash na abertura, um engasgo durante a partida ou o celular quente podem interromper um bom jogo. Eu colocaria o teste de performance no ciclo de release, principalmente quando mudam a engine, um SDK ou o sistema operacional. O resultado aprovado vale para o build, o aparelho e as condições daquela medição.

O Google Play lista limites globais de 1,09% para crashes percebidos pelo usuário e 0,47% para ANRs, calculados por usuário ativo diário. Cada métrica também tem limite de 8% por modelo de celular. Ultrapassá-los pode afetar a visibilidade ou gerar aviso na loja.

Bateria e calor merecem checagens próprias. Uma pesquisa da CMR de 2023, com 2.086 jogadores mobile na Índia, apontou consumo de bateria em 53%, falta de espaço em 48% e aquecimento em 48%. É um levantamento datado de um mercado específico; eu usaria esses dados para escolher o que investigar.

Em dezembro de 2024, um desenvolvedor relatou cerca de 20 ms por frame no Unity 2022.3 e 50 ms no Unity 6.0.23f1, usando um Redmi Note 10 e um exemplo URP. Respostas posteriores discutem configurações e possíveis melhorias. É um relato com variáveis em aberto; eu investigaria antes de prever a mesma regressão em outro projeto.

SDKs pedem o mesmo cuidado. O Unity Ads 4.16.6, lançado em 22 de janeiro de 2026, documentou melhorias de estabilidade e tratamento de ANR em alguns Androids com pouca memória. É um motivo concreto para testar abertura, anúncios e retorno ao jogo depois de atualizar dependências.

Eu manteria um baseline e repetiria o mesmo percurso em celulares de entrada, intermediários e topo de linha representativos do público. Fixaria brilho, qualidade gráfica, taxa de atualização, condição de carregamento e temperatura inicial. Registraria versões do build e do sistema, repetindo as rodadas para investigar diferenças consistentes.

Além do FPS médio, olharia tempos de frame e engasgos, crescimento de memória, carregamento, bateria e temperatura ao longo da sessão. A documentação do ADPF descreve variações térmicas e de frequência da CPU no Android. O emulador ajuda em outras checagens; performance sustentada precisa de validação no hardware alvo.

O exemplo do kPerf abaixo usa dados sintéticos para mostrar uma queda de FPS junto com mais jank e atividade de CPU. Essa coincidência orientaria a investigação, sem estabelecer a causa. A coleta também tem limites: registre métricas ausentes e permissões, sem deduzir percentis de frame time a partir de uma média de FPS.

Eu vincularia a cobertura às mudanças e à exposição dos jogadores. Esta é uma recomendação inicial para adaptar ao risco do jogo:

Testar custa tempo de aparelho, manutenção, repetição e interpretação especializada. Um único celular ou uma sessão curta podem deixar problemas passar. Eu acompanharia regressões acionáveis encontradas antes do release, tempo de investigação e relatos do suporte para avaliar o valor da cobertura.

O case da Spokko publicado pelo Google relata expansão de 520 para 9.280 aparelhos suportados em duas semanas e 10% mais downloads após decisões de cobertura baseadas em performance. É um resultado reportado para aquele jogo, sem retorno garantido para outro estúdio.

A Kakunyn oferece teste de performance de jogos mobile com foco em FPS, bateria, memória, rede, calor e crashes. Se você vai migrar de engine ou preparar um release, fale com a gente sobre os aparelhos, cenários e comparações que precisam entrar na cobertura de QA.