1. 字体系统在嵌入式GUI中的核心地位与挑战

在嵌入式系统里做图形界面开发，字体处理这块儿绝对是让人又爱又恨的部分。爱的是，一个清晰、美观的字体能让整个产品的档次瞬间提升，用户体验直接拉满；恨的是，嵌入式设备那点有限的RAM和Flash，还有捉襟见肘的CPU性能，处理起字体来真是处处掣肘。我见过太多项目，前期UI设计稿看着挺漂亮，一到真机显示就“翻车”——要么是字符显示不全，中文成了方框；要么是字体边缘锯齿感人，看起来非常廉价；更常见的是，稍微多显示几行文字，内存占用就飙升，系统开始卡顿甚至崩溃。

emWin的字体系统，可以说就是为解决这些痛点而生的。它不是一个简单的“点阵字库加载器”，而是一套从底层数据结构到上层应用接口都经过精心设计的完整解决方案。这套系统的核心目标很明确：在有限的资源下，提供尽可能强大、灵活的字体渲染能力。它要能处理从最简单的单色ASCII点阵，到带抗锯齿的TrueType矢量字体，还要能支持全球各种语言的字符集。这听起来像是桌面系统的要求，但emWin确实在嵌入式环境里做到了。

为什么字体这么重要？因为它是信息的载体。一个设备的交互界面，90%以上的信息是通过文本来传递的——菜单、标签、数值、提示、日志。字体渲染的质量和效率，直接决定了用户获取信息的准确性和舒适度。在工业HMI、医疗仪器、智能家居中控这些领域，字体显示不清或者速度慢，不只是体验问题，可能还会引发误操作。所以，深入理解emWin的字体系统，不是可选项，而是嵌入式GUI开发者的必修课。

2. emWin字体系统的架构与核心设计思路

emWin的字体系统设计遵循了“分层”与“插件化”的思想，这让它既保持了核心的简洁高效，又具备了强大的扩展能力。我们可以把它想象成一个印刷厂：有负责存储字模的“字库”（字体数据），有负责排版和选取字模的“排版工人”（字体驱动），还有最终把字模印到纸上的“印刷机”（渲染引擎）。

2.1 核心数据结构：GUI_TTF_DATA

我们先从最“底层”的、能体现其设计思想的数据结构看起。用户手册里提到了GUI_TTF_DATA，这个结构体是理解emWin如何管理外部字体（尤其是TTF）的关键。

typedef struct { const void * pData; U32 NumBytes; } GUI_TTF_DATA;

这个结构体极其简单，只有两个成员：一个指向字体文件原始数据的指针pData，和一个表示数据大小的NumBytes。但简单背后是深思熟虑的设计。

为什么这么设计？

1. 平台无关性：pData是一个const void *。这意味着emWin不关心你的字体数据是从哪里来的——它可以是在Flash中的一个常量数组，是从SD卡读取到RAM中的一块缓冲区，甚至是通过网络加载到内存中的。字体驱动只通过这个指针访问数据，完全解耦了数据来源和数据处理逻辑。
2. 零拷贝思想：理想情况下，字体数据可以直接存放在非易失性存储器（如QSPI Flash）中，并且该存储器支持内存映射（Memory-Mapped）或XIP（Execute In Place）访问。这样，pData可以直接指向这个地址，emWin在渲染时直接读取，无需将庞大的字体文件全部加载到宝贵的RAM中。这对于动辄几MB的TTF中文字库来说，是节省内存的杀手锏。
3. 为流式处理铺路：TTF文件结构复杂，emWin的TTF解析器（通过GUI_TTF_CreateFont()调用）可以按需读取文件中的特定表（Table），比如cmap（字符映射表）、glyf（字形数据表）。GUI_TTF_DATA这种原始的“数据块”定义，使得解析器可以基于统一的接口进行流式解析，而不是一次性处理整个文件。

实操心得：在实际项目中，处理TTF字体时，最稳妥的方式是将字体文件通过固件打包工具（如SRecord、bin2c等）转换成C语言数组，直接编译链接到程序的RODATA段（只读数据段）。这样，pData就直接指向这个数组的地址，NumBytes就是数组的大小。既保证了数据在Flash中的安全性，又利用了芯片的XIP能力，避免了运行时加载的开销和内存占用。例如：

// 假设使用工具生成了 font_songti.c 文件 extern const unsigned char font_songti_ttf[]; extern const unsigned int font_songti_ttf_size; GUI_TTF_DATA TTF_Data = { .pData = font_songti_ttf, .NumBytes = font_songti_ttf_size }; GUI_FONT * pFont = GUI_TTF_CreateFont(..., &TTF_Data, ...);

2.2 字体类型的标志位系统

字体不是千篇一律的，emWin用一套标志位（Flags）系统来精确描述一种字体的特性。手册中列举了GUI_FONTINFO_FLAG_PROP（比例字体）、GUI_FONTINFO_FLAG_MONO（等宽字体）、GUI_FONTINFO_FLAG_AA（抗锯齿字体）等。这些标志位不仅仅是描述，它们直接决定了渲染引擎采用何种算法。

• 比例字体 vs 等宽字体：这不仅仅是外观差异，更关乎存储和渲染效率。等宽字体（如GUI_Font8x16）每个字符宽度相同，在存储结构上通常是二维数组，查找和渲染速度极快，适合用于终端、代码显示。比例字体（如GUI_Font16_ASCII）每个字符宽度不同，存储结构更复杂（通常需要存储每个字符的宽度信息），但排版美观，节省水平空间，适合用于UI文本。
• 抗锯齿标志（AA/AA2/AA4）：这是提升显示质量的关键。AA表示抗锯齿，AA2和AA4则指明了抗锯齿的位数（2位或4位），即每个像素用多少比特来表示灰度等级（4级或16级灰度）。位数越高，边缘过渡越平滑，但带来的代价是：
  1. 存储空间倍增：一个原本1bpp（位每像素）的二值化字模，变成4bpp后，数据量是原来的4倍。
  2. 渲染计算量增加：渲染时需要处理灰度混合，而不是简单的覆盖。
  3. 可能依赖显示驱动：需要显示控制器支持相应的颜色格式（如ARGB4444、AL88等）才能正确显示半透明效果。

设计考量：emWin将这些属性标志化，使得字体驱动和渲染引擎可以通过检查标志位来切换不同的处理流水线。例如，渲染一个带AA4标志的字体时，引擎会自动启用alpha混合计算，而不是简单的位块传输（BitBLT）。

2.3 字符集的支持策略

字符集是字体系统国际化的基石。emWin采取了渐进式的支持策略：

1. ASCII (0x20-0x7E)：最基础的支持，涵盖英文、数字和基本符号。这是所有字体都默认或必须支持的。
2. ISO 8859-1 (Latin-1)：在ASCII基础上扩展了0xA0-0xFF的字符，覆盖了大多数西欧语言（如法语、德语、西班牙语）的附加字符（如ä, ö, ü, ç, ñ）。这是对欧洲市场设备的基本要求。
3. Unicode：终极解决方案。emWin在框架层面支持Unicode（使用UTF-16或UTF-8编码，取决于配置），这意味着你可以显示中文、日文、阿拉伯文等任何语言字符。但这里有一个关键点：手册中明确指出“It is the responsibility of the user to define these additional characters.” 也就是说，emWin提供了显示Unicode字符的“能力”和“钩子”，但具体的、超出标准字体包范围的字形数据，需要开发者自己提供（例如，链接一个完整的中文TTF字库，或者使用emWin提供的字体转换工具生成特定Unicode范围的点阵字体）。

这种策略非常务实。如果项目只需要英文，就只用ASCII字体，体积最小。如果需要德法西等语言，就选择带“_1”后缀的字体（如GUI_Font16_1），它会包含ISO 8859-1字符集。如果需要亚洲语言，就需要额外处理，比如使用GUI_Font16_HK（日文假名）或加载一个全中文字库。这避免了为所有项目强制绑定一个庞大的多语言字库，把资源使用的选择权交给了开发者。

3. 深入解析标准字体库：命名、选型与内存权衡

emWin自带的标准字体库是其开箱即用能力的体现。手册里列出了密密麻麻的字体列表，乍一看很复杂，但一旦掌握了其命名规则和设计逻辑，选型就变得非常清晰。

3.1 字体标识符的命名密码

GUI_Font[<style>][<width>x]<height>[x<MagX>x<MagY>][H][B][_<characterset>]这个命名规则是一把钥匙。

• GUI_Font：固定前缀，表明这是emWin内置字体句柄。
• <style>：可选，表示特殊风格。目前主要是Comic（漫画体），如GUI_FontComic18B_1。这给了UI一点个性化的可能。
• [<width>x]：这是区分等宽字体和比例字体的关键！如果字体名中包含<width>x（如8x16），则这是一个等宽字体，<width>就是每个字符的固定像素宽度。如果省略，如GUI_Font16，则是比例字体，字符宽度可变。
• <height>：字体的像素高度。这是选择字体大小的首要依据。
• [x<MagX>x<MagY>]：仅出现在放大字体中，如GUI_Font8x16x2x2。这表示该字体是由基础字体（这里是8x16）在X和Y方向分别放大2倍得到的。这是一种节省ROM空间的高级技巧：存储一个基础小字库，运行时通过算法放大，可以模拟出多种尺寸，避免了为每个尺寸都存储一套完整的字模数据。但放大算法可能导致边缘模糊，适合对精度要求不高的场景。
• [H]：表示“High”。当有多个同高度的字体时，带H的字体视觉上看起来更高（通常是因为大写字母高度C值更大）。例如，GUI_Font13H就比GUI_Font13的字母更修长。
• [B]：表示“Bold”，粗体。笔划更粗，更醒目。
• [_<characterset>]：字符集后缀。ASCII、1（ISO 8859-1）、HK（日文假名）、1HK（西欧+日文）、D（仅数字）。这是选择字体的最后一步，根据你的语言需求来定。

示例拆解：

• GUI_Font8x15B_ASCII：这是一个等宽字体，每个字符宽8像素，高15像素，是粗体，仅包含ASCII字符集。典型用于需要对齐的粗体文本显示，如按钮标签。
• GUI_FontComic24B_1：这是一个比例字体，漫画风格，高24像素，是粗体，包含ISO 8859-1字符集。适合用于标题或需要活泼风格的UI区域。
• GUI_FontD32：这是一个比例的数字字体，高32像素。只包含+ - . 0 1 2 3 4 5 6 7 8 9这些字符，专门用于大号数字显示，如仪表盘、计数器，因为去掉了字母符号，所以字模数据量小，显示效果可以优化得更好。

3.2 字体文件与内存占用的实战分析

手册中的表格不仅列出了字体名，还给出了关键的ROM大小和使用的文件。这是做内存预算时必须参考的数据。

以GUI_Font16_1为例：

• 测量参数：F:16, B:13, C:10, L:7, U:3。这告诉我们字体的整体高度、基线位置、大写字母高度、小写字母高度和下伸部分高度。这对于精确的文本布局计算至关重要。
• ROM大小：2714 + 3850 = 6564 字节。其中F16_ASCII.c占2714字节，F16_1.c占3850字节。_1字符集的文件比ASCII基础文件大了约40%，这就是支持西欧字符的代价。
• 对比GUI_Font16_ASCII：仅需2714字节。如果你的产品只卖英语国家，使用_ASCII版本能节省近6KB的Flash空间。在资源极其紧张的MCU（比如只有128KB Flash）上，这6KB可能就能决定一个功能是否能加上。

等宽字体的空间复用技巧： 注意看GUI_Font8x16、GUI_Font8x17、GUI_Font8x18这几个字体，它们的ROM大小都指向同一个文件F8x16.c（3304字节）。这意味着emWin通过一种“派生”机制，复用了8x16的字模数据，通过微调渲染参数（可能是行间距或基线偏移）来模拟出17、18像素高度的效果。这是一种非常极致的空间优化。GUI_Font8x16x1x2等放大字体也是同理，它们都共享F8x16.c的基础数据。

选型建议表：

3.3 比例字体与等宽字体的内部实现差异

理解这两种字体在emWin内部的存储差异，能帮你更好地诊断问题。

• 等宽字体存储：通常是一个二维数组fontData[CHAR_COUNT][BYTES_PER_CHAR]。每个字符的字模数据大小固定（高度 * (宽度/8 + (宽度%8?1:0))字节）。获取第N个字符的字模，就是一次数组索引操作，速度是O(1)。
• 比例字体存储：存储结构更复杂。它通常包含：
  1. 一个字符编码到索引的映射表（对于ASCII/ISO8859-1，可能就是简单的偏移计算）。
  2. 一个字符宽度表，记录每个字符的像素宽度。
  3. 一个字模数据块，所有字符的字模数据连续存放。每个字符的字模数据长度取决于其宽度和高度。 获取一个字符的数据，需要先通过映射表找到索引，再根据索引和宽度表计算出该字符字模数据在数据块中的偏移地址。这个过程比等宽字体稍慢，但带来了存储空间的节省（窄字符如‘i’占位少）和排版的美观。

注意事项： 当使用GUI_DispStringAt()等函数显示字符串时，对于比例字体，emWin需要遍历整个字符串，累加每个字符的宽度，才能知道字符串的像素长度。如果你需要频繁计算字符串显示长度（比如做自动换行），直接使用GUI_GetStringDistX()函数会比你自己计算高效得多，因为字体驱动内部已经优化了这个过程。

4. 高级字体应用：从TTF动态创建到抗锯齿渲染

标准字体库虽然方便，但总有无法满足需求的时候：比如需要一款特定的商业字体，或者要支持藏文、彝文等非常用字符。这时就需要用到emWin的高级字体功能。

4.1 使用TTF/OTF字体

GUI_TTF_CreateFont()是连接外部矢量字体的桥梁。其核心流程如下：

1. 准备数据：将TTF文件以GUI_TTF_DATA结构的形式准备好。
2. 创建字体：调用GUI_TTF_CreateFont()，指定大小、样式等参数。这个操作比较耗时，因为emWin需要在运行时解析TTF复杂的文件结构，提取并栅格化（Rasterize）指定尺寸的字形轮廓。
3. 缓存管理：对于动态创建的字体，emWin通常会在堆（Heap）中分配内存来存储栅格化后的字模缓存。你需要确保堆空间足够。对于频繁使用的大字体，建议在系统初始化时创建并常驻内存，而不是在需要显示时临时创建。
4. 设置与使用：创建成功后，会得到一个GUI_FONT*句柄，通过GUI_SetFont()设置为当前字体即可使用。

一个关键参数：抗锯齿级别。在创建TTF字体时，你可以指定抗锯齿级别（如GUI_TA_AA4）。级别越高，边缘越平滑，但渲染速度越慢，缓存占用也越大。对于小字号（如12px以下），2bpp抗锯齿（GUI_TA_AA2）通常就能获得不错的效果，且性价比最高。

// 示例：从内存数组创建一款14像素高、带4bpp抗锯齿的TTF字体 GUI_TTF_DATA TTF_MyFont = {_acMyFontData, sizeof(_acMyFontData)}; GUI_FONT * pMyTTFFont; pMyTTFFont = GUI_TTF_CreateFont(14, 0, GUI_TA_AA4, &TTF_Data); if (pMyTTFFont) { GUI_SetFont(pMyTTFFont); GUI_DispStringAt("Hello TTF!", 10, 10); } // 注意：使用完毕后，如果字体不再需要，应调用 GUI_TTF_DeleteFont() 释放内存。

4.2 SIF与XBF字体格式

除了运行时解析TTF，emWin还提供了两种预处理的字体格式，它们更适合资源受限的嵌入式环境：

• SIF (Segger Internal Font)：可以看作是emWin的一种“编译后”的字体格式。你可以使用SEGGER提供的字体转换工具（如FontCvt），将PC上的字体文件（如.ttf）提前转换成SIF格式的C文件。这个C文件包含了在指定尺寸和样式下预栅格化好的字模数据。编译时，它就像标准字体一样被链接进程序。

  • 优点：运行时无需解析，加载速度极快，内存占用确定（就是数组大小）。
  • 缺点：字体尺寸和样式固定，无法动态缩放。每增加一种尺寸或样式，就需要生成一个新的C文件，增加Flash占用。
  • 适用场景：UI中使用的、固定的、有限的几种字体。

• XBF (eXtended Bitmap Font)：这是一种更灵活的“外部字体”格式。字模数据可以存放在外部存储器（如SPI Flash、SD卡）中。emWin通过GUI_XBF_CreateFont()创建字体对象，并提供一个回调函数来从外部存储器读取所需的字模数据。

  • 优点：字体数据不占用宝贵的内部Flash，可以存储海量字体（尤其是中文字库）。可以动态更换字体文件。
  • 缺点：读取外部存储有速度延迟，可能影响渲染性能。需要实现稳定的存储驱动。
  • 适用场景：需要支持多种语言、大量字体，且内部Flash紧张，但有外部大容量存储的设备。

选择建议：对于产品UI的主字体（如一种英文字体，一种中文字体），优先使用SIF格式，保证渲染性能。对于不常用或可选的字体，可以考虑使用XBF格式存放在外部。

4.3 抗锯齿字体渲染的底层逻辑与优化

抗锯齿（Anti-aliasing）是让字体在低分辨率屏幕上看起来更平滑的技术。emWin支持2bpp（4级灰度）和4bpp（16级灰度）抗锯齿。

• 原理：在字符边缘的像素，不再是简单的0（透明）或1（着色），而是根据字形轮廓覆盖该像素的面积比例，赋予一个中间灰度值。例如，4bpp下，值可以是0-15，0为完全透明，15为完全着色，中间值表示部分着色。
• 渲染流程：当绘制一个抗锯齿字符时，渲染引擎需要：
  1. 从字模缓存中读取每个像素的灰度值（alpha值）。
  2. 根据当前文本颜色（GUI_SetColor()设置）和背景色，将这个alpha值应用于颜色混合公式（通常是Alpha Blending）。
  3. 将混合后的最终颜色写入帧缓冲区。
• 性能影响：抗锯齿渲染的计算量远大于二值化渲染。它涉及乘法、移位等操作。在低端MCU上，全屏刷新大量抗锯齿文本可能会成为性能瓶颈。
• 优化技巧：
  1. 局部刷新：只刷新文本变化的区域，而不是整个屏幕。
  2. 使用硬件加速：如果MCU的LCD控制器或2D加速器支持颜色混合（Blending），确保emWin的驱动配置能利用上这个硬件功能，可以极大提升抗锯齿渲染速度。
  3. 谨慎选择抗锯齿级别：对于小字体，2bpp和4bpp的视觉差异可能不大，但2bpp的性能和内存占用要好很多。可以通过实际显示对比来决定。
  4. 缓存渲染结果：对于静态不变的文本（如标签），可以考虑先将其渲染到一个内存设备（GUI_MEMDEV_Create()）中，然后多次快速复制（GUI_MEMDEV_CopyToLCD()），避免每次都进行复杂的抗锯齿计算。

5. 字体使用中的常见问题与实战排查指南

即使理解了原理，在实际项目中踩坑仍是难免的。下面是我总结的一些典型问题及解决方法。

5.1 字符显示乱码或为方框（“口口口”）

这是最常见的问题。

• 可能原因1：字体字符集不匹配。你试图用GUI_Font16_ASCII显示一个德语变音字符‘ä’（编码0xE4），而ASCII字体根本不包含这个字符。
  • 排查：确认要显示的字符的编码值，并检查当前设置的字体是否支持该编码范围的字符。使用带_1后缀的字体支持ISO 8859-1。对于中文，必须使用包含中文字模的字体（自定义TTF/SIF/XBF）。
  • 解决：切换到正确的字体。或者，在显示前对字符串进行编码检查和过滤。
• 可能原因2：字体数据损坏或链接错误。自定义的字体C文件没有正确添加到工程，或者数组在链接时被优化掉了。
  • 排查：在调试器中查看字体数据指针（pData）指向的地址是否有效，以及该地址开始的数据是否符合字体格式（对于标准字体，可以对比已知好的字体数据头）。
  • 解决：确保字体数组被声明为const，并且工程链接脚本正确包含了存放该数组的只读数据段。对于GCC编译器，注意const数组可能被放在.rodata段，要确保这个段不会被覆盖。
• 可能原因3：编码格式不一致。emWin内部默认使用ASCII或UTF-8/UTF-16（取决于GUI_WCHAR的定义）。如果你的字符串源是其他编码（如GB2312），直接显示就会乱码。
  • 解决：统一使用UTF-8编码是最佳实践。在代码中书写字符串时注意编译器的编码设置，从外部（如串口、文件）接收字符串时，先进行转码。

5.2 文本显示位置偏移或截断

• 可能原因：字体度量（Metrics）理解错误。GUI_DispStringAt()的坐标参数(x, y)指定的是文本**基线（Baseline）**的起始位置，而不是文本矩形的左上角。基线是大部分字母“坐”在上面的那条线。
  • 影响：如果你以为y是左上角，那么像‘y’, ‘g’, ‘j’这种有下伸部（Descender）的字母，下半部分可能会被画到屏幕外面去。
  • 解决：使用GUI_SetTextMode(GUI_TM_TRANS)可以避免用背景色覆盖，但更根本的是要理解基线。如果需要精确控制文本的包围框，可以使用GUI_GetFontSize()、GUI_GetYDistOfFont()等函数获取字体的高度、基线偏移等信息，再进行计算。
  • 示例：要在一个矩形框内居中显示文本，计算应为：

    int FontSizeY = GUI_GetFontSizeY(); int TextWidth = GUI_GetStringDistX(“Text”); int x = (RectWidth - TextWidth) / 2 + RectX0; int y = (RectHeight - FontSizeY) / 2 + RectY0 + GUI_GetYDistOfFont() - 1; // -1是常见微调 GUI_DispStringAt(“Text”, x, y);

5.3 使用TTF字体时内存不足或创建失败

• 可能原因1：堆（Heap）空间不足。GUI_TTF_CreateFont()会在堆上分配内存来缓存栅格化后的字模。
  • 排查：在调用创建函数前后，打印或调试查看堆的剩余空间。emWin通常使用malloc，你可以实现自己的GUI_X_Alloc系列函数来跟踪内存分配。
  • 解决：增大系统的堆空间。或者，考虑使用SIF预转换字体，避免运行时分配。
• 可能原因2：TTF文件数据错误。指针错误或大小不对。
  • 排查：检查GUI_TTF_DATA中的pData和NumBytes是否与实际的字体文件完全一致。确保字体文件是完整的、未损坏的。
  • 解决：使用可靠的字体文件，并通过校验和（如CRC32）确保数据在存储和传输中未出错。
• 可能原因3：请求的字体尺寸过大或过小。TTF引擎有尺寸限制。
  • 解决：尝试一个常见的尺寸，如12, 14, 16, 20, 24。避免使用奇特的尺寸。

5.4 多字体混合使用时的性能下降

• 可能原因：字体切换开销。每次调用GUI_SetFont()，emWin内部需要更新一些渲染状态。如果在同一帧内频繁切换字体（比如在循环中交替显示不同字体的文本），会产生额外开销。
  • 优化：对显示内容进行排序，尽量将使用同一种字体的文本绘制操作集中在一起进行。例如，先画完所有大标题（字体A），再画所有正文（字体B），最后画所有小标签（字体C）。
  • 进阶：对于复杂的、静态的界面，可以考虑使用内存设备（Memory Device）将整个窗口或控件预先绘制好，然后一次性刷新，这样可以完全避免绘制过程中的字体切换。

5.5 自定义字体工具链的使用心得

SEGGER提供的FontCvt工具是生成SIF/XBF字体的利器。在使用中有几个关键点：

1. 字符范围选择：不要盲目选择“All”。仔细分析你的项目真正需要显示哪些字符。如果只显示英文和数字，就只选ASCII。如果需要德法西语，就添加ISO 8859-1。对于中文，可以使用“Unicode Range”功能，只添加你UI中用到的汉字（比如几百个常用字），这能极大减小字体文件体积。一个包含6000个汉字的字体和包含200个汉字的字体，体积可能相差几十倍。
2. 抗锯齿设置：在工具中就可以选择2bpp或4bpp抗锯齿。在这里生成抗锯齿数据，比在运行时让emWin去处理TTF抗锯齿，性能更好，结果更可控。
3. 输出格式：选择“C File”生成SIF，选择“XBF”格式用于外部存储。生成XBF时，注意数据排列格式（位序）是否与你的读取函数匹配。
4. 版本匹配：确保FontCvt工具的版本与你的emWin库版本兼容。不同版本生成的字体数据格式可能有细微差别。

字体系统是嵌入式GUI的“面子工程”，也是资源消耗的“大户”。吃透emWin的字体机制，意味着你能在视觉效果和系统性能之间找到最佳平衡点。从根据产品地域选择最小字符集，到为不同UI元素匹配最合适的字体类型，再到利用好外部存储和内存设备这些高级特性，每一步选择都直接影响最终产品的品质和稳定性。我的经验是，在项目早期就制定明确的字体策略，并预留足够的测试时间，远比在后期被字体问题搞得焦头烂额要划算得多。毕竟，用户第一眼看到的，就是屏幕上清晰、美观、流畅的文字。