简介UnityNativeOSFont 是一套面向 Unity 开发者的开源工具用于在运行时获取操作系统本地字体并接入 TextMeshPro 动态字体渲染解决 TMP 默认字体库无法覆盖各平台系统字体、需手动导入字体文件的问题。它通过 C# 脚本读取系统字体列表并转换为 Unity 可识别格式配合 ShaderLab 自定义着色器优化抗锯齿、描边等渲染效果适用于电子书、教育软件及需要本地化字体支持的项目。资源包共 107 个文件约 1.33MB包含 13 个 shader、4 个 cginc 等着色器资源23 个 asset 与 2 个 mat 等配置素材以及 2 个 cs 脚本、示例场景和说明文档结构完整便于直接导入使用。目前已有 1045 人学习下载。读者可借此掌握系统字体枚举、TMP 动态字体应用与跨平台兼容处理思路并参考着色器实现优化文本显示质量。1. UnityNativeOSFont把系统字体变成 TMP 动态字体的那条路做 Unity 项目时UI 里出现生僻字、少数民族文字、日韩越混排甚至用户自定义昵称里带 emoji 组合TextMeshPro 的静态字体图集就开始翻车——方块、豆腐块、缺字警告刷满 Console。常规解法是往 Font Asset 里塞几千个字符重新烘焙包体直接膨胀几十兆而且用户输入什么你根本预判不了。UnityNativeOSFont 这个方向要解决的就是这件事不再预烘焙而是在运行时直接向操作系统要字体文件把它喂给 TMP 的动态字体系统按需生成字形。它适合做工具类 App、社交聊天、输入框、多语言阅读器这类「字符集不可穷举」的项目也适合被包体优化逼到墙角的团队。核心链路只有三步拿到系统字体路径、读成字节流、交给 TMP_FontAsset 动态渲染。听起来简单坑全在平台差异和 TMP 的内部机制上。2. 系统字体从哪来三平台的取字路径与选型理由2.1 为什么不用打包内置字体先说选型。很多人第一反应是把一个覆盖全 Unicode 的字体比如思源黑体全量版打进 StreamingAssets省事。但全量 CJK 字体动辄 1520MB加上 TMP 图集包体压力很大更麻烦的是系统级 emoji、部分小语种字形内置字体未必覆盖用户一输入还是缺字。动态从系统取字体的价值在于字形覆盖跟着操作系统走用户系统里能显示的字你的 App 基本也能显示包体只增加读取逻辑那点代码。代价也要讲清楚系统字体路径因平台、系统版本、厂商定制而不同读取可能失败字体授权也因系统而异自用渲染通常没问题但别把系统字体文件再分发出去。所以工程上一般做成「系统字体优先失败回退内置字体」的双保险。2.2 三个平台的字体目录不同平台拿字体的方式差别很大先建立一张对照表后面代码都围绕它展开。平台典型字体目录常见字体文件读取方式WindowsC:/Windows/Fontsmsyh.ttc、simhei.ttf、arial.ttfFile.ReadAllBytesmacOS/System/Library/Fonts、/Library/FontsPingFang.ttc、Helvetica.ttcFile.ReadAllBytesAndroid/system/fontsNotoSansCJK-Regular.ttc、DroidSansFallback.ttfFile.ReadAllBytes需权限范围内iOS/System/Library/Fonts、/System/Library/Fonts/CorePingFang.ttc、Helvetica.ttc部分路径受沙盒限制优先用系统 API注意.ttc是字体集合TrueType Collection一个文件里打包了多个字重或字形集。TMP 的Font.CreateFontAsset对 ttc 的支持要看 Unity 版本和 FreeType 版本很多情况下直接读 ttc 会失败或只取到第一个 face。稳妥做法是优先找.ttf/.otf找不到再尝试 ttc 并做好异常兜底。2.3 用代码枚举并挑选字体下面这段是跨平台枚举候选字体的最小实现思路是「按优先级列表逐个探测命中即返回」。using System.IO; using UnityEngine; public static class OSFontLocator { // 按优先级排列的候选路径前面的命中就不再看后面 static readonly string[] WinCandidates { C:/Windows/Fonts/msyh.ttc, // 微软雅黑中文覆盖好 C:/Windows/Fonts/simhei.ttf, // 黑体ttf 更稳 C:/Windows/Fonts/arial.ttf // 兜底拉丁 }; static readonly string[] MacCandidates { /System/Library/Fonts/PingFang.ttc, /System/Library/Fonts/Helvetica.ttc }; static readonly string[] AndroidCandidates { /system/fonts/NotoSansCJK-Regular.ttc, /system/fonts/DroidSansFallback.ttf }; public static string Find() { string[] list; #if UNITY_STANDALONE_WIN || UNITY_EDITOR_WIN list WinCandidates; #elif UNITY_STANDALONE_OSX || UNITY_EDITOR_OSX list MacCandidates; #elif UNITY_ANDROID list AndroidCandidates; #else list new string[0]; #endif foreach (var p in list) { if (File.Exists(p)) return p; // 命中即返回 } return null; // 全部失败交给上层回退内置字体 } }逻辑说明Find()只负责「找到第一个存在的字体文件路径」不做加载职责单一方便单测。参数上候选数组的顺序就是优先级中文项目把雅黑/Noto 放前面纯英文项目可以把 Arial/Helvetica 提前。返回null是明确信号调用方必须处理不能假设一定有系统字体。提示Android 上/system/fonts一般可读但个别定制 ROM 会收紧权限File.Exists返回 false 时不要慌走回退逻辑即可。iOS 沙盒对/System的访问限制更严真机上更推荐用Font.CreateDynamicFontFromOSFont拿到系统字体名再配合 TMP 的 fallback 机制而不是硬读文件路径。3. 把字体字节流喂给 TMP动态 FontAsset 的创建与参数3.1 TMP 动态字体的工作方式TMP 的TMP_FontAsset有两种模式静态图集预烘焙字符固定和动态运行时按需把字形渲染进图集。动态模式的关键是atlasPopulationMode设为Dynamic并保证TMP_Settings里开启了动态字体支持。动态图集有容量上限默认 1024x1024字符一多会触发图集扩容或重建这就是为什么「字符集不可穷举」场景必须用动态——你不可能预知用户输入什么。从系统字体字节流创建 FontAsset走的是TMP_FontAsset.CreateFontAsset的重载它内部用 FreeType 解析字体数据。这里有个容易忽略的点创建出来的 FontAsset 是运行时对象不落盘切场景时如果不DontDestroyOnLoad或放进常驻管理器会被 GC 回收导致后续文本变方块。3.2 从字节流创建动态 FontAssetusing System.IO; using TMPro; using UnityEngine; public static class OSFontAssetBuilder { public static TMP_FontAsset Build(string path) { if (string.IsNullOrEmpty(path) || !File.Exists(path)) return null; byte[] data File.ReadAllBytes(path); // 一次性读入内存 if (data null || data.Length 0) return null; // 关键参数采样点大小、图集尺寸、模式 var font TMP_FontAsset.CreateFontAsset( data, // 字体字节流 90, // samplingPointSize采样点影响清晰度 9, // atlasPadding字形间距防粘连 UnityEngine.TextCore.LowLevel.GlyphRenderMode.SDFAA, 1024, // atlasWidth 1024, // atlasHeight AtlasPopulationMode.Dynamic, // 动态模式 true // enableMultiAtlasSupport允许扩容多图集 ); if (font ! null) { font.name OSFont_ Path.GetFileName(path); Object.DontDestroyOnLoad(font); // 防止被回收 } return font; } }逻辑说明CreateFontAsset的第一个参数接受byte[]这是从系统字体文件读出来的原始数据。samplingPointSize决定 SDF 采样的精细度90 是常用值太小会糊太大图集消耗快。atlasPadding给字形留边防止相邻字形 SDF 溢出粘连9 是经验值。GlyphRenderMode.SDFAA是带抗锯齿的 SDFUI 场景通用。enableMultiAtlasSupport设为 true 后单张图集满了会自动开新图集这是动态字体不爆的关键开关。参数怎么调给一张对照参数常用值调大后果调小后果samplingPointSize6090更清晰图集消耗快发虚小字号糊atlasPadding59更安全浪费空间字形边缘可能粘连atlasWidth/Height1024单图集容量大内存高频繁扩容性能抖动enableMultiAtlasSupporttrue不爆图集内存上限高超限后新字渲染失败3.3 挂到 TMP 组件并处理回退创建好 FontAsset 后要把它赋给TMP_Text.font同时把它加进fallbackFontAssetTable这样主字体缺字时能自动切到系统字体。using TMPro; using UnityEngine; public class OSFontApplier : MonoBehaviour { public TMP_Text target; // 要应用的目标文本 public TMP_FontAsset builtin; // 内置兜底字体 void Start() { string path OSFontLocator.Find(); var osFont OSFontAssetBuilder.Build(path); if (osFont ! null) { target.font osFont; // 把内置字体作为回退系统字体缺字时兜底 osFont.fallbackFontAssetTable.Add(builtin); } else { target.font builtin; // 系统字体失败直接用内置 } } }逻辑说明fallbackFontAssetTable是 TMP 的缺字回退链主字体找不到字形时会依次查回退表。把内置字体挂上去等于给系统字体上了保险。注意回退表是单向的别写成循环引用A 回退 BB 又回退 A否则 TMP 查字会死循环。注意动态 FontAsset 在运行时创建后如果多个 TMP_Text 共用同一个实例图集是共享的这通常是好事省内存。但如果你给每个文本都CreateFontAsset一次就会创建多份图集内存直接翻倍。正确做法是全局只建一份缓存起来复用。4. 避坑与排查系统字体动态化的 5 个血泪现场4.1 现象真机上文字全变方块编辑器正常原因编辑器在 Windows/macOS 上能读到系统字体真机尤其 Android 定制 ROM、iOS 沙盒路径不存在或权限不足Find()返回 null代码没走回退target.font被赋成 null。解决Build()返回 null 时必须显式回退到内置字体别让font保持 null。加一行日志把实际路径打出来真机连 Logcat/Xcode 看比猜快得多。4.2 现象切场景后原本正常的文本变方块原因运行时创建的 FontAsset 没有DontDestroyOnLoad切场景时被卸载TMP_Text 引用的对象失效。解决创建后立刻DontDestroyOnLoad(font)或者放进一个常驻的字体管理器单例里持有引用。别指望 TMP 帮你保命。4.3 现象输入大量不同字符后新字渲染不出来Console 报图集满原因动态图集容量到顶enableMultiAtlasSupport没开或者开了但atlasWidth/Height太小扩容次数过多触发限制。解决创建时把enableMultiAtlasSupport设为 true图集起步 1024。如果项目字符量极大比如聊天记录滚动考虑定期清理不用的字形或对历史文本用静态快照。4.4 现象读.ttc文件抛异常或只显示部分字重原因TMP/FreeType 对 TrueType Collection 的支持不完整一个 ttc 里多个 face默认可能只解析第一个或者直接解析失败。解决优先选.ttf/.otf候选路径。只有 ttc 可用时用 try-catch 包住CreateFontAsset失败就走回退。别在 ttc 上死磕。4.5 现象字体加载瞬间卡顿低端机掉帧明显原因File.ReadAllBytes同步读大字体文件十几 MB加上 FreeType 首次解析全在主线程。解决把读取和创建放到异步线程或协程分帧创建完成后回主线程赋值。字体文件读取本身可以用Task.Run但CreateFontAsset涉及 Unity 对象必须在主线程调用所以拆成「异步读字节 → 主线程建 FontAsset」两段。5. 进阶缓存策略、字形预热与一套可复用的字体管理器走到这里基本链路已经通了。但要在真实项目里稳住还得解决两件事字体只建一次、常用字形提前预热。先说缓存。全局维护一个Dictionarystring, TMP_FontAssetkey 用字体路径命中直接返回。这样无论多少个 UI 面板请求系统字体底层只有一份 FontAsset 和图集。管理器大致长这样using System.Collections.Generic; using TMPro; using UnityEngine; public class FontManager : MonoBehaviour { static FontManager _inst; readonly Dictionarystring, TMP_FontAsset _cache new(); public static FontManager Instance { get { if (_inst null) { var go new GameObject(FontManager); _inst go.AddComponentFontManager(); DontDestroyOnLoad(go); // 常驻跨场景不销毁 } return _inst; } } public TMP_FontAsset GetOSFont() { string path OSFontLocator.Find(); if (string.IsNullOrEmpty(path)) return null; if (_cache.TryGetValue(path, out var cached)) return cached; // 命中缓存 var font OSFontAssetBuilder.Build(path); if (font ! null) _cache[path] font; return font; } }逻辑说明单例 字典缓存保证同一路径只创建一次。DontDestroyOnLoad挂在管理器 GameObject 上字体对象本身也随管理器常驻。参数上没什么可调的重点是别在GetOSFont里做重复创建。再说预热。动态字体第一次渲染某个字时才生成字形会有一次小的卡顿。对已知的高频字符比如数字、常用汉字前 500 个、项目固定文案可以在加载时主动调用font.TryAddCharacters把它们提前烘进图集// 预热把常用字符提前加入图集避免首次渲染卡顿 string warmup 0123456789abcdefghijklmnopqrstuvwxyz; font.TryAddCharacters(warmup, out string missing); if (!string.IsNullOrEmpty(missing)) Debug.LogWarning($预热缺失字符: {missing});TryAddCharacters返回是否全部成功missing输出没加进去的字符。预热字符集别贪多几百个足够加太多等于把静态烘焙的包体问题又搬回运行时内存。最后给一个验证方法在真机上跑一个「随机字符压力测试」每秒往 TMP_Text 里塞一批随机 Unicode 字符观察图集数量和帧率。图集数量稳定、帧率无尖刺说明缓存和扩容策略都对了。我自己的习惯是任何动态字体方案上线前必在最低端的目标机型上跑这个压力测试跑不过就不发。系统字体这条路能省包体、能覆盖生僻字但它把不确定性从打包期挪到了运行期测试必须补上。希望帮到你。本文还有配套的精品资源点击获取