1.1 Linguagem, bibliotecas e runtime

A Unity anunciou a migração para o runtime moderno do .NET (CoreCLR); até lá, confira sempre se um recurso da linguagem ou uma biblioteca NuGet funciona no Unity antes de construir em cima dele. Alguns recursos do C# 9 que dependem de tipos do runtime novo (como init e record) exigem declarar um tipo auxiliar ou não funcionam como esperado.

1.2 O que mais surpreende quem vem do .NET

• Não há Main. O motor controla o laço principal e chama os seus componentes (módulo 2).
• Não se usam construtores em MonoBehaviour. O motor cria os componentes; a inicialização vai para Awake/Start.
• Quase toda a API do motor só funciona na thread principal (módulo 5).
• Alocar é caro de uma forma que num servidor web não seria — o GC pode causar engasgos visíveis (módulo 7).
• Objetos do motor têm dois lados: um objeto C# e um objeto nativo em C++. Daí o "null falso" (módulo 4).

2.1 Os métodos principais

2.2 A regra de ouro da inicialização

Em Awake, prepare-se a si próprio; em Start, fale com os outros. A ordem de Awake entre objetos diferentes não é garantida. Se o objeto A lê em Awake um valor que B só define no seu Awake, o resultado depende da sorte — e muda entre o editor e o build. A ordem pode ser forçada em Script Execution Order, mas é melhor não depender dela.

2.3 Tempo

void Update()
{
    // independente do frame rate: unidades por segundo × segundos deste quadro
    transform.position += direcao * velocidade * Time.deltaTime;
}

void FixedUpdate()
{
    // física: dentro do passo fixo; não multiplique forças por deltaTime
    corpo.AddForce(empurrao);
}

3.1 As regras

O Unity guarda (serializa) um campo se ele for público ou marcado com [SerializeField], não estático, não const, não readonly, e de um tipo serializável: tipos primitivos, string, enums, tipos do Unity (Vector3, Color, AnimationCurve…), referências a UnityEngine.Object (GameObject, componentes, assets), classes e structs marcadas com [Serializable], e arrays ou List<T> desses tipos.

Não são serializados: propriedades, dicionários, arrays multidimensionais, listas de listas, campos estáticos, e referências a interfaces ou classes abstratas (a não ser com [SerializeReference]).

3.2 Três armadilhas

• O valor do Inspector vence o inicializador. Mudar public float velocidade = 5f; para = 8f no código não altera objetos já existentes: eles guardaram 5 na cena. Só objetos novos recebem o valor novo.
• Renomear um campo perde os dados. O Unity guarda pelo nome. Use [FormerlySerializedAs("nomeAntigo")] ao renomear campos que já têm dados em cenas e prefabs.
• Público só para serializar é mau encapsulamento. Prefira [SerializeField] private: o Inspector vê, o resto do código não.

public class Inimigo : MonoBehaviour
{
    [SerializeField] private float velocidade = 5f;           // no Inspector, privado para o código
    [field: SerializeField] public int Vida { get; private set; } // serializa o campo por trás da propriedade
    [FormerlySerializedAs("dano")]
    [SerializeField] private int danoPorGolpe;                // renomeado sem perder os valores
}

4.1 Dois objetos em um

Cada GameObject, componente ou asset tem um lado C# (o objeto gerenciado) e um lado nativo (em C++, dentro do motor). Quando se chama Destroy, o lado nativo desaparece, mas o objeto C# continua a existir enquanto houver referências a ele. Para esconder isso, UnityEngine.Object sobrecarrega o operador ==: um objeto destruído compara como igual a null, embora a referência C# não seja nula.

4.2 Onde isso morde

4.3 Destroy não é imediato

Destroy(obj) marca o objeto e só o destrói no fim do quadro. No resto do quadro atual, ele ainda existe e responde. Código que destrói e, na linha seguinte, conta os objetos na cena, conta também o destruído. DestroyImmediate é para scripts de editor, não para o jogo.

4.4 Procurar componentes

// TryGetComponent: não aloca quando o componente não existe (GetComponent aloca no editor)
if (outro.TryGetComponent(out Vida vida))
    vida.ReceberDano(10);

// guarde as referências; não procure em cada Update
Rigidbody _rb;
void Awake() => _rb = GetComponent<Rigidbody>();

5.1 Corrotinas

IEnumerator Piscar(int vezes)
{
    for (int i = 0; i < vezes; i++)
    {
        render.enabled = !render.enabled;
        yield return new WaitForSeconds(0.1f);   // continua no quadro certo, na thread principal
    }
    render.enabled = true;
}
// StartCoroutine(Piscar(6));

• Correm na thread principal — não são paralelismo, são uma forma de espalhar trabalho pelo tempo.
• Param quando o GameObject é desativado ou destruído — o que é quase sempre o que se quer.
• Não devolvem valores nem tratam exceções com facilidade.
• new WaitForSeconds aloca; num laço muito repetido, guarde-o num campo.

5.2 async/await com Awaitable

No Unity 6, o tipo Awaitable é a forma recomendada de usar async no motor: é integrado ao laço do Unity, tem métodos para esperar o próximo quadro, segundos, o próximo passo de física, e para mudar de thread.

async Awaitable AbrirPortaAsync()
{
    var ct = destroyCancellationToken;               // cancela se o objeto for destruído
    animador.SetTrigger("abrir");
    await Awaitable.WaitForSecondsAsync(1.2f, ct);
    colisor.enabled = false;

    await Awaitable.BackgroundThreadAsync();         // trabalho pesado fora da thread principal
    var caminho = CalcularRota(mapa);               // só C# puro aqui, nada de API do Unity
    await Awaitable.MainThreadAsync();                // volta antes de tocar na cena
    guia.Mostrar(caminho);
}

5.3 Qual usar

6.1 As opções

6.2 O par OnEnable / OnDisable

void OnEnable()  => jogador.VidaMudou += AtualizarBarra;
void OnDisable() => jogador.VidaMudou -= AtualizarBarra;

Inscrever em OnEnable e desinscrever em OnDisable cobre ativação, desativação e destruição. Um evento que continua a apontar para um componente destruído é uma das fontes mais comuns de MissingReferenceException intermitente e de vazamento de memória.

7.1 Por que o GC incomoda mais no Unity

O coletor de lixo do Unity não é geracional: quando corre, examina todo o heap gerenciado. Com o GC incremental (ativo por padrão nas versões recentes), o trabalho é dividido por vários quadros, o que reduz os picos — mas não elimina o custo. A regra de ouro continua: no código que corre a cada quadro, alocar zero.

7.2 Alocações escondidas

7.3 Pooling

using UnityEngine.Pool;

ObjectPool<Bala> _balas;
void Awake() => _balas = new ObjectPool<Bala>(
    createFunc:      () => Instantiate(prefab),
    actionOnGet:     b => b.gameObject.SetActive(true),
    actionOnRelease: b => b.gameObject.SetActive(false),
    defaultCapacity: 32);

// disparar: var b = _balas.Get();   ao acertar: _balas.Release(b);

Para medir, use a coluna GC Alloc do Profiler (em build de desenvolvimento no aparelho): o objetivo é 0 B por quadro durante a jogabilidade. Performance em aparelhos móveis e XR está em Meta Quest 3, módulos 6 e 7.

8.1 O problema e a resposta

O código de jogo típico corre numa só thread, com objetos espalhados pela memória. Para processar dezenas de milhares de elementos (partículas próprias, multidões, simulações, geração procedural), a Unity oferece duas peças:

• C# Job System: divide o trabalho por vários núcleos de forma segura, com verificação de concorrência (o motor avisa se dois jobs escrevem nos mesmos dados).
• Burst: compila jobs para código nativo altamente otimizado (com vetorização SIMD) — frequentemente muitas vezes mais rápido do que o mesmo C# em Mono.

8.2 Um job em miniatura

using Unity.Burst;
using Unity.Collections;
using Unity.Jobs;
using Unity.Mathematics;

[BurstCompile]
struct MoverJob : IJobParallelFor
{
    public NativeArray<float3> posicoes;
    [ReadOnly] public NativeArray<float3> velocidades;
    public float dt;

    public void Execute(int i) => posicoes[i] += velocidades[i] * dt;
}

// agendar:  var h = new MoverJob { posicoes = p, velocidades = v, dt = Time.deltaTime }.Schedule(p.Length, 64);
//           h.Complete();   // antes de ler os resultados
// NativeArray não é gerido pelo GC: faça Dispose() quando não precisar mais.

8.3 O C# que o Burst aceita

Burst compila um subconjunto chamado HPC# (High Performance C#): structs e tipos não gerenciados, NativeArray e outras coleções nativas, e o pacote Mathematics. Não aceita classes, strings gerenciadas, referências a GameObject ou componentes, nem exceções no caminho normal. É outro estilo de programar — orientado a dados.

8.4 ECS / DOTS

O pacote Entities (a parte "ECS" da pilha orientada a dados, DOTS) leva a ideia ao extremo: entidades sem GameObject, componentes como dados puros, sistemas que processam tudo em lote. Compensa em jogos com enormes quantidades de elementos; para a maioria dos projetos, Jobs + Burst em pontos quentes específicos dão a maior parte do ganho com muito menos mudança.

9.1 IL2CPP e AOT

Com IL2CPP, o código C# é convertido em C++ e compilado antes da execução (AOT). É obrigatório em plataformas como iOS, WebGL e consolas, e costuma ser mais rápido. Consequência: não há geração de código em tempo de execução. Reflection.Emit e expressões compiladas não funcionam, e alguns usos de genéricos só descobertos em execução podem falhar se o compilador não os tiver previsto.

9.2 Managed code stripping

Para reduzir o tamanho do build, o Unity remove código que parece não ser usado. Código chamado só por reflexão (serializadores, injeção de dependências, alguns plugins) parece não usado — e desaparece. O sintoma: funciona no editor, falha no build com erros de tipo ou método em falta. Soluções: [Preserve] nos tipos e métodos, ou um arquivo link.xml listando o que manter, e um nível de stripping menos agressivo enquanto se investiga.

9.3 Código de editor

• Código que usa UnityEditor não existe no build. Coloque-o em pastas Editor, num Assembly Definition só para editor, ou entre #if UNITY_EDITOR.
• Ferramentas úteis: [MenuItem] para comandos, inspetores personalizados, validações com OnValidate, [ContextMenu] para ações rápidas num componente.
• Assembly Definitions separam o código em módulos: compilação mais rápida e dependências explícitas (ver Unity para Aplicações, módulo 2).

9.4 Domain reload e campos estáticos

Ao entrar no Play Mode, o Unity recarrega por padrão todo o código (domain reload), o que repõe os campos estáticos. Muitas equipas desativam esse recarregamento (Enter Play Mode Options) para entrar em Play em segundos em vez de dezenas de segundos. Consequência: campos estáticos e eventos estáticos mantêm os valores da sessão anterior. Um singleton que "já existe" ou uma contagem que começa em 37 são os sintomas. A solução é repor o estado explicitamente:

[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)]
static void Repor() { _instancia = null; TotalInimigos = 0; }

10.1 Perguntas frequentes

10.2 Portfólio

1. Um projeto com código limpo e comentado no GitHub: [SerializeField] private, eventos desinscritos, sem alocações por quadro (com captura do Profiler a mostrar 0 B).
2. Uma demonstração de Jobs + Burst: a mesma simulação em MonoBehaviour e em jobs, com os tempos medidos.
3. Uma ferramenta de editor que poupa trabalho real (validador de cenas, gerador de níveis) — mostra que você sabe estender o motor.
4. Testes automatizados com o Unity Test Framework na lógica do jogo.

10.3 Fontes para continuar

• Manual do Unity: ordem de execução das funções de eventos; regras de serialização; Awaitable; Job System; Burst; managed code stripping; configurar o Enter Play Mode.
• E-books gratuitos da Unity sobre padrões de programação em C# para Unity e sobre otimização de performance.
• Blog técnico da Unity: os textos sobre o comportamento do == em UnityEngine.Object e sobre o GC incremental.
• Na Uniana: C#, Unity Essencial, Unity, Unity para Aplicações, Meta Quest 3.