Nie. UniText nie zapieka atlasów tekstur poszczególnych czcionek do Twojego buildu. Glify są rasteryzowane w runtime do współdzielonego atlasu (opartego na Texture2DArray) ze zliczaniem referencji per glif i eksmisją LRU. Do buildu trafiają wyłącznie dane czcionki — nigdy atlasy. Dodatkowo wbudowana kompresja czcionek (Zstd, poziom 22) zmniejsza dane czcionki nawet ~2.7× dla łaciny/arabskiego (CJK skromniej, ~1.3×).

Nie. Asset UniTextFont osadza bajty czcionki w sobie. Odwołanie do źródłowej czcionki istnieje tylko w Edytorze (opakowane w #if UNITY_EDITOR) — po prostu nie istnieje w buildzie gracza, więc nie jest zależnością w runtime i nie zostanie wciągnięte do AssetBundle przez wyszukiwanie zależności. Plik .ttf możesz usunąć, gdy asset zostanie utworzony.

Nie. Możesz zbudować UniTextFont z pliku .ttf znajdującego się w dowolnym miejscu na dysku, korzystając z okna narzędzia UniText (okno wyboru pliku czyta bajty bezpośrednio). Zaimportowanie czcionki do projektu jest opcjonalne.

• WebGL: pusty build waży ≈ 6–10 MB (zależnie od wersji Unity i zainstalowanych paczek); UniText dodaje swoje natywne biblioteki (HarfBuzz, FreeType). To te same standardowe w branży biblioteki, które dostarcza sam Advanced Text Generator z UI Toolkit Unity — nic egzotycznego (UniText po prostu nosi własne kopie). • Android: APK z dwiema architekturami niesie obie — około +4 MB na architekturę. Ale gdy publikujesz AAB, Google Play dostarcza bundle dopasowany do urządzenia, więc użytkownik pobiera tylko swoją architekturę (~4 MB), a nie obie.

Przy TMP w trybie zapełniania atlasu Static zapieczenie pełnego zestawu glifów typowej czcionki CJK rozdmuchuje build o dziesiątki do setek MB (kilka atlasów 4096²/8192²; spodziewaj się ~80–250 MB w zależności od liczby glifów i rozdzielczości). Kluczowa rzecz: narzut UniText nie skaluje się z liczbą glifów — to te same kilka MB, niezależnie od tego, czy dostarczasz łacinę, czy pełne CJK.

Tak — to leży po stronie dewelopera, a UniText nie staje na przeszkodzie. Pobierz bajty czcionki własnym kodem (UnityWebRequest) i zbuduj z nich UniTextFont w runtime przez CreateFontAsset(byte[]). Aby okroić czcionkę do samych potrzebnych znaków (subsetting), użyj narzędzia UniText działającego na etapie budowania. W paczce nie ma wbudowanego auto-ładowacza CDN — to celowo odpowiedzialność projektu, nie silnika.

Tak — SystemFont czyta plik czcionki bezpośrednio z systemu operacyjnego w runtime, więc nie ma wpływu na rozmiar buildu (nic nie jest zapiekane). Rozwiązywanie odbywa się leniwie (przy pierwszym użyciu), więc nie spowalnia startu aplikacji.

Nie — i to ograniczenie przeglądarki, nie UniText. Piaskownica przeglądarki nie udostępnia czcionek systemu operacyjnego. W przypadku WebGL osadź czcionkę w asset UniTextFont (albo załaduj bajty samodzielnie — zobacz pytanie o CDN powyżej).

Glify mieszczą się w kafelkach trzech rozmiarów — 64, 128, 256 — a rozmiar dobierany jest na podstawie złożoności konturu (wiele segmentów → 128/256, prosty kontur → 64). • SDF Detail to mnożnik szacowanej złożoności. Podnieś go, a i tak już nietrywialny glif z większym prawdopodobieństwem przeskoczy do większego kafelka. (Naprawdę prosty kształt zostaje przy 64 — mnożnik wpływa tylko na glify powyżej progu.) • Tile Size Offset to twardy krok po drabinie rozmiarów (wybrany 64 + offset 1 → 128; zakres −2..+2).

Żaden w oderwaniu — oba jedynie decydują o końcowym rozmiarze kafelka, a koszt wyznacza wyłącznie ten rozmiar. Dwie kombinacje, które sprowadzają się do tego samego rozmiaru kafelka, kosztują dokładnie tyle samo. Celuj w najmniejszy rozmiar kafelka, który wciąż daje akceptowalną jakość.

Tylko wtedy, gdy glifu nie ma jeszcze w atlasie — nigdy co klatkę. Dla „Hello world” rasteryzuje unikalne glify H e l o w r d. Drugie H nie robi nic; litera a rasteryzuje tylko samo a.

Koszt jest proporcjonalny do liczby unikalnych, widzianych po raz pierwszy glifów rasteryzowanych w danej klatce — a nie do długości tekstu. W naszym benchmarku ~2000 unikalnych glifów w pierwszej klatce to ≈ 1 sekunda na typowym urządzeniu z Android; TMP i UI Toolkit potrzebują w tym samym scenariuszu 10+ sekund. Ponowne użycie glifów z cache’u jest darmowe.

UniText niemal nie polega na Unity Job System na gorącej ścieżce — to celowe. Rasteryzacja glifów (nasze autorskie lpSDF / lpMSDF) domyślnie działa na GPU przez compute shader; zadania Burst są tylko awaryjnym rozwiązaniem na CPU, gdy compute jest niedostępny. Główna wielowątkowość — shaping, layout, generowanie meshu — działa na własnej puli wątków OS UniText (nie na Unity Jobs, dlatego nie pojawiają się w profilerze Jobs). Zatem „brak zadania UniText” nie oznacza „wątki są wyłączone”: albo praca trafiła na GPU, albo atlas jest już rozgrzany, albo tekst jest poniżej progu równoległości (krótkie lub pojedyncze etykiety przetwarzane są sekwencyjnie — tak jest taniej).

„Update() jest wolny” to mit w przypadku buildów release. Narzut wywołania magicznej metody z kodu natywnego jest realny, ale pomijalny (~1000 wywołań ≈ 0.16 ms) — to nie jest wąskie gardło. Prawdziwym kosztem w naiwnym kodzie jest układ pamięci AoS, a nie samo wywołanie zwrotne; UniText stosuje SoA tam, gdzie ma to znaczenie (atrybuty Unicode, metryki, bufory per piksel). (To także powód, dla którego ECS jest szybki — dzięki SoA, a nie „magii ECS”.) A UniText i tak jest scentralizowany — po prostu nie jako menedżer MonoBehaviour: samo Update() jest niemal puste, a ciężka praca jest zbierana w jeden wsadowy przebieg na wywołaniach zwrotnych renderowania Canvas (co daje też równoległość między komponentami).