Ні. UniText не запікає окремі текстурні атласи на кожен шрифт у Ваш білд. Гліфи растеризуються в рантаймі у спільний атлас (на основі Texture2DArray) із підрахунком посилань на кожен гліф і витісненням за LRU. У Ваш білд потрапляють лише дані шрифту — ніколи атласи. До того ж вбудоване стиснення шрифтів (Zstd, рівень 22) зменшує дані шрифту до ~2.7× для латиниці/арабської (для CJK скромніше, ~1.3×).

Ні. Ассет UniTextFont вбудовує байти шрифту всередину себе. Посилання на вихідний шрифт існує лише в редакторі (загорнуте в #if UNITY_EDITOR) — у білді гравця його просто немає, тож це не рантайм-залежність і воно не потрапить в AssetBundle через пошук залежностей. Ви можете видалити .ttf після створення ассета.

Ні. Ви можете створити UniTextFont із .ttf, розташованого будь-де на Вашому диску, через вікно інструмента UniText (діалог вибору файлу читає байти напряму). Імпортувати шрифт у проєкт необов'язково.

• WebGL: порожній білд ≈ 6–10 MB (залежить від версії Unity та встановлених пакетів); UniText додає свої нативні бібліотеки (HarfBuzz, FreeType). Це ті самі індустріально-стандартні бібліотеки, які постачає власний Advanced Text Generator в UI Toolkit від Unity — нічого екзотичного (UniText просто несе власні копії). • Android: APK із двома архітектурами несе обидві — приблизно +4 MB на архітектуру. Але коли Ви публікуєте AAB, Google Play доставляє бандл під конкретний пристрій, тож користувач завантажує лише свою архітектуру (~4 MB), а не обидві.

З TMP у режимі Static-заповнення атласу запікання повного набору гліфів типового CJK-шрифту роздуває білд на десятки-сотні MB (кілька атласів 4096²/8192²; очікуйте ~80–250 MB залежно від кількості гліфів і роздільної здатності). Ключовий момент: накладні витрати UniText не зростають із кількістю гліфів — це ті самі кілька MB, чи постачаєте Ви латиницю, чи повний CJK.

Так — це на боці розробника, і UniText не заважає. Завантажте байти шрифту власним кодом (UnityWebRequest) і створіть із них UniTextFont у рантаймі через CreateFontAsset(byte[]). Щоб урізати шрифт лише до потрібних Вам символів (субсетинг), скористайтеся інструментом UniText часу збірки. У пакеті немає вбудованого авто-завантажувача з CDN — це навмисно відповідальність проєкту, а не рушія.

Так — SystemFont читає файл шрифту прямо з ОС у рантаймі, тож він ніяк не впливає на розмір білду (нічого не запікається). Розв'язання відбувається ліниво (при першому використанні), тож це не сповільнює запуск застосунку.

Ні — і це обмеження браузера, а не UniText. Пісочниця браузера не надає доступ до шрифтів ОС. Для WebGL вбудуйте шрифт в ассет UniTextFont (або завантажте байти самостійно — див. запитання про CDN вище).

Гліфи живуть у тайлах трьох розмірів — 64, 128, 256 — і розмір обирається за складністю контуру (багато сегментів → 128/256, простий контур → 64). • SDF Detail — це множник для оцінки складності. Підніміть його — і вже нетривіальний гліф з більшою ймовірністю перейде до більшого тайла. (Справді простий контур залишається на 64 — множник впливає лише на гліфи вище порогу.) • Tile Size Offset — це жорсткий крок по драбині розмірів (обрано 64 + зсув 1 → 128; діапазон −2..+2).

Ні на чому окремо — обидва лише визначають підсумковий розмір тайла, а вартість задається саме цим розміром. Дві комбінації, що дають однаковий розмір тайла, коштують рівно однаково. Прагніть найменшого розміру тайла, який усе ще дає прийнятну якість.

Лише коли гліфа ще немає в атласі — ніколи щокадру. Для «Hello world» він растеризує унікальні гліфи H e l o w r d. Друга H не робить нічого; a растеризує лише a.

Вартість пропорційна кількості унікальних, уперше побачених гліфів, растеризованих у цьому кадрі — а не довжині тексту. У нашому бенчмарку ~2000 унікальних гліфів на першому кадрі — це ≈ 1 секунда на типовому Android-пристрої; TMP і UI Toolkit у тому ж сценарії потребують 10+ секунд. Повторне використання кешованих гліфів безкоштовне.

UniText майже не покладається на Unity Job System на гарячому шляху — і це задумано. Растеризація гліфів (наш власний lpSDF / lpMSDF) за замовчуванням виконується на GPU через compute-шейдер; Burst-задачі — лише запасний варіант на CPU, коли compute недоступний. Основна багатопотоковість — шейпінг, компонування, генерація меша — виконується у власному пулі OS-потоків UniText (а не Unity Jobs, тому вони й не з'являються у профайлері Jobs). Тож «немає задачі UniText» не означає «потоки вимкнено»: або робота пішла на GPU, або атлас уже прогрітий, або текст нижчий за поріг паралелізму (короткі чи поодинокі підписи обробляються послідовно — так дешевше).

«Update() повільний» — це міф для release-білдів. Накладні витрати виклику магічного методу з нативного коду реальні, але мізерні (~1000 викликів ≈ 0.16 ms) — це не вузьке місце. Справжня вартість у наївному коді — це розкладка пам'яті AoS, а не сам колбек; UniText застосовує SoA там, де це має значення (атрибути Unicode, метрики, буфери на кожен піксель). (Саме тому й ECS швидкий — завдяки SoA, а не «магії ECS».) І UniText усе одно централізований — просто не як MonoBehaviour-менеджер: сам Update() майже порожній, а важка робота збирається в єдиний пакетний прохід на колбеках рендерингу Canvas (що також дає паралелізм між компонентами).