Unity uGUI: divida Canvases de acordo com as mudanças que realmente ocorrem

Identifique o trabalho que uma mudança dispara

Um Canvas do uGUI organiza a renderização e o batching da interface. Quando elementos mudam, o Unity pode precisar regenerar a geometria afetada e reavaliar os batches do Canvas. Um pequeno rótulo que muda pode, portanto, gerar trabalho além do próprio rótulo. O recálculo de layout é outra preocupação: ele define tamanhos e posições por meio de elementos e controladores de layout. Diagnostique o trabalho relevante em vez de tratar todo custo de UI como o mesmo tipo de rebuild. [1][3]

Agrupe os elementos pelo comportamento de mudança

A Unity recomenda separar a UI estática dos grupos que mudam com frequência. Um Canvas filho mantém sua própria geometria e seu próprio batching, isolando esse trabalho de renderização do Canvas pai e dos irmãos. Canvases aninhados usam o modo de renderização do pai. [1][2]

Antes de dividir, faça um pequeno mapa das mudanças reais: quais elementos são animados juntos, quais só mudam quando um menu abre e quais permanecem fixos? Dê às mudanças relacionadas um limite útil. Criar um Canvas separado para cada ícone pode fragmentar o batching sem resolver nenhum problema relevante de invalidação. Avalie em conjunto o número de batches resultante e o trabalho de CPU.

Projete um display de cockpit como exemplo

Imagine um cockpit com uma moldura decorativa, rótulos fixos, um número de combustível e uma faixa de alerta animada. Mantenha a moldura e os rótulos em um Canvas predominantemente estático. Coloque o display de combustível e a faixa de alerta em um grupo dinâmico menor, se as mudanças observadas justificarem esse agrupamento.

Suponha que o projeto exija que o valor de combustível exibido seja atualizado a cada 0,1 segundo. Atualize essa apresentação apenas quando o valor exibido mudar; a simulação subjacente pode manter seu próprio ritmo. Reserve largura suficiente para o formato numérico previsto, de modo que o rótulo não precise empurrar os controles vizinhos. Essas são escolhas de projeto propostas, não economias medidas.

Inspecione as dependências de layout separadamente

Um Layout Group controla o tamanho e a posição dos filhos a partir dos tamanhos mínimo, preferido e flexível informados por eles. O texto pode influenciar seu tamanho preferido, e um Content Size Fitter pode redimensionar o próprio elemento com base nessa informação. Siga essa cadeia de dependências quando uma mudança de texto mover um painel maior. [3]

Uma divisão de Canvas é um limite de renderização; por isso, verifique também se controladores de layout ainda ligam o conteúdo que muda aos controles ao redor. Remova aninhamentos desnecessários ou dê às regiões estáveis um contrato de layout deliberado. A reconstrução de layout normal, depois de marcada, é adiada até pouco antes da renderização, o que permite processar as mudanças em conjunto; evite exigir recálculo imediato sem uma necessidade concreta. [1][3]

Valide o equilíbrio entre interação e renderização

Capture a interface enquanto o combustível muda, um alerta é animado e o menu abre. Compare, antes e depois da divisão proposta, o trabalho de CPU com rebuild e layout, o número de batches e a correção visual. Verifique as resoluções suportadas e rótulos localizados mais longos. Uma tela ociosa mais barata não basta se abrir o menu ainda causa a mudança custosa.

Remova Graphic Raycasters dos Canvases que não precisam de entrada e, quando apropriado, desative Raycast Target nos elementos gráficos decorativos. Isso reduz trabalho de entrada não relacionado, mas não substitui a correção do comportamento de rebuild. Mantenha as divisões cujo benefício medido justifique a hierarquia e a complexidade de renderização adicionais. [1]

Fontes

1. Unity UI performance optimization tips — Unity Technologies.
2. Canvas — Unity Technologies.
3. Auto Layout — Unity Technologies.