Pesquisar em Unity

Algumas das melhores dicas de otimização para IU Unity

Last updated: January 2019

What you will get from this page: Tips on how to create optimized UI elements for your content, including dividing up your canvases, avoiding the use of Camera.main and Layout Groups, smart pooling of UI objects and more.

You’ll find many more in this great session by Unity engineer Ian Dundore, Squeezing Unity: Dicas para aumentar o desempenho, (section on Unity UI starts at 23:38).

Divida seus canvas

Problema: Quando um ou mais elementos mudam no canvas da IU, todo o canvas é afetado.

O Canvas is the basic component of Unity UI. It generates meshes that represent the UI elements placed on it, regenerates the meshes when UI elements change, and issues draw calls to the GPU so that the UI is actually displayed.

A geração dessas malhas pode ser custosa. Os elementos da IU devem ser coletados em lotes, de modo que sejam desenhados no mínimo draw calls possível. Como a geração de lotes é custosa, queremos regenerá-los somente quando for necessário. O problema é que, quando um ou mais elementos mudam em um Canvas, todo o Canvas,deve ser reanalisado para determinar a maneira otimizada de desenhar todos os seus elementos.

Muitos usuários criam a IU de todo o jogo em um único canvas com milhares de elementos. Então, quando mudam um elemento, podem experimentar um pico de CPU custando vários milissegundos (para mais informações, veja a palestra de Ian no minuto 24:55).

Solução: divida seus canvas.

Cada canvas é uma ilha que isola seus elementos dos elementos de outros canvas. Assim, divida seus canvas na ferramenta principal disponível para resolver problemas de batching na IU de Unity.

Você também pode aninhar canvas, o que permite aos designers criarem IUs grandes e hierárquicas sem ter de preocupar-se com os diversos elementos na tela em vários canvas. Os canvas filhos também isolam o conteúdo dos canvas pais e irmãos. Mantêm sua própria geometria e realizam seu próprio processamento batch.

Ao subdividir canvas com canvas filhos, tente agrupá-las no momento em que elas forem atualizadas. Por exemplo, separe elementos dinâmicos de estáticos (a partir do minuto 29:36, Ian dá um bom exemplo de subdivisão inteligente de canvas).

Uso ótimo de Graphic Raycaster

Problema: Uso otimizado do Graphic Raycaster:

O Graphic Raycaster é um componente que traduz suas entradas em eventos da IU. As entradas de tela / toque são convertidas em eventos e depois enviadas para elementos de IU adequados. Você precisa de um Raycaster gráfico em cada tela que requer entrada, incluindo sub-telas.

Apesar do nome, o Graphic Raycaster não é um emissor de raios: por padrão, ele apenas testa os gráficos da IU. Pega o conjunto de elementos da IU que estão interessados em receber entradas em uma determinada tela e executa verificações de interseção: Verifica se o ponto em que o evento de entrada ocorre contra o RectTransform de cada elemento da tela Graphic Raycaster é marcado como interativo.

O desafio é que nem todos os elementos da IU estão interessados em receber atualizações.

Solução: Desligue o Raycast Target para elementos estáticos ou não interativos.

Por exemplo, o texto em um botão. Desligar o Raycast Target reduzirá diretamente o número de verificações de interseção que o Graphic Raycaster deve executar em cada frame.

Dicas de otimização para IU Unity

Problema: de certa forma, o Graphic Raycaster atua como um emissor de raios.

Se você definir o modo de renderização em seu canvas para Worldspace Camera ou Screen Space Camera, você também pode configurar uma máscara de bloqueio. A máscara de bloqueio determina se o Raycaster lançará raios através de física 2D ou 3D, para ver se algum objeto de física está bloqueando a capacidade do usuário para interagir com a IU.

Solução: Raycasting via física em 2D e 3D pode ser custoso, use esta função com moderação.

Além disso, minimize o número de Graphic Raycasters ao não adicioná-los a Canvas da IU não interativas, pois neste caso, não há motivos para verificar eventos de interação.

Evite o uso de Camera.main

Problema: Os canvas World Space precisam saber de qual câmera devem vir seus eventos de interação.

Quando se configura um Canvas para renderizar em um Canvas World Space ou em um Canvas Screen Space Camera, é possível especificar a câmara que será usada para gerar os eventos de interação para o Graphic Raycaster da IU. Esta configuração é necessária para Canvas "Screen Space - Camera" e denomina-se "Render Camera".

Unity UI optimization tips screen space camera

No entanto, a configuração é facultativa para os canvas "World Space" e denomina-se "Event Camera".

Unity UI optimization tips world space

Se você deixar o campo Event Camera em branco em um Canvas World Space, isto não significa que seu canvas não receberá os eventos. Em vez disso, este usa a câmara principal do jogo. Para determinar qual é a câmara principal, ele acessa a propriedade Camera.main

Unity UI optimization tips camera main property

Dependendo da rota de código que tome Unity, acessará a Camera.main entre 7 a 10 vezes por frame, por Graphic Raycaster, por World Space Canvas. E Camera.main chama Object.FindObjectWithTag toda vez que é acessado! Obviamente, isso não é bom em tempo de execução.

Solução: Evite o uso de Camera.main.

Coloque as referências às câmeras no cache e crie um sistema para rastrear a câmera principal. Se você usa os canvas World Space, atribua sempre uma Event Camera. Não deixe esta configuração vazia! Se for necessário mudar a Event Camera, escreva um código que atualize a propriedade Event Camera.

Evite os grupos de layout sempre que possível

Problema: Todo elemento IU que tenta sujar o Layout executará pelo menos uma chamada GetComponents.

Quando um ou mais elementos filho mudam em um sistema de layout, ele fica sujo. O(s) elemento(s) filho(s) alterado(s) invalidam o sistema Layout ao qual pertencem.

Um pouco sobre os sistemas de layout : um sistema de layout é um conjunto de grupos de layout contíguos que se situam diretamente sobre um elemento de layout. Um elemento de layout não é apenas o componente do elemento de layout: imagens de IU texto e Scroll Rects também são elementos de layout. E Scroll Rects também são grupos de layout.

Voltando ao problema: cada elemento IU que marca seu layout como sujo faz pelo menos uma chamada GetComponents. Esta chamada procura um grupo de layout válido no pai do elemento de layout. Se um grupo for encontrado, ele continuará subindo a hierarquia Transform até que nenhum grupo de layout possa ser encontrado ou a raiz hierárquica seja atingida, o que ocorrer primeiro. Assim, cada grupo de layout adiciona uma chamada do GetComponents ao processo de sujidade de cada elemento de layout filho, o que torna os grupos de layout aninhados extremamente prejudiciais ao desempenho.

Solução: Evite grupos de layout sempre que possível.

Use âncoras para layouts proporcionais. Em IUs com uma quantidade dinâmica de elementos, considere escrever seu próprio código que irá calcular os layouts e certifique-se de usá-los somente quando necessário em vez de com cada mudança.

Agrupe objetos da IU de maneira inteligente

Problema: Agrupar objetos IU de forma incorreta.

Muitas vezes, as pessoas agrupam objetos da IU, alterando a hierarquia de pai e depois desativando, mas isso causa alterações desnecessárias.

Solução: Primeiro desative o objeto e depois altere a hierarquia de pai no agrupamento.

Você vai alterar a antiga hierarquia uma vez, mas, quando você altere a hierarquia de pai, você evitará alterar a antiga hierarquia pela segunda vez. A nova hierarquia permanece inalterada. Se você estiver removendo um objeto do agrupamento, primeiro altere a hierarquia de pai, atualize seus dados e depois habilite-o.

Como ocultar um Canvas

Como ocultar um Canvas

Às vezes, é necessário ocultar alguns elementos da IU e canvas. Como proceder de forma mais eficiente?

Solução: Desative o próprio componente de canvas

Desativar o componente Canvas faz com que o Canvas pare de emitir draw calls para a GPU e, portanto, não é mais visível. O Canvas não exclui seu buffer de vértice; todas as malhas e vértices são preservados e se você os reativar, não irá desencadear uma reconstrução, apenas começará a desenhá-los novamente.

Além disso, desativar o componente de canvas não desencadeia Callbacks custosas OnDisable / OnEnable na hierarquia do Canvas. Certifique-se de desativar os Componentes filhos que executam código dispendioso por frame.

Uso ótimo de animadores em elementos da IU

Problema: Uso de animadores em sua IU

Os animadores sujam seus elementos em cada frame, mesmo que o valor na animação não mude. Os animadores não têm verificações não operacionais.

Solução:

Only put animators on dynamic elements that always change. For elements that rarely change or that only change in response to events, for a short period of time, write your own code or tweening system (there are a number on the Asset Store).

Mais recursos

Queremos saber! Você gostou deste conteúdo?

Sim, continue. Bem. Poderia ser melhor
Eu entendi

Usamos cookies para garantir a melhor experiência no nosso site. Visite nossa página da política de cookies para obter mais informações.