Tidak. UniText tidak membakar atlas tekstur setiap fon ke dalam binaan anda. Glyph dirasterkan pada masa jalan ke dalam atlas dikongsi (berasaskan Texture2DArray) dengan pengiraan rujukan setiap glyph dan penyingkiran LRU. Hanya data fon yang dihantar dalam binaan anda — tidak sekali-kali atlas. Selain itu, Pemampatan Fon terbina dalam (Zstd, tahap 22) mengecilkan data fon sehingga ~2.7× untuk Latin/Arab (CJK lebih sederhana, ~1.3×).

Tidak. Aset UniTextFont membenamkan bait fon di dalam dirinya sendiri. Rujukan kepada fon sumber adalah khusus Editor sahaja (dibalut dalam #if UNITY_EDITOR) — ia sememangnya tidak wujud dalam binaan pemain, jadi ia bukan kebergantungan masa jalan dan tidak akan ditarik ke dalam AssetBundle melalui carian kebergantungan. Anda boleh memadam .ttf sebaik sahaja aset dicipta.

Tidak. Anda boleh membina UniTextFont daripada .ttf yang terletak di mana-mana pada cakera anda melalui tetingkap alat UniText (dialog fail membaca bait secara terus). Mengimport fon ke dalam projek adalah pilihan.

• WebGL: binaan kosong adalah ≈ 6–10 MB (ia berbeza mengikut versi Unity dan pakej yang dipasang); UniText menambah pustaka aslinya (HarfBuzz, FreeType). Ini adalah pustaka standard industri yang sama seperti yang dihantar oleh Advanced Text Generator UI Toolkit Unity sendiri — tiada yang eksotik (UniText hanya membawa salinannya sendiri). • Android: APK dengan dua seni bina membawa kedua-duanya — lebih kurang +4 MB setiap seni bina. Tetapi apabila anda menerbitkan AAB, Google Play menghantar bundle khusus peranti, jadi pengguna memuat turun hanya seni bina mereka sendiri (~4 MB), bukan kedua-duanya.

Dengan TMP dalam mod Static atlas-population, membakar set glyph penuh bagi fon CJK biasa membengkakkan binaan sebanyak berpuluh hingga beratus MB (beberapa atlas 4096²/8192²; jangkakan ~80–250 MB bergantung pada bilangan glyph dan resolusi). Perkara utama: beban UniText tidak berskala dengan bilangan glyph — ia adalah beberapa MB yang sama sama ada anda menghantar Latin atau CJK penuh.

Ya — itu di pihak pembangun, dan UniText tidak menghalang. Muat turun bait fon dengan kod anda sendiri (UnityWebRequest) dan bina UniTextFont daripadanya pada masa jalan melalui CreateFontAsset(byte[]). Untuk memangkas fon kepada hanya aksara yang anda perlukan (subsetting), gunakan alat masa binaan UniText. Tiada pemuat automatik CDN terbina dalam pakej — itu sengaja menjadi tanggungjawab projek, bukan enjin.

Ya — SystemFont membaca fail fon terus daripada OS pada masa jalan, jadi ia tidak memberi kesan pada saiz binaan (tiada apa yang dibakar). Resolusi bersifat malas (pada penggunaan pertama), jadi ia tidak memperlahankan permulaan aplikasi.

Tidak — dan itu adalah batasan pelayar, bukan batasan UniText. Kotak pasir pelayar tidak mendedahkan fon OS. Untuk WebGL, benamkan fon dalam aset UniTextFont (atau muatkan bait itu sendiri — lihat soalan CDN di atas).

Glyph terletak dalam jubin tiga saiz — 64, 128, 256 — dan saiz dipilih daripada kerumitan kontur (banyak segmen → 128/256, kontur ringkas → 64). • SDF Detail ialah pengganda pada anggaran kerumitan. Naikkannya dan glyph yang sememangnya tidak remeh lebih berkemungkinan naik ke jubin yang lebih besar. (Bentuk yang benar-benar ringkas kekal pada 64 — pengganda hanya mempengaruhi glyph di atas ambang.) • Tile Size Offset ialah langkah keras sepanjang tangga saiz (dipilih 64 + offset 1 → 128; julat −2..+2).

Tiada satu pun secara berasingan — kedua-duanya hanya menentukan saiz jubin akhir, dan kos ditetapkan oleh saiz itu sahaja. Dua kombinasi yang menghasilkan saiz jubin yang sama berkos betul-betul sama. Sasarkan saiz jubin terkecil yang masih memberikan kualiti yang boleh diterima.

Hanya apabila glyph belum ada dalam atlas — tidak sekali-kali setiap bingkai. Untuk “Hello world” ia meraster glyph unik H e l o w r d. H kedua tidak melakukan apa-apa; a meraster hanya a.

Kos adalah berkadar dengan bilangan glyph unik yang pertama kali dilihat dan dirasterkan pada bingkai itu — bukan dengan panjang teks. Dalam penanda aras kami, ~2000 glyph unik pada bingkai pertama adalah ≈ 1 saat pada peranti Android biasa; TMP dan UI Toolkit mengambil masa 10+ saat dalam senario yang sama. Menggunakan semula glyph cache adalah percuma.

UniText hampir tidak bergantung pada Unity Job System pada laluan panas — secara reka bentuk. Rasterisasi glyph (lpSDF / lpMSDF proprietari kami) berjalan pada GPU melalui compute shader secara lalai; kerja Burst hanyalah sandaran CPU apabila compute tidak tersedia. Multithreading utama — pembentukan, susun atur, penjanaan mesh — berjalan pada kumpulan benang OS UniText sendiri (bukan Unity Jobs, sebab itulah ia tidak muncul dalam profiler Jobs). Jadi “tiada kerja UniText” tidak bermakna “benang dimatikan”: sama ada kerja itu pergi ke GPU, atau atlas sudah panas, atau teks berada di bawah ambang keselarian (label pendek atau tunggal diproses secara berurutan — ia lebih murah begitu).

“Update() lambat” ialah mitos untuk binaan keluaran. Beban panggilan kaedah ajaib daripada kod asli adalah nyata tetapi boleh diabaikan (~1000 panggilan ≈ 0.16 ms) — ia bukan penghambat. Kos sebenar dalam kod naif ialah susun atur memori AoS, bukan panggilan balik itu sendiri; UniText menggunakan SoA di tempat yang penting (atribut Unicode, metrik, penimbal setiap piksel). (Ini juga sebabnya ECS pantas — kerana SoA, bukan “keajaiban ECS”.) Dan UniText tetap berpusat — cuma bukan sebagai pengurus MonoBehaviour: Update() sendiri hampir kosong, dan kerja berat dikumpulkan ke dalam satu laluan berkelompok pada panggilan balik pemaparan Canvas (yang juga memberikan keselarian merentas komponen).