Como você sabe que um mini-jogo é realmente estável no mundo real?
Uma taxa de crash de 0,1% no seu telefone topo de linha de teste não é estabilidade. É uma conjetura a partir de um dispositivo com wifi. A estabilidade real é uma distribuição entre milhares de modelos de dispositivos, assassinos de memória de fabricantes e redes instáveis —e os mini-jogos carregam uma dobra extra que apps nativas não: você compartilha um runtime com todos os outros. Isto é como medir e ser dono disso.
Q: Por que seu próprio dispositivo não pode lhe dizer que o jogo é estável?
Porque é a amostra errada. Seu telefone de dev é um topo de linha recente numa conexão rápida; seus jogadores estão em dois mil modelos de Android, dispositivos de pouca RAM e operadoras que soltam pacotes no meio da sessão. Um crash que nunca se reproduz na sua mesa pode atingir 5% de um telefone de entrada popular que você nunca segurou. Estabilidade é um problema de distribuição, não uma média que você calcula a partir de um número. A única forma de aprender é telemetria real de dispositivos em campo —o simulador e seu laptop vão mentir para você toda vez, porque foram desenhados para ser o melhor caso.
Q: Qual é a métrica que importa de verdade?
Duas, rastreadas separadamente. A taxa de sessões sem crash (ou de usuários) é a manchete —e você a quer acima de 99%, porque uma vez abaixo de ~98% você está perdendo jogadores que nunca enviarão um relatório; eles simplesmente vão embora. A segunda é ANR —"app not responding"— que parece um crash para o jogador mas não aparece nos logs de crash, então equipes reportam otimistamente uma estabilidade que não têm. Ambas devem ser segmentadas por modelo de dispositivo, versão de SO e versão de runtime, porque uma má versão de runtime pode afundar a estabilidade de todos os jogos sobre ela de uma vez.
Q: Por que a estabilidade é especial para mini-jogos num runtime compartilhado?
Seu mini-jogo vive dentro de um runtime anfitrião, e quando esse runtime atualiza, o comportamento do seu jogo pode mudar mesmo que você não tenha mudado uma linha. Uma mudança de motor WebView, um endurecimento de permissões, um ajuste de teto de memória —qualquer um desses pode quebrar você em toda a frota, e os sintomas parecem exatamente seu bug. Assim você deve monitorar por versão de runtime, e precisa de uma rota de rollback que não exija que o anfitrião o reimplante. A assimetria a internalizar: apps nativas são donas de toda a sua pilha; mini-jogos compartilham uma, e a regressão de um vizinho pode se disfarçar de sua culpa em cada painel que você abrir.
Q: Como construir um programa de estabilidade que pega incêndios cedo?
Instrumente um reporter de crashes (Crashlytics, Sentry) desde o dia um —não após a primeira avaliação de 1 estrela. Lance cada versão de runtime e jogo em canary para uma pequena porcentagem antes do rollout completo. Alerte sobre a regressão na taxa sem crash, não sobre contagens brutas, porque contagens brutas escalam com o tráfego e escondem o sinal. Mantenha um rollback de um clique pronto. E feche o ciclo honestamente: um crash sem reproduzir e sem conserto é uma fuga que você decidiu aceitar, então etiquete-o, priorize por quantidade de usuários afetados em vez da etiqueta de severidade que alguém atribuiu, e lance o fix antes que se torne a razão pela qual sua curva de retenção se dobra.
| Sinal | Limite de ação | Segmentar por | Ação |
|---|---|---|---|
| Sessões sem crash | < 99% | dispositivo, SO, runtime | investigue + canary |
| Taxa ANR | tendência de alta | modelo dispositivo | perfile thread principal |
| Regressão por runtime | qualquer queda vs anterior | versão runtime | rota rollback |
| Crash irrepetível | > N usuários | afetados | priorize, não enterre |
