一、字体基础与嵌入式挑战：点阵字体与矢量字体原理
做嵌入式开发的朋友，十有八九都被字体问题折磨过。我入行那会儿，第一次在STM32上显示中文，折腾了整整三天——不是显示乱码，就是内存爆了。后来我才明白，字体这东西，看着简单，背后全是资源博弈。
今天咱们就从最基础的东西聊起。点阵字体和矢量字体，到底有什么区别？嵌入式系统为什么对字体这么“敏感”？存储痛点又在哪里？
1.1 点阵字体：最朴素的方案
点阵字体，说白了就是把每个字符画在一个网格里。比如一个16×16的点阵，每个点要么亮要么灭，用1个bit表示。16×16=256个bit，也就是32个字节。
核心公式：点阵字体大小 = 宽度(像素) × 高度(像素) ÷ 8
举个例子，一个常用的16×16中文字库，包含6763个汉字：
每个字大小 = 16 × 16 ÷ 8 = 32 字节
总大小 = 6763 × 32 = 216,416 字节 ≈ 211 KB嗯，211KB，听起来不大对吧？但你要知道，很多MCU的Flash总共才64KB或128KB。一个中文字库就占满了，别的代码还放不放？
我在一个智能电表项目里就踩过这个坑。当时选了颗STM32F103C8T6，Flash只有64KB。字库塞进去之后，主程序只剩不到10KB的空间。最后只能砍掉二级汉字，只保留GB2312中的一级汉字（3755个），勉强挤了进去。
注意：点阵字体放大后会出现锯齿。你想想看，一个16×16的点阵放大到32×32，每个点变成2×2的方块，边缘全是“楼梯”。这在工业HMI上还能忍，但如果是消费级产品，用户一眼就能看出粗糙。
1.2 矢量字体：优雅但昂贵
矢量字体就不一样了。它用数学曲线来描述字形轮廓，最常见的是TrueType（TTF）和OpenType（OTF）。每个字符由若干条贝塞尔曲线组成，存储的是控制点坐标和曲线类型。
矢量字体的优势很明显：
- 无级缩放：放大多少倍都不会锯齿
- 存储效率：一个TTF文件通常只有几百KB，却能包含几千个字符
- 样式丰富：粗体、斜体、下划线都可以通过算法生成
但问题来了——渲染矢量字体需要数学计算。每条曲线都要用贝塞尔公式逐点计算，再填充内部区域。这个计算量，在PC上不算什么，但在主频几十MHz、没有FPU的MCU上，简直是噩梦。
我记得有个同事做过一个项目，用ESP32驱动TFT屏幕显示矢量字体。一个“永”字，渲染用了将近200毫秒。用户翻页的时候，屏幕要卡顿半秒才能显示出来。用户体验？别提了。
| 对比维度 | 点阵字体 | 矢量字体 |
|---|---|---|
| 存储大小 | 固定，与字号成正比 | 较小，与字符复杂度相关 |
| 缩放质量 | 放大有锯齿 | 无级缩放，边缘平滑 |
| 渲染速度 | 极快，直接拷贝像素 | 较慢，需要数学计算 |
| 内存占用 | 运行时几乎无额外开销 | 需要帧缓冲和临时计算空间 |
| 适用场景 | 低端MCU、固定字号 | 高端MCU、多字号需求 |
1.3 嵌入式系统的资源限制
做嵌入式字体优化，你得先搞清楚你的“战场”长什么样。我列几个最常见的限制：
- Flash存储：大部分MCU的Flash在64KB~2MB之间。一个完整的中文字库（GB18030-2000，约27000字）用16×16点阵存储，需要27000×32≈864KB。很多芯片根本放不下。
- RAM空间：运行时内存通常只有几KB到几百KB。渲染一个32×32的字符，需要1024字节的帧缓冲。如果同时显示多个字符，内存很快就见底了。
- CPU算力：主频几十到几百MHz，没有硬件浮点单元。矢量字体的贝塞尔曲线计算，每次都要做大量乘法运算，CPU根本扛不住。
- 功耗限制：电池供电的设备，CPU跑得越快，功耗越高。渲染矢量字体时CPU全速运转，电流可能从10mA飙升到50mA以上。
我的经验：选型阶段就要把字体存储算进去。我习惯先确定最小字号和最大字号，然后估算字库大小。如果Flash不够，要么换大容量芯片，要么考虑外挂SPI Flash。千万别等到代码写完了才发现放不下。
1.4 字体存储的痛点
痛点这东西，不亲自踩一遍，光看文档是体会不到的。我总结几个最常见的：
- 痛点一：字库太大，Flash装不下。这是最直接的。一个16×16的完整中文字库就要800多KB，很多MCU的Flash总共才512KB。怎么办？要么砍字，要么外挂存储。
- 痛点二：多语言支持导致存储爆炸。中文、英文、日文、韩文、阿拉伯文……每种语言一套字库。我做过一个多语言POS机项目，光字库就占了4MB的SPI Flash。每次更新固件，光烧写字库就要好几分钟。
- 痛点三：不同字号需要不同点阵。如果你需要12×12、16×16、24×24三种字号，就得存三套字库。存储量直接翻三倍。矢量字体虽然能缩放，但渲染速度又跟不上。
- 痛点四：字库更新困难。产品出厂后，如果发现某个字显示错误，或者需要增加新字符，就得更新整个字库。OTA升级字库？那得保证网络稳定、Flash有足够空间、升级过程中不能断电……麻烦得很。
避坑指南：我曾经在一个项目里用了外挂SPI Flash存字库，结果没注意SPI Flash的读取速度。主控读取一个字需要几百微秒，导致屏幕刷新时出现明显的“逐字显示”效果。后来换成Quad SPI Flash，读取速度提升了4倍，问题才解决。所以，存储介质的速度也要提前评估。
1.5 本章知识体系
下面这张图，把本章的核心逻辑串起来了。你可以看到，从字体基础到嵌入式挑战，再到存储痛点，是一条完整的链路。
你看，从点阵和矢量两种字体方案出发，到嵌入式系统的资源限制，再到具体的存储痛点，每一步都有取舍。没有完美的方案，只有最适合你项目的方案。
接下来的章节，我们会深入探讨各种压缩算法和存储优化策略。但今天这些基础，是后面所有内容的地基。地基打不牢，后面盖什么楼都得塌。