Uma grande pilha Mono não significa necessariamente que a memória gerenciada é seu maior problema. Antes de otimizar o GC ou reduzir alocações, entenda onde sua margem total de memória está realmente sendo consumida.
Resumo
Vendo 400 MB de memória Mono em um projeto Unity, geralmente gera a mesma resposta:
- Otimizar GC
- Reduzir alocações gerenciadas
- Agregar mais pool de objetos
- Refatorar o código do jogo
Mas isso pode não ser o melhor lugar para começar.
No mundo real, em muitos casos, o problema maior não é a Mono em si, mas a categoria de memória que permanece inexplicada.
Por exemplo, se seu relatório de memória mostrar:
Mono: 400 MB
Others: ~1 GB
A categoria desconhecida "Outros" pode representar uma oportunidade de otimização muito maior do que a memória gerenciada.
Antes de otimizar sistemas individuais, sempre entenda sua margem total de memória e identifique onde a memória está realmente sendo usada.
400 MB de Memória Mono é Muito?
Não necessariamente.
Não há um valor universal que defina o uso "saudável" da memória Mono.
A pergunta correta é:
O total de memória do processo permanece dentro da margem de memória do dispositivo-alvo?
O Mono é apenas uma parte da pegada total de memória. A memória do seu jogo pode incluir:
- Monte gerenciado (Mono)
- Texturas
- Malhas
- Audição
- Alocações nativas
- Memória do motor
- Memória de tempo de execução de terceiros
Todos esses compartilham a mesma margem de memória.
Como referência prática:
| Memória do Dispositivo | Intervalo PSS Recomendado |
|---|---|
| 3 GB RAM | Aproximadamente 1,3–1,5 GB |
| 4 GB RAM | Aproximadamente 1,8–2,2 GB |
Dispositivos de alto nível fornecem mais espaço para sobrevoo, mas isso não significa que o uso da memória pode crescer sem limites.
Inclusive em um dispositivo com 8 GB, um processo de jogo se aproximando de 3 GB PSS ainda pode enfrentar pressão de memória, riscos de encerramento ou vazamentos ocultos.
No caso dos dispositivos iOS, as margens de memória geralmente são mais restritivas.
Por que "Outros" Podem Ser Mais Importantes do Que Mono
Imagine sua margem total de memória fixa.
Se o Mono crescer em 100 MB, essa memória deve vir de algum lugar dentro da mesma margem.
O mesmo se aplica a:
- Memória de textura
- Memória nativa
- Memória de áudio
- Recursos GPU
Portanto:
400 MB Mono não é automaticamente um problema.
A pergunta real é:
Qual porcentagem da sua memória total o Mono representa?
Um projeto com:
Mono: 400 MB
Texturas: 300 MB
Áudio: 100 MB
Outros: 1 GB
tem um problema muito diferente em comparação com:
Mono: 400 MB
Texturas: 1 GB
Áudio: 500 MB
Outros: 100 MB
O primeiro caso provavelmente deve investigar "Outros" em primeiro lugar.
Como Investigar a Memória de "Outros"
Um fluxo prático de depuração:
1. Comece com o Profilador de Memória do Unity
Primeiro, capture um snapshot de memória.
Caso o snapshot explique a alocação:
- Texturas grandes → otimize o uso das texturas
- Ativos grandes → revise a estratégia de carregamento/descarregamento
- Muitos objetos gerenciados → investigue Mono
Cuide do problema confirmado primeiro.
2. Analise o Heap Nativo
Se o Profilador de Memória do Unity não explicar a diferença na memória, a alocação provavelmente está fora da classificação gerenciada pelo Unity.
Use ferramentas de memória nativa como:
- Native Memory Profiler do Android Studio
- Perfetto
- GameOptim Gears
Foque em:
- Crescimento do heap nativo
- Alocações de motor
- Bibliotecas terceiras
- Sistemas em tempo real
3. Verifique a Memória Específica do Tempo de Execução
Alguns projetos incluem tempos de execução adicionais:
- Lua
- Alocações nativas IL2CPP
- Bibliotecas personalizadas C++
- Bibliotecas SDK terceiras
Essas alocações podem aparecer como "Outros" porque o Unity não pode classificá-las diretamente.
Para tempos de execução de scripting, como Lua, Perfetto com simbolização pode ajudar a identificar a fonte real da alocação.
Por que "Outros" É Tão Difícil de Explicar?
Porque o Unity não possui todos os bytes de memória usados pelo seu jogo.
Alguns alocações vêm de:
- Componentes do sistema Android
- Código nativo do motor
- Bibliotecas
- SDKs
- Bibliotecas nativas personalizadas
- Runtimes de scripting externos
Uma única ferramenta de perfilagem geralmente não pode fornecer a imagem completa.
A abordagem mais confiável é combinar várias fontes de dados:
- Snapshots do Profilador de Memória do Unity
- Análise do Heap Nativo
- Métricas de memória em tempo real
- Ferramentas de perfilagem no nível do dispositivo
Apenas correlacionando essas fontes você pode entender o que "Outros" realmente contém.
Principais Conclusões
Quando a memória Mono atinge 400 MB, não assuma imediatamente que a memória gerenciada é seu maior problema.
Caso 'Outros' já esteja próximo de 1 GB, investigar memória nativa não explicada pode proporcionar uma melhoria muito maior.
A boa otimização da memória começa com:
- Definir o orçamento de memória do dispositivo-alvo
- Medir a memória total do processo (PSS)
- Identificar as maiores categorias não explicadas
- Otimizar com base em evidências, não em suposições
O maior número em um relatório de memória nem sempre é o problema mais grave.
FAQ
400 MB de memória Mono no Unity é muito alto?
Não necessariamente. Isso depende dos dispositivos-alvo, do uso total de PSS e da função que o Mono desempenha em seu orçamento geral de memória.
Devo otimizar GC antes de investigar 'Outros'?
Geralmente não.
Caso 'Outros' consuma uma porção significativa da memória, encontrar sua origem pode fornecer mais valor do que reduzir ainda mais as alocações gerenciadas.
O Profiler de Memória do Unity explica toda a utilização da memória?
Não.
Alguns alocações nativas, memória do sistema Android, alocações no nível do motor e memória em tempo de execução de terceiros podem não ser atribuídas completamente.
Para casos complexos, combine o Profiler de Memória do Unity com a análise da pilha nativa e métricas em tempo de execução.