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