Ei. UniText ei leivo fonttikohtaisia tekstuuriatlaksia buildiisi. Glyyfit rasteroidaan ajonaikaisesti jaettuun atlakseen (Texture2DArray-pohjaiseen), jossa on glyyfikohtainen viittauslaskenta ja LRU-poisto. Vain fonttidata toimitetaan buildissasi — ei koskaan atlaksia. Tämän päälle sisäänrakennettu Font Compression (Zstd, taso 22) pienentää fonttidataa jopa ~2.7× latinalaisilla/arabialaisilla (CJK on maltillisempi, ~1.3×).

Ei. UniTextFont-asset upottaa fonttitavut sisäänsä. Viittaus lähdefonttiin on vain Editorille tarkoitettu (kääritty #if UNITY_EDITOR -lohkoon) — sitä ei yksinkertaisesti ole player-buildissa, joten se ei ole ajonaikainen riippuvuus eikä sitä vedetä AssetBundleen riippuvuushaun kautta. Voit poistaa .ttf-tiedoston, kun asset on luotu.

Ei. Voit rakentaa UniTextFontin mistä tahansa levylläsi sijaitsevasta .ttf-tiedostosta UniText-työkaluikkunan kautta (tiedostodialogi lukee tavut suoraan). Fontin tuominen projektiin on valinnaista.

• WebGL: tyhjä build on ≈ 6–10 MB (se vaihtelee Unity-version ja asennettujen pakettien mukaan); UniText lisää natiivikirjastonsa (HarfBuzz, FreeType). Nämä ovat samat alan standardikirjastot, jotka Unityn oma UI Toolkit Advanced Text Generator toimittaa — ei mitään eksoottista (UniText vain kantaa omat kopionsa). • Android: kahden arkkitehtuurin APK sisältää molemmat — noin +4 MB arkkitehtuuria kohti. Mutta kun julkaiset AAB:n, Google Play toimittaa laitekohtaisen bundlen, joten käyttäjä lataa vain oman arkkitehtuurinsa (~4 MB), ei molempia.

TMP:llä Static atlas-population -tilassa tyypillisen CJK-fontin koko glyyfijoukon leipominen paisuttaa buildia kymmenillä tai sadoilla megatavuilla (useita 4096²/8192² atlaksia; odota ~80–250 MB glyyfien määrästä ja resoluutiosta riippuen). Olennainen pointti: UniTextin lisäkuorma ei skaalaudu glyyfien määrän mukaan — se on samat muutamat MB riippumatta siitä, toimitatko latinalaista vai koko CJK:ta.

Kyllä — se on kehittäjän puolella, eikä UniText ole tiellä. Lataa fonttitavut omalla koodillasi (UnityWebRequest) ja rakenna niistä UniTextFont ajonaikaisesti funktiolla CreateFontAsset(byte[]). Karsiaksesi fontin vain tarvitsemiisi merkkeihin (subsetting) käytä UniTextin buildin aikaista työkalua. Paketissa ei ole sisäänrakennettua CDN-automaattilataajaa — se on tarkoituksella projektin vastuulla, ei moottorin.

Kyllä — SystemFont lukee fonttitiedoston suoraan käyttöjärjestelmästä ajonaikaisesti, joten sillä ei ole vaikutusta buildin kokoon (mitään ei leivota). Fontin selvitys on laiska (tapahtuu ensimmäisellä käytöllä), joten se ei hidasta sovelluksen käynnistystä.

Ei — ja se on selaimen rajoitus, ei UniTextin. Selaimen hiekkalaatikko ei paljasta käyttöjärjestelmän fontteja. WebGL:ssä upota fontti UniTextFont-assetiin (tai lataa tavut itse — katso yllä oleva CDN-kysymys).

Glyyfit sijaitsevat kolmen kokoisissa ruuduissa — 64, 128, 256 — ja koko valitaan ääriviivan monimutkaisuudesta (monta segmenttiä → 128/256, yksinkertainen ääriviiva → 64). • SDF Detail on kerroin monimutkaisuusarviolle. Nosta sitä, niin jo ennestään ei-triviaali glyyfi siirtyy todennäköisemmin suurempaan ruutuun. (Aidosti yksinkertainen muoto pysyy koossa 64 — kerroin vaikuttaa vain kynnyksen ylittäviin glyyfeihin.) • Tile Size Offset on kova askel kokoportaikossa (valittu 64 + siirtymä 1 → 128; alue −2..+2).

Ei kumpaakaan erikseen — molemmat vain päättävät lopullisen ruudun koon, ja kustannuksen määrää yksin tuo koko. Kaksi yhdistelmää, jotka päätyvät samaan ruudun kokoon, maksavat täsmälleen saman verran. Tavoittele pienintä ruudun kokoa, joka silti antaa hyväksyttävän laadun.

Vain silloin, kun glyyfi ei ole jo atlaksessa — ei koskaan joka framella. Tekstille “Hello world” se rasteroi uniikit glyyfit H e l o w r d. Toinen H ei tee mitään; a rasteroi vain a:n.

Kustannus on verrannollinen sinä framella rasteroitujen uniikkien, ensi kertaa nähtyjen glyyfien määrään — ei tekstin pituuteen. Benchmarkissamme ~2000 uniikkia glyyfiä ensimmäisellä framella on ≈ 1 sekunti tyypillisellä Android-laitteella; TMP ja UI Toolkit vievät 10+ sekuntia samassa skenaariossa. Välimuistissa olevien glyyfien uudelleenkäyttö on ilmaista.

UniText tuskin nojaa Unityn Job Systemiin kuumalla polulla — tarkoituksella. Glyyfien rasterointi (oma lpSDF / lpMSDF -tekniikkamme) ajetaan oletuksena GPU:lla compute shaderilla; Burst-jobit ovat vain CPU-varajärjestelmä, kun compute ei ole käytettävissä. Pääasiallinen monisäikeisyys — muotoilu, asettelu, meshin generointi — ajetaan UniTextin omassa OS-säiepoolissa (ei Unity Jobs, minkä vuoksi ne eivät näy Jobs-profilerissa). Joten “ei UniText-jobia” ei tarkoita “säikeet ovat pois päältä”: joko työ meni GPU:lle, tai atlas on jo lämmin, tai teksti on rinnakkaisuuskynnyksen alapuolella (lyhyet tai yksittäiset labelit käsitellään peräkkäin — se on halvempaa).

“Update() on hidas” on myytti release-buildeille. Maagisen metodikutsun lisäkuorma natiivikoodista on todellinen mutta merkityksetön (~1000 kutsua ≈ 0.16 ms) — se ei ole pullonkaula. Todellinen kustannus naiivissa koodissa on AoS-muistilayout, ei itse takaisinkutsu; UniText soveltaa SoA:ta siellä, missä sillä on merkitystä (Unicode-attribuutit, metriikat, pikselikohtaiset puskurit). (Tämä on myös syy, miksi ECS on nopea — SoA:n ansiosta, ei “ECS-taikuuden”.) Ja UniText on joka tapauksessa keskitetty — vain ei MonoBehaviour-managerina: Update() itsessään on lähes tyhjä, ja raskas työ kootaan yhteen niputettuun ajoon Canvasin render-takaisinkutsuissa (mikä myös antaa komponenttien välisen rinnakkaisuuden).