いいえ。UniText はフォントごとのテクスチャアトラスをビルドに焼き込むことはありません。グリフはランタイムに共有アトラス(Texture2DArray ベース)へラスタライズされ、グリフごとの参照カウントと LRU による退避で管理されます。ビルドに含まれるのはフォントデータのみで — アトラスが含まれることはありません。さらに、組み込みのフォント圧縮(Zstd、レベル22)により、ラテン文字/アラビア語ではフォントデータを最大 ~2.7× まで縮小できます(CJK はより控えめで ~1.3×)。

いいえ。UniTextFont アセットはフォントのバイトデータを自身の内部に埋め込みます。ソースフォントへの参照は Editor 専用(#if UNITY_EDITOR で囲まれています) — プレイヤービルドにはそもそも存在しないため、ランタイムの依存関係にはならず、依存関係の解決によって AssetBundle に取り込まれることもありません。アセットを作成した後は .ttf を削除できます。

いいえ。UniText のツールウィンドウから、ディスク上のどこにある .ttf でも UniTextFont を作成できます(ファイルダイアログがバイトデータを直接読み取ります)。フォントをプロジェクトにインポートするかどうかは任意です。

• WebGL: 空のビルドは ≈ 6–10 MB です(Unity のバージョンやインストール済みパッケージによって変動します)。UniText はネイティブライブラリ(HarfBuzz、FreeType)を追加します。これらは Unity 自身の UI Toolkit Advanced Text Generator が同梱しているのと同じ業界標準のライブラリで、特別なものではありません(UniText は自前のコピーを持っているだけです)。 • Android: 2つのアーキテクチャを含む APK は両方を抱えます — アーキテクチャあたり約 +4 MB です。しかし AAB で公開すれば、Google Play がデバイス固有のバンドルを配信するため、ユーザーは両方ではなく自分のアーキテクチャ(~4 MB)だけをダウンロードします。

TMP を Static のアトラス生成モードで使うと、一般的な CJK フォントのグリフセット全体を焼き込むだけで、ビルドが数十〜数百 MB 肥大化します(複数の 4096²/8192² アトラス。グリフ数と解像度に応じて ~80–250 MB を見込んでください)。重要なのは、UniText のオーバーヘッドはグリフ数に比例して増えないという点です — ラテン文字を出荷しようと、CJK 全体を出荷しようと、同じ数 MB です。

はい — それは開発者側の領分であり、UniText が邪魔をすることはありません。独自のコード(UnityWebRequest)でフォントのバイトデータをダウンロードし、ランタイムに CreateFontAsset(byte[]) で UniTextFont を作成してください。フォントを必要な文字だけに削減する(サブセット化)には、UniText のビルド時ツールを使います。パッケージには組み込みの CDN 自動ローダーはありません — これは意図的に、エンジンではなくプロジェクトの責務としているためです。

はい — SystemFont はランタイムに OS からフォントファイルを直接読み取るため、ビルドサイズには影響しません(何も焼き込まれません)。解決は遅延で行われる(初回使用時)ため、アプリの起動を遅くすることもありません。

いいえ — そしてこれは UniText ではなくブラウザの制約です。ブラウザのサンドボックスは OS のフォントを公開しません。WebGL では、フォントを UniTextFont アセットに埋め込んでください(あるいは自分でバイトデータを読み込みます — 上記の CDN の質問を参照)。

グリフは3つのサイズ — 64、128、256 — のタイルに収められ、サイズは輪郭の複雑さから選ばれます(セグメントが多い → 128/256、単純な輪郭 → 64)。 • SDF Detail は複雑さの推定値に対する乗数です。値を上げると、すでに単純ではないグリフがより大きなタイルへ移動しやすくなります。(本当に単純な形状は 64 のままです — 乗数はしきい値を超えるグリフにのみ影響します。) • Tile Size Offset はサイズの段階に沿った強制的なステップです(選ばれた 64 + オフセット 1 → 128、範囲は −2..+2)。

どちらも単独では優先すべきではありません — どちらも最終的なタイルサイズを決めるだけで、コストはそのサイズだけで決まります。同じタイルサイズに帰着する2つの組み合わせのコストは、まったく同じです。許容できる品質が得られる範囲で、できるだけ小さいタイルサイズを目指してください。

グリフがまだアトラスにない場合のみで — 毎フレームということは決してありません。「Hello world」であれば、ユニークなグリフ H e l o w r d をラスタライズします。2つ目の H は何もせず、a は a だけをラスタライズします。

コストは、そのフレームでラスタライズされる、初めて登場するユニークなグリフの数に比例します — テキストの長さにではありません。当社のベンチマークでは、最初のフレームで ~2000 個のユニークなグリフは、一般的な Android デバイスで ≈ 1 秒です。TMP と UI Toolkit は同じシナリオで 10+ 秒かかります。キャッシュ済みのグリフの再利用は無料です。

UniText はホットパスで Unity の Job System にほとんど依存していません — これは設計上の意図です。グリフのラスタライズ(独自の lpSDF / lpMSDF)は、デフォルトでコンピュートシェーダーを介して GPU 上で実行されます。Burst ジョブは、コンピュートが利用できない場合の CPU フォールバックにすぎません。主要なマルチスレッド処理 — シェーピング、レイアウト、メッシュ生成 — は、UniText 独自の OS スレッドプール上で実行されます(Unity Jobs ではないため、Jobs プロファイラーには表示されません)。つまり「UniText のジョブがない」ことは「スレッドがオフ」であることを意味しません。処理が GPU に回されたか、アトラスがすでにウォームであるか、あるいはテキストが並列化のしきい値を下回っているか(短いラベルや単一のラベルは順次処理されます — その方が安価だからです)のいずれかです。

「Update() は遅い」というのは、リリースビルドにおいては俗説です。ネイティブコードからのマジックメソッド呼び出しのオーバーヘッドは実在しますが、無視できるほど小さく(~1000 回の呼び出しで ≈ 0.16 ms) — ボトルネックではありません。素朴なコードにおける本当のコストは、コールバック自体ではなく AoS のメモリレイアウトです。UniText は重要な箇所で SoA を適用します(Unicode 属性、メトリクス、ピクセルごとのバッファ)。(ECS が高速なのもこれと同じ理由です — 「ECS の魔法」ではなく SoA のおかげです。)そして UniText はいずれにせよ集中管理されています — ただし MonoBehaviour のマネージャーとしてではありません。Update() 自体はほぼ空で、重い処理は Canvas のレンダーコールバックで単一のバッチ処理にまとめられます(これがコンポーネント間の並列化をもたらすものでもあります)。