直接存储uint8_t位图字库浪费Flash，因汉字/ASCII字模稀疏、含大量全零行；应采用按字为单位的RLE+行内bitpack压缩，配合4字节固定头实现零解压开销、O(1)随机访问与极小RAM占用。
为什么直接存 uint8_t 位图字库在 Flash 里太浪费
单色字模（如 16×16 点阵）按字节对齐存储时，每行 16 点需 2 字节，整字 32 字节。但实际有效信息只有 256 bit = 32 byte，看似没冗余——问题出在「字形稀疏性」：汉字笔画集中在局部区域，大量连续 0x00 或 0xFF 行；英文 ASCII 字模更甚，小写字母常只有中间几行有数据。直接存原始字节，Flash 里塞满无意义的全零行，压缩率几乎为 0。
实操建议：
- 先用工具统计字库中连续全零行占比（例如遍历所有字模，memcmp(row, "\x00\x00", 2) == 0），若 >40%，说明有压缩空间
- 避免用通用压缩算法（如 zlib）——解压需要 RAM 和 CPU，嵌入式设备扛不住
- 优先选「无损、零解压开销、可随机访问」的方案，比如行程编码 + 行内紧凑打包
怎么用 RLE + 行内 bitpack 压缩字模并保持 O(1) 查找
核心思路：不压缩整个字库，而是按「单字」为单位压缩，每个字模头部存长度+偏移，内部按行压缩，且每行只存非零段。
常见错误现象：
- 把整个字库当字符串跑 zlib_compress() → 解压要 2KB RAM，MCU 直接卡死
- 用 Huffman 编码但没建表 → 每次查字都要重建码表，CPU 占用飙升
- 行压缩后丢掉行高信息 → 渲染时无法定位下一行起始，显示错位
实操建议：
- 每个字模结构体固定 4 字节头：uint16_t data_offset（相对基址）、uint8_t height（实际非空行数）、uint8_t flags（比如 bit0=是否含全 0xFF 行）
- 行数据用 RLE 编码：每行先写一个 uint8_t run_len（该行压缩后字节数），再跟 run_len 个字节；全零行直接记 run_len = 0，跳过数据
- 行内进一步 bitpack：比如 "00001111" 存成 0xF0，而不是两个字节 0x00 0xFF —— 这步让 16×16 字模平均从 32B 压到 18~22B
- 查字时：先读头 → 跳到 data_offset → 按 height 循环读 run_len → 遇到 run_len == 0 就填 0x00 行，否则 memcpy 到临时 buffer 渲染
memcpy 渲染前要不要解压到 RAM？
不要。这是最常踩的坑：有人把压缩字模每次全解压到 RAM 再 memcpy 到 LCD 控制器 FIFO，结果 10 个字就吃掉 512B RAM，中断里还可能触发栈溢出。
使用场景决定策略：
- 若 LCD 支持“位图直刷”（如 ST7735 的 RAMWR 命令接受串行 bit 流）→ 直接边解 RLE 边推 bit 到 SPI，0 RAM 开销
- 若只能刷字节（如大部分 SSD1306）→ 只解当前行到 2B 临时 buffer（16 点=2 字节），memcpy 完立刻覆盖，RAM 占用恒定 2 字节
- 绝对避免：分配 32B buffer 存整个解压字模 —— 这和不压缩没区别，只是把 Flash 压力转嫁给了 RAM
编译期压缩比运行时压缩更可靠
运行时压缩字库（比如启动时调用 rle_encode()）看似灵活，但嵌入式 Flash 写寿命有限，且首次启动延迟不可控；而编译期用 Python 脚本预处理，生成 C 数组，能彻底规避运行时不确定性。
参数差异注意点：
- Python 脚本输出数组时，加 __attribute__((section(".font_flash")))（GCC）或 __flash（AVR）确保进 Flash，别误进 RAM
- 不同 MCU 对齐要求不同：STM32 希望 4 字节对齐，否则 *(uint32_t*)ptr 可能硬 fault；脚本里每个字模起始地址手动 pad 到 4B
- 字模顺序必须和字体索引严格一致（比如 ASCII 0x20~0x7E 连续排），否则 font_data + (ch - ' ') * sizeof(header) 算偏移会错
真正难的不是压缩算法本身，是让压缩后的数据结构能被极简代码在 2KB RAM 里安全、确定地随机访问 —— 所有设计决策都要回退一步问：这一行代码，会在中断里执行吗？这个指针，指向 Flash 还是 RAM？
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
