Profile e analise o uso de memória com as ferramentas de profiling de memória do Unity

O profiling de memória está amplamente relacionado ao desempenho em tempo de execução, mas é útil para testar limitações de memória da plataforma de hardware ou se seu jogo está travando. Também pode ser relevante se você quiser melhorar o desempenho da CPU/GPU fazendo alterações que realmente aumentem o uso de memória.

Existem duas maneiras de analisar o uso de memória em seu aplicativo no Unity:

- O módulo Profiler de Memória: Este é um módulo Profiler embutido que fornece informações básicas sobre onde sua aplicação usa memória no profiler regular.

- O Profiler de Memória: Esta é uma ferramenta dedicada disponível como um pacote Unity que você pode adicionar ao seu projeto. Ela adiciona uma janela adicional do Profiler de Memória ao Editor Unity, que você pode usar para analisar o uso de memória em sua aplicação com ainda mais detalhes. Você pode armazenar e comparar snapshots para encontrar fugas de memória ou analisar o layout de memória para identificar problemas de fragmentação. Abordaremos isso em mais detalhes mais adiante neste guia e manteremos o foco aqui nas considerações gerais que você precisa levar em conta.

Ambas as ferramentas permitem que você monitore o uso de memória, localize áreas de uma aplicação onde o uso de memória é maior do que o esperado e encontre e melhore a fragmentação de memória.

Compreender e orçar as limitações de memória de seus dispositivos-alvo é crítico para o desenvolvimento multiplataforma. Ao projetar cenas e níveis, você precisa se manter dentro do orçamento de memória definido para cada dispositivo-alvo. Ao definir limites e diretrizes, você pode garantir que sua aplicação funcione bem dentro das especificações de hardware de cada plataforma.

Você pode encontrar as especificações de memória do dispositivo na documentação do desenvolvedor.

Também pode ser útil definir orçamentos de conteúdo em torno da complexidade de malhas e shaders, bem como para compressão de texturas. Todos esses fatores influenciam quanto de memória é alocada. Esses números de orçamento podem ser referenciados durante o ciclo de desenvolvimento do projeto.

Determinar limites físicos de RAM

Como cada plataforma tem um limite de memória, sua aplicação precisará de um orçamento de memória para cada um de seus dispositivos-alvo. Use o Profiler de Memória para olhar para um instantâneo capturado do seu uso de memória. O instantâneo de Recursos de Hardware (veja a imagem abaixo) mostra os tamanhos de Memória de Acesso Aleatório Física (RAM) e Memória de Acesso Aleatório de Vídeo (VRAM). Esse número não leva em conta o fato de que nem todo aquele espaço pode estar disponível para uso. No entanto, fornece uma figura útil para começar a trabalhar.

É uma boa ideia cruzar as especificações de hardware para as plataformas-alvo, pois os números exibidos aqui podem não mostrar sempre o quadro completo. O hardware do kit de desenvolvimento às vezes tem mais memória, ou você pode estar trabalhando com hardware que possui uma arquitetura de memória unificada.

Identifique o hardware com a especificação mais baixa de RAM para cada plataforma que você suporta e use isso para orientar sua decisão de orçamento de memória. Lembre-se de que nem toda essa memória física pode estar disponível para uso. Por exemplo, um console pode ter um hipervisor em execução para suportar jogos mais antigos, que pode usar parte da memória total. Pense em uma porcentagem (por exemplo, 80% do total) para usar como equipe, dependendo do seu cenário específico. Para plataformas móveis, você também pode considerar dividir em vários níveis de especificações para suportar melhor qualidade e recursos para aqueles com dispositivos de ponta.

Considere orçamentos por equipe para equipes maiores

Uma vez que você tenha um orçamento de memória definido, considere definir orçamentos de memória por equipe. Por exemplo, seus artistas de ambiente recebem uma certa quantidade de memória para usar em cada nível ou cena que é carregada, a equipe de áudio recebe alocação de memória para música e efeitos sonoros, e assim por diante. Embora isso possa parecer rígido, pense nisso como diretrizes para informar as decisões criativas que estão sendo tomadas em relação ao custo dos recursos.

É importante ser flexível com os orçamentos à medida que o projeto avança. Se uma equipe ficar abaixo do orçamento, atribua o excedente a outra equipe se isso puder melhorar as áreas do jogo que estão desenvolvendo.

Uma vez que você decida e defina orçamentos de memória para suas plataformas-alvo, o próximo passo é usar ferramentas de perfilagem para ajudá-lo a monitorar e rastrear o uso de memória em seu jogo, permitindo que você tome decisões informadas e tome ações conforme necessário.

Para determinar em um nível alto quando o uso de memória começa a se aproximar dos orçamentos da plataforma, use o seguinte cálculo "de costas de guardanapo":

Memória Usada pelo Sistema (ou Memória Total Reservada se a Memória Usada do Sistema mostrar 0) + buffer aproximado de memória não rastreada / memória total da plataforma

Quando esse número começar a se aproximar de 100% do orçamento de memória da sua plataforma, use o pacote Memory Profiler para descobrir o porquê.

No Unity 6, muitos dos recursos do módulo Memory Profiler são substituídos pelo pacote Memory Profiler, mas você ainda pode usar o módulo para complementar seus esforços de análise de memória. Por exemplo:

- Para identificar alocações de GC: Embora esses apareçam no módulo, é mais fácil rastreá-los usando Auditor de Projetos ou Profiling Profundo.

- Para olhar rapidamente o tamanho Usado/Reservado do heap

- Análise de memória de shader

- Use a visão Detalhada no módulo Memory Profiler para aprofundar nas árvores de memória mais altas e descobrir o que está usando mais memória.

Aqui estão mais alguns recursos para ajudá-lo a explorar casos de uso adicionais e recursos do Profiler do Unity:

- Visão geral do Profiler no manual do Unity

- Introdução ao profiling no Unity

- Como perfilar e otimizar um jogo

Você geralmente vai querer perfilar usando um sistema de desenvolvedor poderoso com muita memória disponível (espaço para armazenar grandes instantâneas de memória ou carregar e salvar essas instantâneas rapidamente é importante).

O profiling de memória é uma besta diferente em comparação com o profiling de CPU e GPU porque pode incorrer em sobrecarga de memória adicional. Você pode precisar perfilar a memória em dispositivos de alta gama (com mais memória), mas preste atenção ao limite do orçamento de memória para a especificação de alvo de baixa gama.

Configurações como níveis de qualidade, camadas gráficas e variantes de AssetBundle podem ter diferentes usos de memória em dispositivos mais poderosos. Com isso em mente, aqui estão alguns detalhes a serem considerados para obter o máximo do profiling de memória:

- As configurações de qualidade e gráficos podem afetar o tamanho das texturas de renderização usadas para mapas de sombra.

- A escala de resolução pode afetar o tamanho dos buffers de tela, texturas de renderização e efeitos de pós-processamento.

- As configurações de textura podem afetar o tamanho de todas as texturas.

- O LOD máximo pode afetar modelos e mais.

Se você tiver variantes de AssetBundle como uma versão HD (Alta Definição) e uma versão SD (Definição Padrão), e escolher qual usar com base nas especificações do seu dispositivo alvo, você pode obter tamanhos de ativos diferentes com base em qual dispositivo você está perfilando.

- A resolução da tela do seu dispositivo alvo afetará o tamanho das texturas de renderização usadas para efeitos de pós-processamento.

- A API gráfica suportada de um dispositivo pode afetar o tamanho dos shaders com base nas variantes que ele suporta (ou não suporta).

- Um sistema em camadas que usa diferentes configurações de qualidade e gráficos, bem como variantes de AssetBundle, é uma ótima maneira de poder direcionar uma gama mais ampla de dispositivos.

Por exemplo, você pode carregar uma versão HD de um AssetBundle em um dispositivo móvel de 4GB e uma versão SD em um dispositivo de 2GB. No entanto, leve em consideração as variações acima no uso de memória e certifique-se de testar ambos os tipos de dispositivos, bem como dispositivos com diferentes resoluções de tela ou APIs gráficas suportadas.

Observação: O Editor do Unity geralmente mostrará uma maior utilização de memória devido a objetos adicionais que são carregados do Editor e do Profiler. Além disso, a utilização de memória de textura é maior, pois todas são forçadas a ter leitura/escrita habilitada no Editor.

O pacote Memory Profiler pode ajudá-lo a entender e otimizar o uso de memória do seu projeto. Ele permite que você capture 'instantâneas' da memória do seu aplicativo em momentos específicos, tanto dentro do Editor do Unity quanto em builds do Player em seu dispositivo alvo.

As instantâneas fornecem uma análise abrangente de como a memória está sendo utilizada, mostrando alocações em todo o motor. Isso ajuda você a identificar fontes de uso excessivo ou desnecessário de memória, rastrear vazamentos de memória e inspecionar problemas como fragmentação de heap.

Após instalar o pacote Memory Profiler, abra-o via Janela > Análise > Memory Profiler.

A barra de menu superior do Memory Profiler permite que você altere o alvo de seleção do player e capture ou importe instantâneas. O menu suspenso de seleção de alvo no canto superior esquerdo permite que você analise a memória diretamente em seu hardware alvo conectando o Memory Profiler ao dispositivo remoto. Observe que a análise no Editor do Unity fornecerá números imprecisos devido a sobrecargas adicionadas pelo Editor e outras ferramentas.

No lado esquerdo da janela do Memory Profiler está o componente Instantâneas. Use isso para gerenciar e abrir ou fechar instantâneas de memória salvas. O componente Snapshot fornece duas visualizações, Snapshot Único e Comparar Snapshot.

Semelhante ao Analisador de Perfil, o Profiler de Memória permite que você carregue e compare dois snapshots de memória lado a lado. Use essa comparação para rastrear o crescimento da memória ao longo do tempo, analisar o uso entre cenas ou identificar possíveis vazamentos de memória.

O Profiler de Memória tem várias abas na janela principal que permitem que você explore os snapshots de memória, sendo as principais Resumo, Objetos Unity e Toda a Memória. Vamos analisar cada uma dessas opções em detalhes.

A aba Resumo fornece um instantâneo de alto nível do uso de memória do seu projeto no momento em que uma captura de memória foi feita. É perfeito para quando você deseja uma visão rápida e informativa sem mergulhar em uma análise detalhada.

Essa visualização destaca métricas-chave e pode ajudá-lo a identificar rapidamente possíveis problemas de memória ou padrões de uso inesperados. É especialmente útil ao comparar snapshots ou depurar o uso de memória ao longo do tempo. Vamos olhar para algumas de suas seções principais.

Dicas: No painel direito (veja a imagem abaixo), você encontrará informações contextuais úteis sobre seu snapshot. Essas podem alertá-lo sobre possíveis problemas ou guiá-lo na interpretação dos resultados.

Uso de Memória no Dispositivo: Isso mostra a pegada da aplicação na memória física. Inclui todas as alocações Unity e não-Unity residentes na memória no momento da captura.

Distribuição de Memória Alocada: Essa visualização mostra como a memória alocada é distribuída entre diferentes categorias de memória.

Note a barra de memória Não Rastreada*. Isso corresponde à memória que o Unity não rastreia através de seu sistema de gerenciamento de memória. Essas alocações podem vir de plugins nativos e drivers. Use o profiler específico da plataforma para analisar o uso de memória não rastreada para seu dispositivo alvo.

Utilização do Heap Gerenciado: Nesta visualização, você obterá uma divisão da memória que a VM de script do Unity gerencia, que inclui a memória do heap gerenciado usada para objetos gerenciados, espaço vazio no heap que pode ter sido usado anteriormente por objetos ou reservado durante a última expansão do heap, e memória usada pela própria máquina virtual.

Principais Categorias de Objetos do Unity: Isso exibe quais tipos de objetos do Unity usam mais memória no snapshot (por exemplo, Texture2D, malha, GameObject).

A aba de Objetos do Unity exibe quaisquer objetos do Unity que alocaram memória, quanto de memória nativa e gerenciada o objeto usa, e o total combinado. Use essas informações para identificar áreas onde você pode eliminar entradas de memória duplicadas ou para encontrar quais objetos usam mais memória. E através da barra de pesquisa, você pode encontrar as entradas na tabela que contêm o texto que você inserir.

Por padrão, a tabela lista todos os objetos relevantes por Tamanho Alocado em ordem decrescente. Você pode clicar no nome do cabeçalho de uma coluna para classificar a tabela por essa coluna ou para mudar se a coluna classifica em ordem crescente ou decrescente.

Use isso a seu favor ao otimizar o uso de memória e visando empacotar a memória de forma mais eficiente para plataformas de hardware onde os orçamentos de memória são limitados.

Comece analisando um snapshot do Memory Profiler para identificar áreas de alto uso de memória. Uma vez que você capture ou carregue um snapshot do Memory Profiler, use a aba de Objetos do Unity para inspecionar as categorias, ordenadas do maior para o menor em tamanho de pegada de memória.

Os ativos do projeto são frequentemente os maiores consumidores de memória. Usando o modo Tabela, localize texturas, malhas, clipes de áudio, texturas de renderização, variantes de shader e buffers pré-alocados. Estes são frequentemente bons candidatos para começar a otimizar o uso de memória. O Auditor de Projetos é uma ótima ferramenta complementar aqui, pois pode fornecer algumas recomendações sobre como reduzir o uso de memória para ativos (certificando-se de que o ativo está configurado corretamente no Inspector de Configurações de Importação é um bom ponto de partida).

Localizando vazamentos de memória

Um vazamento de memória é uma situação em que ativos, objetos ou recursos não utilizados não são liberados corretamente da memória. Isso pode levar a um aumento progressivo no uso de memória e problemas de desempenho ou falhas.

Um vazamento de memória geralmente acontece quando:

- Um objeto não é liberado manualmente da memória através do código.

- Um objeto permanece inadvertidamente na memória porque outro objeto ainda mantém uma referência a ele.

O Profiler de Memória tem um modo Comparar Capturas que pode ajudar a encontrar vazamentos de memória comparando duas capturas ao longo de um período específico. Essa comparação pode revelar objetos que persistem na memória quando deveriam ser desalocados.

Um cenário frequente para vazamentos de memória em jogos Unity é após descarregar uma cena. Objetos da cena descarregada podem não ser coletados corretamente se referências a eles ainda existirem.

Localizando alocações de memória recorrentes ao longo da vida útil da aplicação

Através de comparação diferencial de múltiplas capturas de memória, você pode identificar a fonte de alocações contínuas de memória durante a vida útil da aplicação.

As seções a seguir fornecem algumas dicas para ajudar a identificar alocações de heap gerenciadas em seus projetos.

O módulo Profiler de Memória no Profiler Unity representa alocações gerenciadas por quadro com uma linha vermelha. Isso deve ser 0 na maior parte do tempo, então quaisquer picos nessa linha indicam quadros que você deve investigar para alocações gerenciadas.

A visualização da Linha do Tempo no módulo Profiler de Uso da CPU mostra alocações, incluindo as gerenciadas, em rosa, facilitando a identificação.

As pilhas de chamadas de alocação fornecem uma maneira rápida de descobrir alocações de memória gerenciada em seu código. Essas fornecerão os detalhes da pilha de chamadas que você precisa com menos sobrecarga em comparação com o que a profilagem profunda normalmente adicionaria, e podem ser ativadas em tempo real usando o Profiler padrão.

As pilhas de chamadas de alocação estão desativadas por padrão no Profiler. Para ativá-las, clique no botão Pilhas de Chamadas na barra de ferramentas principal da janela do Profiler. Altere a visualização Detalhes para Dados Relacionados.

Observação: Se você estiver usando uma versão mais antiga do Unity (anterior ao suporte de pilhas de chamadas de alocação), então profilagem profunda é uma boa maneira de obter pilhas de chamadas completas para ajudar a encontrar alocações gerenciadas.

A amostra GC.Alloc selecionada na Hierarquia ou Hierarquia Bruta agora conterá suas pilhas de chamadas. Você também pode ver as pilhas de chamadas das amostras GC.Alloc na dica de seleção na Linha do Tempo.

A visualização da Hierarquia no Profiler de Uso da CPU permite que você clique nos cabeçalhos das colunas para usá-los como critérios de ordenação. Classificar por GC Alloc é uma ótima maneira de se concentrar nesses.

O Auditor de Projetos, introduzido como um pacote no Unity 6.1, é uma poderosa ferramenta de análise para projetos Unity, projetada para ajudar os desenvolvedores a otimizar o desempenho, manter as melhores práticas e identificar problemas e gargalos potenciais em seus projetos.

O Auditor de Projetos escaneia todo o seu projeto e fornece relatórios detalhados sobre ineficiências, como chamadas de script pesadas, ativos não utilizados, contagens excessivas de entidades, etc.

O Auditor de Projetos abrange várias áreas diferentes:

Otimização de desempenho: Ele identifica problemas que podem impactar o desempenho em tempo de execução do seu projeto, como geração excessiva de lixo, alocações de objetos desnecessárias ou chamadas de função caras.

Revisão de código e ativos: Ele destaca ativos não utilizados, padrões de código ineficientes ou APIs desatualizadas que podem ser refatoradas. Isso ajuda a reduzir o tamanho da construção, melhorar a manutenibilidade geral do projeto e otimizar o uso da memória.

Diagnósticos e melhores práticas: Ele fornece recomendações com base nas melhores práticas do Unity e destaca erros ou avisos relacionados à configuração do seu projeto, como referências ausentes ou configurações de Player ou Qualidade subótimas.

Relatórios personalizáveis: Ele organiza os resultados em categorias, facilitando a priorização de otimizações. Você também pode criar regras personalizadas para adaptar a análise ao seu projeto ou necessidades específicas.

Dicas:

- Execute o Auditor de Projetos em etapas-chave do desenvolvimento (por exemplo, antes de marcos, lançamentos beta, compilações finais). Auditorias regulares ajudam a identificar gargalos de desempenho, ativos não utilizados ou código desatualizado precocemente, evitando que problemas cresçam à medida que seu projeto se expande.

- Você pode automatizar a execução do Auditor de Projetos como parte da sua configuração de CI ou build (como mostrado aqui no manual) e usar os relatórios para garantir que ninguém adicione ativos ou código que introduzam novos problemas (usando a API detalhada aqui).

- Você pode adicionar suas próprias regras se houver coisas específicas que você deseja garantir que sejam capturadas em seu jogo; por exemplo, configurações de textura, tamanhos ou regras mais complicadas. Veja esta página no manual para mais detalhes sobre como fazer isso.

Os relatórios gerados pelo Auditor de Projetos são categorizados por severidade (Maior, Moderado e Informação). Concentre-se primeiro nos problemas mais severos, pois eles frequentemente destacam problemas críticos de desempenho, como alocação excessiva de memória ou coleta de lixo excessiva. Eles também provavelmente estarão em caminhos de código que são chamados com mais frequência, como Update, onde quaisquer problemas de desempenho que eles trazem serão mais óbvios para os jogadores.

O Auditor de Projetos também verifica configurações como Configurações do jogador e Configurações de qualidade e faz recomendações sobre o que você pode mudar. Use isso para garantir que seus alvos de build, resolução, compressão de texto ou outras configurações do projeto estejam otimizados para sua plataforma pretendida.

Recarga de Domínio

O Editor do Unity permite que você configure as configurações sobre entrar no modo Play; esta página tem mais detalhes sobre isso, mas você pode frequentemente acelerar seu tempo de iteração no Editor desativando a Recarga de Domínio. No entanto, isso não redefinirá mais seu estado de script toda vez que você entrar no modo Play, então você terá que fazer isso manualmente em seu código.

A área de Código no Auditor de Projetos pode analisar os scripts em seu projeto para ajudá-lo a encontrar onde você precisa redefinir suas variáveis de script. É considerado uma boa prática corrigir todos os problemas exibidos na visualização de Recarga de Domínio e, em seguida, desativar a recarga de domínio. Para preencher esta visualização com dados, você deve habilitar a configuração Usar Analisadores Roslyn na janela de Preferências. Então você pode percorrer a lista de problemas, seguindo as instruções no manual para corrigi-los. Uma vez que todos eles sejam resolvidos, você pode desativar o Reload de Domínio ao entrar no modo de jogo.

Unity usa o coletor de lixo Boehm-Demers-Weiser para limpar automaticamente a memória quando não é mais necessária para sua aplicação. O GC para de executar o código do seu programa e só retoma a execução normal quando seu trabalho está completo.

Embora a gestão automática seja conveniente, alocações desnecessárias ou frequentes podem levar a interrupções de desempenho porque o coletor de lixo precisa pausar seu jogo para limpar a memória não utilizada (também conhecido como picos de GC). Aqui estão algumas armadilhas comuns a ter em mente:

Strings: Em C#, strings são tipos de referência, não tipos de valor. Isso significa que cada nova string será alocada na pilha gerenciada, mesmo que seja usada apenas temporariamente. Reduza a criação ou manipulação desnecessária de strings. Evite analisar arquivos de dados baseados em string, como JSON e XML, e armazene dados em ScriptableObjects ou formatos como MessagePack ou Protobuf. Use a classe StringBuilder se você precisar construir strings em tempo de execução.

Chamadas de função do Unity: Algumas funções da API do Unity criam alocações na pilha, particularmente aquelas que retornam um array de objetos gerenciados temporários. Armazene referências a arrays em vez de alocá-los no meio de um loop. Além disso, aproveite certas funções que evitam gerar lixo. Por exemplo, use GameObject.CompareTag em vez de comparar manualmente uma string com GameObject.tag (já que retornar uma nova string cria lixo).

Você também pode usar o Auditor de Projetos para listar essas alternativas; isso pode ajudar a garantir que você esteja usando as versões não alocativas sempre que possível.

Boxing: A conversão ocorre quando um tipo de valor (por exemplo, int, float, struct) é convertido em um tipo de referência (por exemplo, object). Evite passar uma variável de tipo valor no lugar de uma variável de tipo referência. Isso cria um objeto temporário, e o potencial lixo que vem com isso converte implicitamente o tipo de valor em um objeto de tipo (por exemplo, int i = 123; object o = i). Em vez disso, tente fornecer substituições concretas com o tipo de valor que você deseja passar. Generics também podem ser usados para essas substituições.

Corrotinas: Embora yield não produza lixo, criar um novo objeto WaitForSeconds o faz. Cache e reutilize o objeto WaitForSeconds em vez de criá-lo na linha yield.

LINQ e Expressões Regulares: Ambos geram lixo devido ao boxing nos bastidores. Evite LINQ e Expressões Regulares se o desempenho for um problema. Escreva loops for e use listas como uma alternativa para criar novos arrays.

Coleções Genéricas e outros tipos gerenciados: Não declare e preencha uma List ou coleção a cada quadro em Update (por exemplo, uma lista de inimigos dentro de um certo raio do jogador). Em vez disso, faça da List um membro do MonoBehaviour e inicialize-a em Start. Simplesmente esvazie a coleção com Clear a cada quadro antes de usá-la.

Coleta de lixo de tempo sempre que possível

Se você tiver certeza de que uma pausa na coleta de lixo não afetará um ponto específico em seu jogo, você pode acionar a coleta de lixo com System.GC.Collect. Um exemplo clássico disso é quando o usuário está em um menu ou pausa o jogo, onde não será perceptível.

Veja Compreendendo a Gestão Automática de Memória para exemplos de como usar isso a seu favor.

Use o Coletor de Lixo Incremental para dividir a carga de trabalho do GC

Em vez de criar uma única interrupção longa durante a execução do seu programa, a coleta de lixo incremental usa múltiplas interrupções mais curtas que distribuem a carga de trabalho ao longo de muitos quadros. Se a coleta de lixo estiver causando uma taxa de quadros irregular, experimente esta opção para ver se reduz o problema dos picos de GC. Use o Analisador de Perfil para verificar seu benefício para sua aplicação.

Observe que usar o GC em modo Incremental adiciona barreiras de leitura-escrita a algumas chamadas de C#, o que vem com uma sobrecarga que pode somar até ~1 ms por quadro de sobrecarga de chamada de script. Para desempenho ideal, é ideal não ter GC Allocs nos loops principais de gameplay para que você não precise do GC Incremental para uma taxa de quadros suave e possa ocultar o GC.Collect onde um usuário não notará, por exemplo, ao abrir o menu ou carregar um novo nível. Em tais cenários otimizados, você pode realizar coletas de lixo completas e não incrementais (usando System.GC.Collect()).

Para saber mais sobre o Profiler de Memória, confira os seguintes recursos:

Passo a passo e tutorial do Profiler de Memória

Documentação do Profiler de Memória

Melhore o uso de memória com o Profiler de Memória no Unity

Profiler de Memória: A Ferramenta para Solucionar Problemas Relacionados à Memória

Trabalhando com o Profiler de Memória