UI Toolkit vs uGUI (Canvas): Qual Usar na Unity

UI Toolkit vs uGUI, direto ao ponto: no Unity 6.3, o UI Toolkit é a escolha mais forte para jogos com muitas telas (menus, inventário, opções, HUD extenso), por causa do layout flexível, dos estilos globais em USS e do data binding. O uGUI (o sistema de Canvas) continua melhor quando a UI precisa ser animada com Animation Clips e Timeline, montada direto na cena ou ligada a eventos configurados no Inspector. Os dois convivem no mesmo projeto, e muitos jogos usam ambos.

Abaixo está como cada um funciona, onde cada um ganha, o que muda em performance e uma tabela de decisão por tipo de projeto.

UI Toolkit vs uGUI: o resumo

A tabela segue a comparação oficial do manual do Unity 6.3 (página "Comparison of UI systems in Unity"), com a última linha como observação prática.

Como cada sistema funciona

uGUI é o sistema baseado em GameObjects. Um Canvas contém objetos com RectTransform (posição, tamanho, âncoras) e componentes visuais: Image, TextMeshPro, Button. Cada botão é um objeto na hierarquia, com Inspector próprio, que pode receber scripts, Animators e eventos no campo On Click (). No Unity 6, o TextMeshPro faz parte do próprio pacote Unity UI, sem instalação separada.

UI Toolkit é baseado em documentos. A estrutura fica num arquivo UXML, o visual num USS (sintaxe parecida com CSS) e a cena só tem um UIDocument que aponta para o UXML e para um Panel Settings. Os elementos não são GameObjects: o script encontra cada um com root.Q<Button>("nome"). O layout é calculado por um motor flexbox, e a renderização é feita por um sistema próprio, montado sobre a camada gráfica da Unity.

A consequência prática é organizacional. No uGUI, mudar a cor de todos os botões significa editar um prefab ou cada botão. No UI Toolkit, você muda uma classe no USS. Em contrapartida, no uGUI você arrasta um Animator num botão e anima qualquer propriedade com a janela Animation; no UI Toolkit isso não existe, e animações ficam nas transições do USS ou em código.

Onde o uGUI ainda ganha

• Animação com keyframes e Timeline. Logo animado, tela de vitória coreografada, UI que entra junto com uma cutscene. O manual recomenda o uGUI justamente para UI que exige animação com keyframes.
• Edição dentro da cena. Você vê e move a UI na Scene view, junto com o jogo. Para UI presa a objetos (placa de loja, painel de nave), isso agiliza muito.
• Referência fácil a partir de MonoBehaviours. Arrastar um Button ou Image para um campo [SerializeField] e configurar o On Click () no Inspector, sem escrever busca por nome. O manual cita esse ponto, junto com a animação por keyframes, como os casos em que o uGUI é a recomendação.
• Ecossistema. Anos de tutoriais, assets da Asset Store e respostas em fórum estão em uGUI. Para quem aprende sozinho, isso conta.
• Projetos existentes. Migrar uma UI pronta de uGUI para UI Toolkit raramente compensa no meio do desenvolvimento.

Onde o UI Toolkit ganha

• Muitas telas. Menus, opções, inventário, loja, diálogos. Estilo global e templates UXML reaproveitáveis reduzem muito o retrabalho.
• Trabalho com artista ou designer. O UI Builder e o USS são familiares para quem já mexeu com web, e mudam a aparência sem tocar no código.
• Data binding. Ligar propriedades de um objeto a campos da tela sem o código de cola de "quando a vida mudar, atualize a barra".
• Layout que se adapta. Flexbox resolve listas, grades e telas de proporções diferentes com menos ajuste manual que Layout Groups.
• Recursos visuais: elementos sem textura (bordas arredondadas e cores sem sprite), atlas dinâmico, anti-aliasing de UI, SVG, emoji e idiomas da direita para a esquerda.
• Ferramentas de editor. Se você também vai criar janelas e inspectors personalizados, o UI Toolkit é o recomendado para o editor, então aprende uma coisa só para os dois lados.

Sobre UI no mundo 3D e shaders: muito tutorial por aí afirma que o UI Toolkit não faz world space nem materiais personalizados. A tabela do Unity 6.3 lista os dois como suportados. Se o seu projeto usa outra versão do editor, confira a tabela do manual daquela versão antes de decidir.

Escolher o sistema de UI é uma decisão pequena perto do que vem depois: ligar menus, HUD, pausa e opções à lógica do jogo sem um emaranhado de referências. Esse é o tipo de estrutura que o curso de Unity constrói com você dentro de um jogo completo, explicando o porquê de cada escolha.

Performance e escala de telas

Sem números mágicos, porque performance de UI depende do que a tela faz. Os princípios:

uGUI: quando um elemento muda, o Canvas inteiro precisa reconstruir a geometria. Uma barra de vida atualizada todo frame dentro do mesmo Canvas do menu estático força a reconstrução de tudo. A prática conhecida é separar em Canvases diferentes o que muda muito e o que é estático, e desligar Raycast Target em imagens e textos que não recebem clique.

UI Toolkit: trabalha em modo retido e só refaz o que mudou. Os elementos não são GameObjects, então uma lista com centenas de itens não cria centenas de objetos com Transform. Para listas longas, use ListView, que recicla os elementos visíveis.

Nos dois casos, a regra que mais importa é a mesma: atualize a UI quando o dado muda, e não em todo frame. E meça com o Profiler no aparelho alvo antes de otimizar. O post de UI/UX design para jogos tem uma seção sobre o que realmente pesa em interface.

Qual usar por tipo de projeto

Se você está começando e ainda decidindo se vai seguir com a Unity, o post vale a pena aprender Unity ajuda a colocar essa escolha no contexto maior.

Dá para misturar os dois no mesmo jogo?

Dá, e é comum. Uma divisão que funciona:

• UI Toolkit para tudo que é tela sobreposta: menu principal, pausa, opções, inventário, HUD.
• uGUI para o que precisa de Timeline ou Animator, e para UI presa a objetos quando você prefere montar direto na cena.

Cuidados ao misturar:

1. Um dono por tela. Não divida a mesma tela entre os dois sistemas. Fica difícil saber quem está por cima e quem recebe o clique.
2. Input. O uGUI precisa de um EventSystem com o Input System UI Input Module. O UI Toolkit processa o input dos seus painéis. Teste clique e navegação por controle nas telas dos dois sistemas.
3. Estilo visual. Fontes e cores precisam bater nos dois lados. Defina a paleta e a fonte uma vez e replique no USS e nos prefabs do uGUI.

Para aprender o fluxo do UI Toolkit na prática, com UI Builder, USS e o script que liga os botões, siga o tutorial de UI Toolkit.

Próximo passo

Faça um teste curto: monte o mesmo menu de três botões nos dois sistemas. Leva menos de uma hora, e você descobre qual fluxo combina com a sua cabeça. Depois, escolha um para as telas principais do seu jogo e mantenha a decisão até o fim do projeto.