做游戏显示艺术字体尤其是那种带描边、带质感、会随情绪变色的数字和标题时很多人的第一反应是让美术出图然后用 Sprite 一张张替换。这套方案做静态能凑合一旦遇到倒计时、比分跳动、金币增减这类高频变化的文本性能和开发心态都会崩。我在项目里踩过这个坑之后才彻底搞明白 Cocos 的 Label-atlas 到底该怎么用以及为什么说它是“艺术字体展示”与“运行效率”之间的最佳平衡点。这篇文章就专门聊透这一个点Cocos 艺术字体的导入流程以及 Label-atlas 的完整使用方法。网上关于这个话题的资料很碎多半是一句“Cache Mode 选 CHAR”就完了完全没讲为什么这么选、图集该怎么生成、字符顺序为什么决定成败。这里我用做过的项目经验从原理到实操把 Cocos Creator 里 Label-atlas 的完整链路串起来讲顺便把那些官方文档里不会写、只有真机跑过才会遇到的坑一并列清楚。不管你是美术转来的、刚接触 Cocos 的新手还是被这个问题困扰过的老开发者照着做基本都能一次跑通。1. 先搞清楚 Label-atlas 到底是什么1.1 把字符“焊”在纹理上的渲染思路传统 Label 组件显示文本走的是系统字体或 TTF 字体逐帧绘制的路线。系统字体在不同平台的渲染效果不一致TTF 字体虽然风格统一但每帧都要让 CPU 把字形轮廓算出来再填色碰上频繁变动的文本节点DrawCall 和 CPU 开销都会涨。而 Label-atlas 的思路完全不同它把需要用到的所有字符预先按固定的顺序“打印”到一张大图上运行时不解析字形只从这张纹理里按坐标抠出对应的那一小块贴上去。这个思路本质上和早期的位图字体一样但 Cocos 里做了规范化处理产物就是一张 PNG 纹理加一个配套的字符映射文件。映射文件描述了每个字符在图集里的矩形区域、宽度、高度和偏移量引擎根据这些数据快速定位并渲染。理解到这一层很多所谓“神秘问题”的答案就摆在眼前了显示乱序是映射关系错位显示问号是图集里根本没有这个字符。1.2 字符集顺序才是真正的命门第一次用 Label-atlas 时我天真地以为随便排一下字符就行。结果在 Cocos Creator 的 Label 组件里把 Cache Mode 设为 CHAR再把一个 PNG 拖进 Custom Font 后屏幕上出现了“0”显示成“9”、“A”显示成“Z”的诡异情况。排查了很久才发现引擎在没有 .fnt 配置时会按一套内置的默认字符顺序去索引图集而这套顺序和我生成图集时的排列顺序完全不一致。Cocos Creator 内置的默认字符顺序大致是先是空格然后英文标点接着数字 0-9再是大写 A-Z、小写 a-z最后是常用符号。也就是说如果你用 BMfont 这类工具导出时勾选了自动排序导出后的顺序通常是按 ASCII 表排的这反而和引擎默认顺序不一致。这里强烈建议不要依赖默认顺序而是用工具显式生成一份严格的 .fnt 文件把映射表带进项目。这样字符串无论怎么拼接引擎都按配置文件里的坐标去取图不会错位。1.3 与 BMFont、图集方案的横向对比方案灵活性静态文本性能动态文本性能制作复杂度系统字体 Label高一般一般零成本TTF 字体高一般较差低成本多张 Sprite 替换中低极差高成本Label-atlas仅限图集内字符高极高中成本Sprite 替换方案的问题是每换一位数字都要切换节点属性对至少三位数以上的计分来说 Debug 都费劲。Label-atlas 本质上是拿“预先准备的一组字符”换“运行时的极致性能”特别适合计分板、伤害飘字、金币余额、倒计时这类字符集合小、变化频率高、但观感要求强的场景。如果文章标题里带“艺术字体”四个字多半都是为了做这类需求。2. 准备素材字体图和映射文件的生产流程2.1 工具选型一个项目不同阶段的选择做 Label-atlas 绕不开两步准备艺术字形、导出图集与配置文件。字形部分通常由美术在 Photoshop、Illustrator 里按风格绘制或者从成熟字体修改描边和质感这步没什么好说的。关键是图集与映射文件的生成我实际用过的工具有这几个BMFontWindows老牌利器支持自定义纹理页输出 .fnt 的多种格式最关键的是可以自己控制字符顺序和字符集。Glyph DesignermacOS界面现代化对中文支持更好但收费。ShoeBox适合从一张已有角色贴图反推配置偶尔救急不错。在线生成工具适合简单数字和少量英文但字符集控制较弱不推荐做中文字库。对大多数游戏项目来说Windows 环境用 BMFont 是最省事的方案。它虽然界面老旧但胜在稳定和可控。这里注意一点导出纹理时建议让图集保持透明背景并尽可能把字符紧密排列这样最终包体和显存占用都会好看一些。2.2 常见实践手工排字符保证顺序可见可控相比靠工具的“自动顺序”我更推荐在生成前就显式定义好字符表。例如只需要“0-9”和英文冒号“:”那我就在工具里只输入这些字符顺序必须是空格可选、0 到 9、冒号。字体图内从左到右、从上到下按这个顺序排列。这样做的最大好处是出问题时可以直接对着源图逐个查。不同功能模块共用一套图集时不会互相污染。减少不必要的字符降低纹理尺寸包体更小。如果你是在做中文字体千万不要把常用汉字全塞进去几千个汉字排成一张 2048x2048 也未必放得下而且运行时加载也不划算。项目里真要显示中文艺术字要么严格限制词库比如只放几十个固定的玩家名用字要么考虑序列帧方案代替。2.3 导出配置时必须确认的三件事导出 .fnt 后建议用文本编辑器打开文件看一眼确认三件事第一字符的 id 是否与你预设的字符集一致中文尤其要看编号是否为 Unicode 十进制第二页page字段是否指向正确的 PNG 文件文件名和实际导入资源名必须一致第三每个字符的 width、height、xoffset、yoffset 是否合理尤其注意空格字符如果缺失会导致字符串拼接后空白宽度完全错乱。这里给一个 .fnt 文本格式的示例片段方便你判断工具导出的是否正常info faceArtNumber size64 bold0 italic0 charset unicode1 common lineHeight64 base51 scaleW512 scaleH256 pages1 packed0 page id0 fileart_number.png chars count12 char id32 x0 y0 width0 height0 xoffset0 yoffset0 xadvance24 page0 chnl0 char id48 x2 y2 width32 height48 xoffset0 yoffset12 xadvance34 page0 chnl0 char id49 x36 y2 width29 height48 xoffset0 yoffset12 xadvance31 page0 chnl0id32 是空格id48 是字符“0”依次类推。看到这种结构基本可以判定配置是完整的。Cocos Creator 在导入时读取的就是这些字段你不用在代码里写任何解析逻辑引擎全都包了。3. Cocos Creator 内的导入与组件配置实操3.1 资源导入路径与类型匹配把导出的 PNG 和 .fnt 文件一起放进项目的 assets 目录Cocos Creator 会自动识别。如果 PNG 和 .fnt 没有放在同一目录或者文件名对不上编辑器会出现资源加载不完全的问题。我曾经踩过一次PNG 叫 art_num.png.fnt 里写的却是 art_number.png结果界面上所有字符全变问号查了半天才发现原来是配置里的文件名和实际资源名不一致。导入后建议在资源管理器里确认 .fnt 资源的类型显示为“字体”并且点击它时属性检查器里能看到“Font Family”之类的字段。如果没有说明文件解析失败多半是 .fnt 文件里含有了 Cocos 不兼容的字段或者文件编码不是 UTF-8。顺手把 .fnt 转成 UTF-8 无 BOM 的编码可以规避不少中文字库项目的编码问题。3.2 Label 组件的关键配置渲染模式与缓存模式在场景中新建一个 Label 节点然后在属性检查器找到 Label 组件。设置字符串为你要显示的初始文本比如“SCORE: 100”。关键点来了先把 Overflow 模式设为 NONE 或 CLAMP然后找到Cache Mode下拉框选择CHAR。CHAR 模式就是为 Label-atlas 准备的它会在初始化时把所有用到的字符缓存成一张纹理节点后续反复修改文本内容都无压力。选择 CHAR 后下方会出现 Custom Font 的槽位把之前导入的 .fnt 资源拖进去。此时界面上应该立刻能看到艺术字生效了。如果没有任何变化关掉编辑器重新打开一次有时资源映射需要刷新。如果显示乱码先别怀疑引擎回到第 2.2 节检查字符顺序。这里补充一个容易被忽略的配置点Cache Mode 还有 BITMAP 模式这种模式是按固定 Bitmap 缓存整行文本更适合文字内容不经常变的场景而 CHAR 模式缓存的是单个字符适合频繁改内容的场景。做计分数字这类高频更新需求务必选 CHAR 而不是 BITMAP否则你会发现改一次分数就重建一次纹理缓存性能优势全部白费。3.3 代码动态更新文本的推荐姿势Label-atlas 的便利之处在于你可以用常规的 string 赋值来更新内容它底层会重新查找字符并拼贴不需要为每个数字单独处理 Sprite。举个典型例子const { Label } cc; // 假设这是计分Label节点 const scoreLabel: cc.Label this.node.getComponent(cc.Label); let score 0; function addScore(step: number) { score step; scoreLabel.string SCORE: ${score}; }这里唯一要留意的性能细节是不要每帧都赋值相同的字符串。Cocos Creator 的 Label 组件在 string 相同时会直接跳过渲染重建但内部仍不可避免有一次字符串比较。高频场景下可以先判断数值是否有变化再赋值比如把上一次分数存一个成员变量只有变了才更新 Label。这个习惯在节点数量较多时对帧率有明显帮助。3.4 美术字体的颜色调整技巧Label-atlas 所用的纹理一般是带透明通道的彩色图如果你想在代码里动态改变艺术字的颜色原生 Label 组件的 color 属性只会影响顶点色对已经烘焙在纹理里的颜色不会产生预期效果。如果你需要同一个艺术字体在场景里呈现红、蓝、金三种颜色最稳妥的方案是在美术阶段把字形做成白色或白色偏灰利用顶点染色变成任意颜色这也是商业项目里最常见的一种做法。如果你拿到的美术资源本来就是金色那也别慌可以用 Shader 做色彩替换但不建议为了几个数字引入复杂后效。项目里我通常会让美术额外导出一份白色字形图这样可以同时应对“动态染色”和“纯静态多色”两种需求。4. 实操过程中的关键业务细节4.1 数字滚动与加分的动效实现很多游戏需要显示金币增加时的“飘字”效果或者大数字伤害的跳动。Label-atlas 特别适合这类场景因为它更新字符串的开销极小。我做伤害飘字时一般是生成一个临时 Label 节点用 Label-atlas 字符配合 tween 做放大与淡出。为了保证透明度也能控制会要求这张艺术数字图导出为白色的字形见 3.4这样透明度变化和颜色染色都能通过 Label 的 color 属性统一处理。这里给出一个简单但完整的做法准备一个对象池保存伤害飘字节点每次产生飘字时从池里取设置 string 后从目标点向上位移并缩小动画结束回收到池中。因为 Label-atlas 的字符查找和渲染都很快这种批量飘字完全不会打崩帧率我实测场景里同时存在 30 个飘字节点时DrawCall 增量保持在一个很小的数值附近。4.2 排版与对齐的约束关系使用 Label-atlas 时会发现它的排版不如 TTF 字体那么精细因为每个字符的 xadvance 和 yoffset 都是在生成时固定死的。做居中、右对齐等操作时引擎会基于这些固定度量来排版所以如果 .fnt 的度量不准确就会出现文字整体偏左、偏右或字间距错乱的情况。遇到排版问题时最有效的排查办法是先在文本编辑器里检查 .fnt 中每个字符的 xadvance 是否合理。对于数字字体xadvance 一般为“字符宽度 字间距”如果发现数值明显偏大例如把 8 写成 80那对齐就会乱。把这类值修正后重新导入即可。另外设置 Label 的 Overflow 为 CLAMP 时文本需要按节点宽度约束显示范围如果艺术字超出节点边界直接裁掉是常态注意给节点留足尺寸。4.3 多分辨率适配下的比例控制艺术字属于“最怕拉伸”的资源之一。我给项目做多分辨率适配时对 Label-atlas 节点的做法是不直接改 Label 的字号而是通过节点的 scale 来控制显示尺寸。这有几个好处渲染贴图保持原始像素比不变不会出现模糊适配逻辑可以和其他 UI 元素统一如果后续要替换更高清的字体图集业务层的尺寸逻辑完全不用动。以设计分辨率 1280x720 为例一个数字节点的参考宽度是 64 像素在 1920x1080 的屏幕上把节点缩放系数设为 1920/1280 1.5显示依然清晰锐利。很多新手会把 Label 组件的 Font Size 从 64 改成 96这会让引擎去拉伸位图字符最终效果发虚。记住一句话位图字体的字号就是原始像素别指望引擎帮你高质量放大要放大就放大节点。4.4 与其它渲染组件的排序关系Label-atlas 也是一个普通的渲染节点用到的也是引擎的 UI 渲染队列。当它跟粒子、动画特效混排时需要注意节点层级和 RenderRoot 的顺序。比如伤害飘字一定希望显示在最上层那么就要保证飘字节点位于 Canvas 节点树较靠后的位置或者使用 UITransform 的 siblingIndex 调整。如果出现了“艺术字被特效盖住”或者“艺术字透出到 UI 背景后面”的情况优先检查节点树的层级顺序而不是盲目修改 Blend Mode。Label-atlas 一般使用透明混合Blend Mode 保持默认即可强行改成其它模式会导致描边发黑或半透明区域异常。5. 常见问题排查与避坑速查5.1 问题现象对照表现象大概率原因解法字符显示为乱序图集字符排列与引擎默认顺序不一致显式导入 .fnt 映射文件全部显示为问号/方框图集中缺少对应字符或 .fnt 未成功加载增大字符集检查配置文件与 PNG 文件名文字整体模糊发虚字号被引擎缩放保持 Font Size 等于原始像素用节点 scale 控制大小空格宽度异常空格字符缺失或 xadvance 为 0在字符集里加入空格并设置合理宽度中文字符显示为两三个字符挤在一起中文编号是 Unicode 十进制但工具导出成 UTF-16 id检查 .fnt 的 id 字段必要时转换成 Unicode 十进制真机上文字偶发消失纹理图集过大导致显存加载中断缩小图集尺寸避免超过 2048x2048修改字符串后界面不刷新同字符串赋值被引擎跳过或 Cache Mode 设置成 BITMAP确认数值变化后再赋值改用 CHAR 模式5.2 字符验证字符串一个能救命的小习惯排查 Label-atlas 问题时最怕的是“所有字符都混在一起不知道哪个错了”。我的习惯是准备一个固定的验证字符串把字符集里的所有字符按顺序排出来比如0123456789: ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz每套艺术字体导入完成后先在场景里放一个 Label 节点专门显示这个字符串跑起来截图留档。后续任何人改动字体图集只要对比截图就能迅速定位是哪个字符出了问题。这个验证字符串我会写进项目的交接文档里避免下一任开发者在深夜对着乱码怀疑人生。5.3 关于 .fnt 文件格式的三点补充Cocos Creator 对 .fnt 的支持范围比较宽松但最稳的是文本格式的 .fnt尽量避免使用二进制格式。文件编码尽量使用 UTF-8 无 BOM某些 Windows 工具默认输出 ANSI 编码会导致中文字符编号错乱。如果 .fnt 和 PNG 放在子目录而场景在另一个目录导入时注意保证资源文件夹被正确识别为 Bundle否则构建时会找不到字体资源。6. 项目里被验证过的几个扩展思路6.1 用灰度图集实现多色艺术字如果你需求很明确游戏里同一套数字会出现多种颜色红、蓝、紫、金建议让美术把原图做成白色配合顶点色技术做运行时染色。这比准备多套 PNG 更省资源也更灵活。我曾在项目的打赏飘字里用这一招只维护一张图集却实现了四种颜色和三种透明度组合后续美术改配色只改代码里颜色值不用重新出图。6.2 数字跳动动画让计分不呆板Label-atlas 字符独立渲染的特性很适合做“每一位数字翻牌”的动画效果。比如比分从 100 变到 137可以把这个变化拆成三个独立的 Label-atlas 节点分别在个位、十位、百位上做滚动渐变。这套玩法如果用系统字体会牵涉到字形的重新采样很麻烦但用位图字体就是纯粹的位置与透明度动画引擎压力很小。6.3 与对象池配合扛住高频伤害飘字伤害飘字是最容易让渲染崩溃的场景。同一帧几十个飘字节点同时出现如果每个都是独立 Node 且频繁重建即使 Label-atlas 性能再好也吃不消。配合对象池把不活跃的飘字节点回收复用可以维持一个稳定的 DrawCall 峰值。这里注意对象池里的节点不要清零字符串只更新字符串内容和播放动画因为 Label-atlas 的字符缓存建立后重复利用会跳过缓存重建速度更快。6.4 极少数字体需求的终极方案序列帧如果只是某个节日活动的超炫标题字符集又动辄几十个也不想维护图集映射关系那可以考虑直接用序列帧动画播放一个完整的标题动画。这不算严格意义的 Label-atlas 使用场景但能提醒我们技术选型是围绕需求做的所有方案都只是工具。Label-atlas 适合“字符集合可控 高频变化 需要一定艺术感”的场景序列帧适合“一次性展示 复杂动态 不需要变化内容”的场景两者并不冲突。我自己做项目到现在最深的体会是Label-atlas 不是一个高深的技术而是一个“用生产流程的确定性换运行时的省心”的典型思路。它真正考验人的地方不是拖拽几个资源、改几个属性而是你是否能保证图集、字符映射、运行时需求这三者始终对齐。把这套流程理顺了以后不管换几任美术、调多少版 UI这份字体方案都会是项目里最稳的模块之一。最后再提醒一句每次拿到新的艺术字图集先跑一遍验证字符串再谈后续优化。