Otimize o desempenho do seu jogo para dispositivos móveis: Obtenha dicas de especialistas sobre física, UI e configurações de áudio
Nossa equipe de Sucesso Integrado apoia os clientes da Unity com suas questões técnicas complexas. Sentamos com essa equipe de engenheiros de software sêniores e pedimos que compartilhassem um pouco de sua experiência em otimização de jogos móveis.
Nossa equipe de Produções do Unity Studio conhece o código-fonte como a palma da mão e trabalha com uma infinidade de clientes da Unity para ajudá-los a aproveitar ao máximo o motor. Em seu trabalho, eles mergulham fundo em projetos de criadores para ajudar a identificar pontos onde o desempenho pode ser otimizado para maior velocidade, estabilidade e eficiência.
À medida que nossos engenheiros começaram a compartilhar suas percepções sobre otimização de jogos móveis, percebemos rapidamente que havia informações demais para o único post de blog que havíamos planejado. Em vez disso, decidimos transformar sua montanha de conhecimento em um e-book completo (que você pode baixar aqui), além de uma série de posts de blog que destacam algumas dessas mais de 75 dicas práticas.
Nesta segunda parte desta série, estamos focando em como melhorar o desempenho com as configurações de UI, física e áudio. Caso você tenha perdido, confira nosso post anterior sobre perfilagem, memória e arquitetura de código – e fique atento ao nosso próximo, dedicado a ativos, configuração de projeto e gráficos.
Quer tudo agora? Baixe o e-book gratuito.
Vamos direto ao ponto!
A Física embutida da Unity (Nvidia PhysX) pode ser cara em dispositivos móveis, mas as dicas a seguir podem ajudá-lo a extrair mais quadros por segundo.
Nas Configurações do Jogador, verifique Pré-assar Malhas de Colisão sempre que possível.
Certifique-se de editar suas configurações de Física (Configurações do Projeto > Física) e simplificar sua Matriz de Colisão de Camadas sempre que possível.
Desative Sincronização Automática de Transformações e ative Reutilizar Callbacks de Colisão.
Colisores de malha podem ser caros. Substitua colisores de malha mais complexos por colisores de malha primitivos ou simplificados para aproximar a forma original.
Use métodos de classe como MovePosition ou AddForce para mover seus objetos Rigidbody. Traduzir seus componentes Transform diretamente pode levar a recalculações do mundo da física, que são caras em cenas complexas. Mova corpos físicos em FixedUpdate em vez de Update.
O Fixed Timestep padrão nas Configurações do Projeto é 0.02 (50 Hz). Altere isso para corresponder à sua taxa de quadros alvo (por exemplo, 0.03 para 30 fps).
Se sua taxa de quadros cair em tempo de execução, no entanto, isso significa que o Unity chamaria FixedUpdate várias vezes por quadro e potencialmente criaria um problema de desempenho da CPU com conteúdo pesado em física.
O Maximum Allowed Timestep limita quanto tempo os cálculos de física e eventos FixedUpdate podem usar no caso de a taxa de quadros cair. Reduzir esse valor significa que durante uma interrupção de desempenho, a física e a animação podem desacelerar, enquanto também reduzem seu impacto na taxa de quadros.
Use a janela de Depuração de Física (Window > Analysis > Physics Debugger) para ajudar a solucionar qualquer problema com colisores ou discrepâncias. Isso mostra um indicador codificado por cores dos GameObjects que podem colidir entre si.
Para mais informações, veja Visualização de Depuração de Física na documentação do Unity.
Unity UI (UGUI) pode frequentemente ser uma fonte de problemas de desempenho. O componente Canvas gera e atualiza malhas para os elementos da UI e emite chamadas de desenho para a GPU. Seu funcionamento pode ser caro, então mantenha os seguintes fatores em mente ao trabalhar com UGUI.
Se você tiver um Canvas grande com milhares de elementos, atualizar um único elemento da UI força todo o Canvas a atualizar, o que pode gerar um pico de CPU.
Aproveite a capacidade do UGUI de suportar múltiplos Canvases. Divida os elementos da UI com base na frequência com que precisam ser atualizados. Mantenha elementos estáticos da UI em um Canvas separado e elementos dinâmicos que se atualizam ao mesmo tempo em sub-canvases menores.
Certifique-se de que todos os elementos da UI dentro de cada Canvas tenham o mesmo valor Z, materiais e texturas.
Você pode ter elementos da UI que aparecem esporadicamente no jogo (por exemplo, uma barra de saúde que aparece quando um personagem recebe dano). Se o seu elemento invisível da UI estiver ativo, ele ainda pode estar usando chamadas de desenho. Desative explicitamente quaisquer componentes invisíveis da UI e reative-os conforme necessário.
Se você só precisa desligar a visibilidade do Canvas, desative o componente Canvas em vez do GameObject. Isso pode economizar na reconstrução de malhas e vértices.
Eventos de entrada, como toques ou cliques na tela, requerem o componente GraphicRaycaster. Isso simplesmente percorre cada ponto de entrada na tela e verifica se está dentro do RectTransform de uma UI.
Remova o GraphicRaycaster padrão do Canvas superior na hierarquia. Em vez disso, adicione o GraphicRaycaster exclusivamente aos elementos individuais que precisam interagir (botões, scrollrects, e assim por diante).
Além disso, desative Raycast Target em todo texto e imagens da UI que não precisam disso. Se a UI for complexa com muitos elementos, todas essas pequenas mudanças podem reduzir cálculos desnecessários.
Grupos de Layout atualizam de forma ineficiente, então use-os com moderação. Evite-os completamente se seu conteúdo não for dinâmico e use âncoras para layouts proporcionais em vez disso. Caso contrário, crie um código personalizado para desativar os componentes Layout Group após configurarem a UI.
Se você precisar usar Grupos de Layout (Horizontal, Vertical, Grid) para seus elementos dinâmicos, evite aninhá-los para melhorar o desempenho.
Grandes Listas e Visões de Grade são caras. Se você precisar criar uma grande Lista ou Visão de Grade (por exemplo, uma tela de inventário com centenas de itens), considere reutilizar um pequeno conjunto de elementos de UI em vez de criar um elemento de UI para cada item. Confira este projeto do GitHub de exemplo para ver isso em ação.
Sobrepor muitos elementos de UI (por exemplo, cartas empilhadas em um jogo de batalha de cartas) cria sobrecarga. Personalize seu código para mesclar elementos em camadas em tempo de execução em menos elementos e lotes.
Com dispositivos móveis agora usando resoluções e tamanhos de tela muito diferentes, crie versões alternativas da UI para fornecer a melhor experiência em cada dispositivo.
Use o Simulador de Dispositivos para visualizar a UI em uma ampla gama de dispositivos suportados. Você também pode criar dispositivos virtuais no XCode e Android Studio.
Se sua tela de pausa ou início cobrir tudo o mais na cena, desative a câmera que está renderizando a cena 3D. Da mesma forma, desative quaisquer elementos de Canvas de fundo ocultos atrás do Canvas superior.
Considere diminuir a Application.targetFrameRate durante uma UI em tela cheia, já que você não deve precisar atualizar a 60 fps.
Deixar o campo Event ou Render Camera em branco força o Unity a preencher Camera.main, o que é desnecessariamente caro.
Considere usar Screen Space – Overlay para o seu Canvas RenderMode se possível, pois isso não requer uma câmera.
Embora o áudio normalmente não seja um gargalo de desempenho, você ainda pode otimizar para economizar memória.
Se você usar qualquer formato comprimido (como MP3 ou Vorbis), o Unity irá descompactá-lo e, em seguida, recomprimí-lo durante o tempo de construção. Isso resulta em duas passagens com perda, degradando a qualidade final.
Reduza o tamanho dos seus clipes e o uso de memória com compressão:
- Use Vorbis para a maioria dos sons (ou MP3 para sons que não devem ser repetidos).
- Use ADPCM para sons curtos e frequentemente usados (por exemplo, passos, tiros). Isso reduz os arquivos em comparação com PCM não compactado, mas é rápido para decodificar durante a reprodução.
Efeitos sonoros em dispositivos móveis devem ser de no máximo 22.050 Hz. Usar configurações mais baixas geralmente tem impacto mínimo na qualidade final; use seus próprios ouvidos para julgar.
A configuração varia de acordo com o tamanho do clipe.
- Clipes pequenos (< 200 kb) devem descompactar ao carregar. Isso incorrerá em custo de CPU e memória ao descompactar um som em dados de áudio PCM bruto de 16 bits, portanto, é desejável apenas para sons curtos.
- Clipes médios (>= 200 kb) devem permanecer comprimidos na memória.
- Arquivos grandes (música de fundo) devem ser configurados para streaming, ou então todo o ativo será carregado na memória de uma vez.
Ao implementar um botão de mudo, não defina simplesmente o volume como 0. Você pode Destruir o componente AudioSource para descarregá-lo da memória, desde que o jogador não precise alternar isso com frequência.
No próximo post do blog, vamos mergulhar diretamente em gráficos e ativos. Mas se você quiser acesso à lista completa de dicas e truques da equipe hoje, nosso e-book completo está disponível aqui.
Se você estiver interessado em aprender mais sobre os serviços de Suporte Integrado e quiser dar à sua equipe acesso direto a engenheiros, conselhos de especialistas e orientações sobre melhores práticas para seus projetos, confira os planos de sucesso da Unity aqui.
Queremos ajudar você a tornar suas aplicações Unity o mais eficientes possível, então, se houver algum tópico de otimização que você gostaria de saber mais, por favor, nos avise nos comentários.