簡介UnityNativeOSFont是一款面向Unity開發(fā)者的開源插件用于在運行時獲取操作系統(tǒng)本地字體并轉(zhuǎn)換為TextMeshPro可用的動態(tài)字體資源突破Unity默認(rèn)字體管理的局限特別適合電子書籍、教育軟件及多語言本地化等需要高度定制文本效果的項目。壓縮包內(nèi)共107個文件其中ShaderLab相關(guān)文件占比突出含13個Shader、4個cginc著色器庫和2個C#腳本以及23個Asset預(yù)設(shè)、示例場景、TMP Settings與PDF文檔整體體積僅1.33MB。已有1042人學(xué)習(xí)下載開發(fā)者可通過C#接口動態(tài)加載系統(tǒng)字體借助自定義Shader實現(xiàn)抗鋸齒、描邊、陰影等視覺效果也可構(gòu)建字體選擇下拉菜單供用戶切換免去預(yù)置字體的體積負(fù)擔(dān)。資源還提供了跨平臺兼容性處理與移動端性能優(yōu)化參考適合具備一定Unity基礎(chǔ)的中級開發(fā)者快速集成。 把一個中文包體壓到百兆以下時字體往往是最憋屈的一筆賬。動畫、貼圖、音頻都能靠壓縮和合批摳出空間但中文字體文件本身就擺在那里完整版的思源黑體一個字重接近10MB做三四個字重再加日韓泰文字包體直接多出幾十兆。今天想聊的方案是在運行時讀取操作系統(tǒng)字體通過 Unity 的原生字體接口加載再轉(zhuǎn)成一個動態(tài)的 TextMeshPro 字體資產(chǎn)。這套流程跑通之后內(nèi)置字體包可以從幾十兆降到接近零UI 的文字觀感也會和系統(tǒng)原生界面保持一致。這篇文章不是講在編輯器里靜態(tài)創(chuàng)建 TMP Font Asset 的常規(guī)流程而是圍繞“運行時動態(tài)獲取”這條主線把跨平臺字體命名差異、動態(tài)圖集內(nèi)存、布局刷新、缺字兜底這些坑一次說清楚。適合正在做包體優(yōu)化、多語言適配或者希望讓游戲 UI 更貼近系統(tǒng)原生的 Unity 開發(fā)者參考。1. 從包體負(fù)擔(dān)談起系統(tǒng)字體方案解決的是哪類問題1.1 字體的重量不是一張圖能打發(fā)的很多團隊初期不重視字體體積是因為在編輯器里看單個字體文件并沒有多扎眼。真正開始做多語言適配時問題才會暴露出來。中文簡體、中文繁體、日文、韓文、泰文、阿拉伯文每一種語言都需要一套字形而 TMP 的靜態(tài) FontAsset 在字符集選“全量”的時候中文就要生成多張圖集頁。每張 2048×2048 的 SDF 圖集顯存占用大約 16MB這還沒算字體文件本身在包體和內(nèi)存里的開銷。我見過一個做法很常見的項目簡體中文用思源黑體 Regular 和 Bold 兩個字重日文再用一套 Noto Sans JP還沒加入韓文就已經(jīng)多出 40 多兆包體。如果這時候甲方又提一句“泰文和阿拉伯文后面也要加”整個資源管線就得重新排。1.2 系統(tǒng)字體方案算的是另外三筆賬第一筆賬是包體。采用系統(tǒng)字體后項目基本不再需要內(nèi)置主流語言字體包那些 10 到 20MB 級別的文件都可以從資源管線里移除。第二筆賬是觀感。操作系統(tǒng)的原生界面字體通常由平臺設(shè)計師深度調(diào)校過比如 iOS 的蘋方、Android 的思源黑體變體游戲 UI 如果直接使用這些字體會天然帶有系統(tǒng)級的視覺協(xié)調(diào)感不會出現(xiàn)“第三方字體和系統(tǒng)控件放一起顯得突?！钡膯栴}。第三筆賬是覆蓋范圍。用戶設(shè)備上裝了什么語言庫系統(tǒng)字體方案就能覆蓋什么語言尤其是那些冷門小語種內(nèi)置字體包很難完整覆蓋但系統(tǒng)字庫的覆蓋率往往遠(yuǎn)超預(yù)期。這個方案當(dāng)然也有邊界。如果項目的核心 UI 強調(diào)品牌感比如標(biāo)題欄需要某個手寫字體或藝術(shù)字體那仍然需要內(nèi)置少量靜態(tài)字體資產(chǎn)用于品牌場景。系統(tǒng)字體方案是解決“通用文本”的大盤而不是取代所有字體設(shè)計。2. 獲取系統(tǒng)字體名稱跨平臺接口與命名差異2.1 Font.GetOSInstalledFontNames 拿到的到底是誰Unity 原生提供了一個很直接的接口Font.GetOSInstalledFontNames()它返回當(dāng)前操作系統(tǒng)可用的字體家族名稱數(shù)組。用下面的代碼就能把所有字體名打到控制臺string[] installedFontNames Font.GetOSInstalledFontNames(); Debug.Log($System font count: {installedFontNames.Length}); for (int i 0; i installedFontNames.Length; i) { Debug.Log($[{i}] {installedFontNames[i]}); }在 Windows 編輯器里你會看到 “Arial”“Microsoft YaHei”“SimHei” 這類名稱macOS 上會出現(xiàn) “PingFang SC”“Hiragino Sans GB”iOS 真機同樣能拿到蘋方相關(guān)的名字。Android 的情況稍微特別一點Unity 在 Android 上返回的更多是邏輯字體名比如 “sans-serif”“sans-serif-light”“monospace”部分廠商 ROM 也會返回類似 “Noto Sans CJK SC” 的具體家族名。這里有一個非常容易踩的坑這個 API 是同步的第一次調(diào)用時 Unity 需要枚舉系統(tǒng)字體庫低端 Android 機器上可能消耗幾十到幾百毫秒。所以不要把它放在 Update 或任何熱路徑里建議只在啟動初始化階段調(diào)用一次并把結(jié)果緩存下來。2.2 不同平臺命名不同匹配策略必須寫成數(shù)組既然每個平臺的字體名稱都不一樣代碼里就必須維護一份候選名列表按優(yōu)先級逐個匹配。不同語言的候選字體整理如下使用場景優(yōu)先候選字體名按順序簡體中文PingFang SC / Microsoft YaHei / Noto Sans CJK SC / sans-serif繁體中文PingFang TC / Microsoft JhengHei / Noto Sans CJK TC日文Hiragino Sans / Yu Gothic / Noto Sans CJK JP韓文Apple SD Gothic Neo / Malgun Gothic / Noto Sans CJK KR泰文Thonburi / Leelawadee UI阿拉伯文Geeza Pro / Segoe UI匹配的時候不要用嚴(yán)格相等判斷因為廠商 ROM 可能改名字比如 “Noto Sans CJK SC” 在部分設(shè)備上可能帶版本后綴或地區(qū)后綴。建議用大小寫不敏感的Contains判斷using System; public static string PickSystemFontName(string[] installedNames, string[] candidates) { for (int i 0; i candidates.Length; i) { for (int j 0; j installedNames.Length; j) { if (installedNames[j].IndexOf(candidates[i], StringComparison.OrdinalIgnoreCase) 0) { return installedNames[j]; } } } return sans-serif; }PickSystemFontName返回的是操作系統(tǒng)里實際存在的完整名稱不是候選數(shù)組里的簡寫。這樣能避免 “Microsoft YaHei” 在系統(tǒng)里實際叫 “微軟雅黑” 導(dǎo)致匹配失敗的問題。3. 把操作系統(tǒng) Font 轉(zhuǎn)成動態(tài) TMP_FontAsset 的完整流程3.1 創(chuàng)建字體資產(chǎn)的參數(shù)清單拿到字體名稱后先用Font.CreateDynamicFontFromOSFont創(chuàng)建 UnityEngine.Font 實例再傳給TMP_FontAsset.CreateFontAsset。這一步就是整個方案的核心代碼示例Font osFont Font.CreateDynamicFontFromOSFont(fontName, 32); if (osFont null) { osFont Font.CreateDynamicFontFromOSFont(sans-serif, 32); } TMP_FontAsset dynamicTmpFont TMP_FontAsset.CreateFontAsset( osFont, 32, // samplingPointSize 6, // atlasPadding GlyphRenderMode.SDFAA, // renderMode 2048, // atlasWidth 2048, // atlasHeight AtlasPopulationMode.Dynamic, // atlasPopulationMode true // enableMultiAtlasSupport );這里每個參數(shù)都對應(yīng)著不同的坑逐個說。samplingPointSize建議用 32 到 36。采樣點太小SDF 的精度不夠文字放大后邊緣容易發(fā)虛采樣點太大圖集里單個字形占用的區(qū)域變大同樣的圖集頁能塞下的字?jǐn)?shù)就變少。atlasPadding一般給 4 到 8。SDF 需要足夠的內(nèi)邊距來記錄字形邊緣的遠(yuǎn)近場信息給 0 的話會出現(xiàn)相鄰字形邊緣互相污染的問題表現(xiàn)就是文字周圍有奇怪的暗邊。GlyphRenderMode.SDFAA是移動端的常用選擇它得到的 SDF 帶抗鋸齒效果渲染效果比純 SDF 更干凈。注意這里選的是圖集生成的渲染模式不是最終屏幕上的抗鋸齒SDF 字體無論怎么縮放都不會像位圖字體那樣明顯發(fā)糊。enableMultiAtlasSupport建議打開。動態(tài)字體在運行時會不斷遇到新字形打開多圖集支持后當(dāng)前圖集頁寫滿會自動新增一頁避免因為圖集滿了導(dǎo)致字形無法寫入。3.2 材質(zhì)與文本組件的綁定細(xì)節(jié)創(chuàng)建完 TMP_FontAsset 后直接在文本組件上賦值即可TMP_Text text GetComponentTextMeshProUGUI(); text.font dynamicTmpFont; text.fontSharedMaterial dynamicTmpFont.material; text.text 你好Unity;如果發(fā)現(xiàn)文字變成粉紫色說明材質(zhì)的 Shader 沒有正確綁定。較新的 TMP 版本在CreateFontAsset時會自動創(chuàng)建帶正確 Shader 的材質(zhì)但如果你對這個 FontAsset 做了復(fù)制或者是在某些資源重建流程中重新賦值了材質(zhì)就需要手動矯正dynamicTmpFont.material.shader Shader.Find(TextMeshPro/Distance Field);另一個細(xì)節(jié)是不要把這些代碼放在Awake里直接運行尤其是當(dāng)場景里多個 TMP 文本組件同時被激活時。把字體創(chuàng)建和賦值拆到Start或者放到場景加載后的初始化協(xié)程里能避免渲染線程與主線程搶資源導(dǎo)致的卡頓。3.3 兩個“動態(tài)”不是一回事很多人搞混一個概念Font.CreateDynamicFontFromOSFont創(chuàng)建的是系統(tǒng)字體對象的動態(tài)字體它解決的是“字形數(shù)據(jù)從哪里來”的問題而 TMP 的AtlasPopulationMode.Dynamic解決的是“字形什么時候烘進圖集”的問題。兩者配合才真正做到按需加載字形。具體表現(xiàn)是當(dāng) TMP 文本遇到一個當(dāng)前圖集里沒有的字符時它會先從系統(tǒng)字體對象中獲取字形輪廓然后實時烘到圖集上再重建網(wǎng)格。這個流程在第一次顯示某個冷門字時會有一次小卡頓但正常的聊天內(nèi)容、界面文本都集中在常用字符上所以整體體驗可以接受。4. 動態(tài)圖集不是免費的內(nèi)存、布局刷新與缺字兜底4.1 圖集頁無限膨脹切換語言后要主動清理動態(tài)圖集的便利背后有一個實打?qū)嵉某杀緢D集只增不減。一個長期運行的項目如果不斷出現(xiàn)新的生僻字或者用戶手動輸入的文本包含大量冷門字符圖集頁會慢慢膨脹。每張 2048×2048 的動態(tài)圖集頁在顯存里大約占 16MB一旦漲到四五頁這個方案的優(yōu)勢就被內(nèi)存消耗抵消了。TMP 3.x 提供了清理方法ClearFontAssetData()可以在切換語言場景時調(diào)用dynamicTmpFont.ClearFontAssetData();這個調(diào)用會清掉動態(tài)烘進去的字形和圖集數(shù)據(jù)下次再設(shè)置文本時會重新按需生成。這里建議加一個開關(guān)控制只在確認(rèn)當(dāng)前界面已經(jīng)進入“不會立即顯示大量歷史文本”的狀態(tài)時才清理避免剛清完又被同一批文本重新烘一遍白忙一場。4.2 第一幀不刷新 LayoutGroup 的經(jīng)典故障系統(tǒng)字體的度量數(shù)據(jù)和每個平臺、每個字體族相關(guān)。當(dāng)運行時把某個 TextMeshProUGUI 的字體替換成系統(tǒng)字體后同一幀內(nèi)VerticalLayoutGroup或ContentSizeFitter拿到的往往是舊字體的布局結(jié)果表現(xiàn)就是文字重疊、不換行、間距錯亂但拖動一下窗口或者切一下分辨率布局又自己恢復(fù)了。這不是 Unity UI 的隨機 bug而是布局系統(tǒng)在字體還沒完成字形烘培時就計算了一遍等字形數(shù)據(jù)更新后布局沒有收到重新計算的信號。解決辦法是強制重建一次布局LayoutRebuilder.ForceRebuildLayoutImmediate(transform as RectTransform);更多時候問題出在時序上。如果字體是異步初始化的最簡單的方式是等待一幀再重建布局yield return null; LayoutRebuilder.ForceRebuildLayoutImmediate(rectTransform);我在動態(tài)更換聊天字體、動態(tài)生成列表項標(biāo)題時都會在首次設(shè)置文本后至少做一次延遲重建這樣能避免大量由字體替換引發(fā)的布局抖動。4.3 缺字時用 fallback 棧兜底系統(tǒng)字體并不是萬能的。某個設(shè)備如果缺少指定語言的字體或者用戶輸入的某個字符在當(dāng)前系統(tǒng)字體里根本沒有對應(yīng)字形TMP 會直接在 UI 上顯示一個方塊。為了讓這種情況不至于失控需要配置 fallback 字體棧。TMP 的 fallback 機制在TMP_Settings里維護了一個字體資源列表。當(dāng)主字體的圖集里找不到某個字形時TMP 會依次去 fallback 列表里的字體資源中查找TMP_Settings.fallbackFontAssets.Add(fallbackFontAsset);這里有一個工程經(jīng)驗不要在 fallback 列表里放一個巨大的全量中文字體。正確做法是放一個覆蓋基礎(chǔ)拉丁字符和常用符號的輕量字體用來兜住主字體缺失的零星字符。如果 fallback 字體本身也很重那系統(tǒng)字體方案省下來的包體又會被 fallback 吃回去。4.4 不要拿動態(tài)字體渲染所有 UI動態(tài)字體最大的價值在動態(tài)內(nèi)容上也就是用戶昵稱、聊天消息、后臺返回的富文本、多語言配置項這一類“運行時才確定”的文本。固定不變的主菜單標(biāo)題、Logo 文字、帶特殊樣式的系統(tǒng)標(biāo)題仍然建議用美術(shù)定制字體或者至少用靜態(tài) TMP 字體資產(chǎn)。原因很簡單靜態(tài)字體可以預(yù)先分配圖集字體風(fēng)格可控還能避免動態(tài)烘培對啟動和首幀造成的壓力。合理的設(shè)計是靜態(tài)品牌字負(fù)責(zé)視覺門面動態(tài)系統(tǒng)字負(fù)責(zé)信息文本。兩者共存而不是互相替代。5. 落到工程里實例緩存、降級路徑和多語言切換5.1 字體資產(chǎn)全局只保留一份動態(tài) TMP 字體資產(chǎn)一旦創(chuàng)建會持有系統(tǒng)字體對象和圖集材質(zhì)。如果每個場景都重新創(chuàng)建一次舊資產(chǎn)又沒有被及時卸載內(nèi)存就會不斷累積。工程上的做法是設(shè)計一個FontService單例由它持有全局唯一的動態(tài)字體資產(chǎn)場景切換時不讓它被銷毀public sealed class FontService { public static readonly FontService Instance new FontService(); private TMP_FontAsset _dynamicFontAsset; public TMP_FontAsset GetDynamicFontAsset() { return _dynamicFontAsset; } }字體資產(chǎn)本身是 UnityEngine.Object可以在啟動階段創(chuàng)建后掛到 DontDestroyOnLoad 的 GameObject 上由場景管理器統(tǒng)一管理生命周期。這樣既避免了重復(fù)創(chuàng)建也讓全局字體替換成為可能。啟動階段不要一進主場景就立刻執(zhí)行字體枚舉和 TMP 字體創(chuàng)建這會和加載邏輯搶時間片。建議放在 Loading 界面之后、主界面出現(xiàn)之前用一個協(xié)程分步執(zhí)行每步之間yield return null讓 UI 先渲染一幀避免卡在白屏或 Logo 畫面。5.2 真機返回 null 或者字體名稱對不上的降級方案就算代碼里寫好了候選表真機仍可能出現(xiàn)CreateDynamicFontFromOSFont返回 null 的情況尤其是一些定制 ROM 會裁剪字體列表。這時不能直接崩潰要準(zhǔn)備一條降級鏈private static Font CreateOSFontWithFallback(string fontName, int size) { Font font Font.CreateDynamicFontFromOSFont(fontName, size); if (font null) { font Font.CreateDynamicFontFromOSFont(sans-serif, size); } if (font null) { font Resources.GetBuiltinResourceFont(LegacyRuntime.ttf); } return font; }Resources.GetBuiltinResourceFont(LegacyRuntime.ttf)是 Unity 內(nèi)置的兜底字體雖然不算美觀但至少保證文本可見。生產(chǎn)環(huán)境還要把這些失敗信息記到日志或上報系統(tǒng)里后續(xù)通過統(tǒng)計修正候選字體表。5.3 多語言切換的完整替換順序多語言項目在運行時切換語言時不能只是把文本翻譯換掉還得把字體一起換掉。我建議的順序是根據(jù)目標(biāo)語言重新調(diào)用PickSystemFontName獲取新字體名稱。創(chuàng)建新的Font和新的TMP_FontAsset。遍歷當(dāng)前活動 UI 上的全部 TMP 文本組件把font屬性切換到新資產(chǎn)。等待一幀執(zhí)行LayoutRebuilder.ForceRebuildLayoutImmediate。確認(rèn)新字體渲染正常后再釋放舊字體資產(chǎn)調(diào)用Resources.UnloadUnusedAssets。這一步一定要先建新的再釋放舊的。如果先釋放舊字體而當(dāng)前場景還在顯示舊文本屏幕上會出現(xiàn)一整片無法解析字形的方塊直到新字體完全接管。5.4 這套方案的建議使用邊界如果你的項目是以界面展示為主、強調(diào)版權(quán)字體品牌的單機游戲或者有非常強烈的美術(shù)字體風(fēng)格我不建議全面采用系統(tǒng)字體方案。用字體本身做設(shè)計語言的項目品牌字才是核心資產(chǎn)系統(tǒng)字體再輕也沒有意義。反過來如果你在做的是一款工具類應(yīng)用、海外多語言小程序、輕量級社交產(chǎn)品或者因為包體限制想做極致壓縮那這套“系統(tǒng)字體 動態(tài) TMP fallback 兜底”的架構(gòu)幾乎就是成本最低的字庫解決方案。我自己實踐后的最后一條原則是把字體當(dāng)成一個可熱更的運行時配置來管理而不是寫成死代碼。系統(tǒng)字體名稱、fallback 列表、采樣點大小都放到配置表里線上發(fā)現(xiàn)某個機型字體重影或者缺字時不用發(fā)版改一行配置就能把問題修掉。這個思路比任何一步具體實現(xiàn)都更能幫項目省時間。本文還有配套的精品資源點擊獲取