Resposta rápida: Resmon é o monitor de recursos do lado do cliente do FiveM. Abra o console F8 e execute resmon true para inspecionar o custo do recurso no cliente. Use-o para encontrar scripts, mapas, HUDs e recursos UI caros antes de adivinhar o que causa baixo FPS.
Última atualização: 25 de junho de 2026
Resmon aberto
- Entre no seu servidor.
- Imprensa
F8. - Execute:
resmon trueSe o acesso for negado, a documentação do Cfx.re observa que o modo de desenvolvedor pode ser necessário para alguns diagnósticos. Teste em um cliente de desenvolvimento ou use o profiler para depuração mais aprofundada.
O que o Resmon informa
| Coluna/sinal | Significado |
|---|---|
| CPU msec | Quanto tempo de CPU do cliente um recurso consome. |
| Memória | Quanta memória o recurso usa no cliente. |
| Picos | Rajadas curtas que podem ocorrer durante UI, streaming ou loops. |
| Custo alto constante | Um recurso que provavelmente precisa de trabalho no código ou nos assets. |
Método de teste prático
- Fique em um local tranquilo e anote os recursos mais caros.
- Mova-se para uma área movimentada da cidade, MLO ou local com muitos veículos.
- Abra menus, inventário, telefone, HUD e trabalho UI um de cada vez.
- Registre qual recurso apresenta pico e qual ação causou isso.
- Desative um recurso suspeito em staging e repita o mesmo teste.
Quando usar o profiler
Use o Resmon para triagem rápida. Use o profiler Cfx.re quando precisar de depuração em nível de linha ou mais aprofundada de recursos. O profiler é melhor quando um recurso é consistentemente caro, mas o motivo não é óbvio durante o jogo.
Causas comuns de valores altos no Resmon
- Loops sem tempo
Espere()suficiente. - Scripts NUI que atualizam a cada quadro.
- Pacotes grandes de mapas ou roupas próximos a áreas densas.
- HUDs verificando muitos estados de jogadores com muita frequência.
- Eventos do cliente realizando trabalho de servidor.
Guias de otimização relacionados
- Otimização do servidor FiveM
- Como mostrar FPS no FiveM
- Corrigir avisos de travamento de thread no FiveM
- Guia oficial do profiler Cfx.re
Como ler o Resmon sem reagir exageradamente
Um pico curto nem sempre é um bug. Abrir um telefone, inventário, menu de roupas ou mapa pode custar mais CPU brevemente. O problema é um recurso que permanece caro enquanto ocioso ou apresenta picos a cada poucos segundos durante o jogo normal.
Notas de teste úteis
- Teste sempre com a mesma rota pela cidade.
- Anote os três principais recursos antes de alterar qualquer coisa.
- Desative um recurso suspeito de cada vez.
- Teste novamente após uma reinicialização completa, não apenas um recarregamento a quente.
- Verifique tanto com poucos jogadores quanto com muitos jogadores.
Correções de desenvolvedor que geralmente funcionam
Aumente esperas em loops, evite atualizações constantes de NUI, armazene em cache consultas repetidas, mova trabalho exclusivo do servidor para fora do código do cliente e pare de verificar o estado de cada jogador a cada quadro. Se um script precisar reagir a eventos, use eventos em vez de polling quando possível.
Como decidir o que consertar primeiro
Não remova recursos aleatórios porque um número parece alto por um momento. Primeiro, teste a mesma rota pela cidade, anote os três recursos mais caros e, em seguida, mude uma coisa de cada vez. Um menu de telefone, inventário ou roupas pode disparar apenas enquanto estiver aberto; isso é diferente de um script que permanece caro enquanto o jogador está inativo.
Correções comuns que os desenvolvedores devem verificar
- Aumente as esperas em loops que não precisam de verificações a cada quadro.
- Armazene em cache consultas repetidas de jogadores, veículos ou entidades.
- Reduza mensagens constantes de NUI de recursos HUD e de telefone.
- Mova a validação apenas do servidor para fora dos loops do cliente.
- Use eventos onde a verificação periódica é apenas uma conveniência.
O que o Resmon não pode provar
O Resmon é do lado do cliente. Ele ajuda a identificar recursos que custam tempo de quadro do jogador, mas não substitui logs do servidor, perfil de banco de dados ou monitoramento do txAdmin. Um recurso pode parecer barato no cliente e ainda assim criar pressão no banco de dados do servidor. Use o Resmon para a experiência do cliente e, em seguida, use ferramentas do servidor para problemas de backend.
Anotações de antes e depois
Tire uma captura de tela ou anote os valores em ms antes de alterar o código. Após cada correção, teste novamente a mesma rota com o mesmo número de jogadores, se possível. Sem um teste repetível, o trabalho de desempenho se torna adivinhação.
Quando o problema é intermitente, registre a hora, o número de jogadores e a localização. Isso ajuda a comparar os dados do Resmon com os logs do txAdmin e as alterações recentes de recursos.
Para equipes compartilhadas, mantenha um pequeno log de desempenho para que os desenvolvedores possam ver o que mudou antes do pico aparecer.
Boas anotações tornam a otimização mais rápida do que adivinhação.
Elas também facilitam reverter exatamente a atualização de recurso que causou a regressão.
Mantenha as anotações curtas o suficiente para que a equipe realmente as use.
