Não. O UniText não embute atlas de textura por fonte na sua build. Os glifos são rasterizados em runtime em um atlas compartilhado (baseado em Texture2DArray) com contagem de referências por glifo e remoção LRU. Só os dados da fonte vão para a sua build — nunca os atlas. Além disso, a Compressão de Fontes integrada (Zstd, nível 22) reduz os dados da fonte em até ~2.7× para latim/árabe (CJK é mais modesto, ~1.3×).

Não. O asset UniTextFont embute os bytes da fonte dentro de si mesmo. A referência à fonte de origem existe apenas no Editor (envolvida em #if UNITY_EDITOR) — ela simplesmente não existe em uma build de player, então não é uma dependência de runtime e não será puxada para um AssetBundle pela resolução de dependências. Você pode apagar o .ttf assim que o asset for criado.

Não. Você pode criar um UniTextFont a partir de um .ttf localizado em qualquer lugar do seu disco pela janela de ferramentas do UniText (a caixa de diálogo de arquivo lê os bytes diretamente). Importar a fonte para o projeto é opcional.

• WebGL: uma build vazia tem ≈ 6–10 MB (varia conforme a versão do Unity e os pacotes instalados); o UniText adiciona suas bibliotecas nativas (HarfBuzz, FreeType). São as mesmas bibliotecas padrão da indústria que o próprio Advanced Text Generator do UI Toolkit do Unity distribui — nada exótico (o UniText apenas carrega suas próprias cópias). • Android: um APK com duas arquiteturas carrega ambas — cerca de +4 MB por arquitetura. Mas quando você publica um AAB, o Google Play entrega um bundle específico do dispositivo, então o usuário baixa apenas a sua própria arquitetura (~4 MB), não ambas.

Com o TMP no modo Static de população de atlas, gerar o conjunto completo de glifos de uma fonte CJK típica infla a build em dezenas a centenas de MB (vários atlas 4096²/8192²; espere ~80–250 MB dependendo da quantidade de glifos e da resolução). O ponto-chave: a sobrecarga do UniText não escala com a quantidade de glifos — são os mesmos poucos MB, quer você distribua latim ou CJK completo.

Sim — isso fica do lado do desenvolvedor, e o UniText não atrapalha. Baixe os bytes da fonte com seu próprio código (UnityWebRequest) e crie um UniTextFont a partir deles em runtime via CreateFontAsset(byte[]). Para reduzir uma fonte a apenas os caracteres de que você precisa (subsetting), use a ferramenta de build-time do UniText. Não há um auto-carregador de CDN embutido no pacote — isso é, deliberadamente, responsabilidade do projeto, não do motor.

Sim — o SystemFont lê o arquivo da fonte diretamente do SO em runtime, então não tem efeito no tamanho da build (nada é embutido). A resolução é preguiçosa (no primeiro uso), então não deixa a inicialização do app mais lenta.

Não — e essa é uma limitação do navegador, não do UniText. O sandbox do navegador não expõe as fontes do SO. Para WebGL, embuta uma fonte em um asset UniTextFont (ou carregue os bytes você mesmo — veja a pergunta sobre CDN acima).

Os glifos ficam em tiles de três tamanhos — 64, 128, 256 — e o tamanho é escolhido a partir da complexidade do contorno (muitos segmentos → 128/256, um contorno simples → 64). • SDF Detail é um multiplicador sobre a estimativa de complexidade. Aumente-o e um glifo já não-trivial tem mais chance de subir para um tile maior. (Uma forma genuinamente simples permanece em 64 — o multiplicador só afeta glifos acima do limiar.) • Tile Size Offset é um passo fixo na escala de tamanhos (64 escolhido + offset 1 → 128; faixa −2..+2).

Nenhum isoladamente — ambos apenas decidem o tamanho final do tile, e o custo é determinado apenas por esse tamanho. Duas combinações que resultam no mesmo tamanho de tile custam exatamente o mesmo. Busque o menor tamanho de tile que ainda ofereça qualidade aceitável.

Apenas quando um glifo ainda não está no atlas — nunca a cada frame. Para “Hello world” ele rasteriza os glifos únicos H e l o w r d. Um segundo H não faz nada; um a rasteriza apenas o a.

O custo é proporcional à quantidade de glifos únicos, vistos pela primeira vez, rasterizados naquele frame — não ao comprimento do texto. No nosso benchmark, ~2000 glifos únicos no primeiro frame equivalem a ≈ 1 segundo em um dispositivo Android típico; o TMP e o UI Toolkit levam 10+ segundos no mesmo cenário. Reutilizar glifos em cache é de graça.

O UniText mal depende do Unity Job System no hot path — por design. A rasterização de glifos (nossos proprietários lpSDF / lpMSDF) roda na GPU via um compute shader por padrão; jobs Burst são apenas o fallback de CPU quando o compute não está disponível. O principal multithreading — shaping, layout, geração de mesh — roda no próprio pool de threads de SO do UniText (não no Unity Jobs, e é por isso que eles não aparecem no profiler de Jobs). Então “nenhum job do UniText” não significa “as threads estão desligadas”: ou o trabalho foi para a GPU, ou o atlas já está aquecido, ou o texto está abaixo do limiar de paralelismo (labels curtos ou únicos são processados sequencialmente — assim sai mais barato).

“Update() é lento” é um mito para builds de release. A sobrecarga da chamada do método mágico a partir do código nativo é real, mas desprezível (~1000 chamadas ≈ 0.16 ms) — não é o gargalo. O verdadeiro custo em código ingênuo é o layout de memória AoS, não o callback em si; o UniText aplica SoA onde importa (atributos Unicode, métricas, buffers por pixel). (É também por isso que o ECS é rápido — por causa do SoA, não de uma “mágica do ECS”.) E o UniText é centralizado de qualquer forma — só que não como um manager MonoBehaviour: o próprio Update() é quase vazio, e o trabalho pesado é reunido em uma única passada em lote nos callbacks de render do Canvas (que é também o que proporciona o paralelismo entre componentes).