1. 课程导入
说到 GUI，大家可能觉得这词儿挺唬人。其实说白了，GUI 就是「图形用户界面」—— 你手机上的图标、智能手表上的表盘、车载屏幕上的导航按钮，这些都是 GUI。我刚开始做嵌入式时，还在用 128×64 的单色点阵屏，那时候写个菜单全靠自己画像素点，现在想想真是硬核。
GUI 的核心任务就三个：显示、交互、反馈。显示就是把数据变成图形；交互是处理触摸、按键这些输入；反馈则是让用户知道操作生效了。这三件事在 PC 上很成熟，但到了嵌入式环境里，情况就完全不一样了。
嵌入式 GUI 的特点：资源受限下的艺术
嵌入式 GUI 和 PC 上的 GUI 最大的区别是什么？一个字：穷。
- 内存小：MCU 的 RAM 通常只有几十 KB 到几 MB，PC 上随便一张图片就几十 MB，这在嵌入式里根本玩不转。
- CPU 弱：主频几十 MHz 到几百 MHz，没有 GPU 加速，所有渲染都得靠 CPU 硬扛。
- 显示资源有限：常见分辨率从 128×64 到 800×480，色彩深度从 1 位到 16 位，和 PC 的 4K 屏没法比。
- 实时性要求：很多嵌入式 GUI 用在汽车仪表、医疗设备上，界面响应必须毫秒级，卡顿是要出问题的。
核心矛盾：嵌入式 GUI 要在有限的硬件资源上，实现流畅、美观、可靠的人机交互。这就像用自行车零件组装一辆跑车，考验的是架构设计能力。
我在一个智能家居项目里遇到过这种情况：用 STM32F4 跑 LVGL，本来好好的，加了个圆角阴影效果后，帧率直接从 60fps 掉到 15fps。后来发现是内存带宽不够，每次渲染都要从 Flash 读大量数据。嗯，这就是典型的「资源受限」问题。
常见嵌入式 GUI 框架对比
目前市面上主流的嵌入式 GUI 框架有四个：LVGL、TouchGFX、emWin、Qt for MCU。我这些年都折腾过，说说我的感受。
| 框架 | 内存需求 | 渲染方式 | 开发语言 | 许可证 | 典型场景 |
|---|---|---|---|---|---|
| LVGL | 低（32KB+） | 软件渲染 | C | MIT | 智能家居、穿戴、工业控制 |
| TouchGFX | 中（128KB+） | 硬件加速 + 软件 | C++ | 免费（STM32 专用） | 高端消费电子、汽车仪表 |
| emWin | 低（16KB+） | 软件渲染 | C | 商业授权 | 医疗设备、工业 HMI |
| Qt for MCU | 高（512KB+） | QML 渲染引擎 | C++ / QML | 商业授权 | 高端 MCU、跨界处理器 |
LVGL：开源社区的宠儿
LVGL 是我个人用得最多的框架。它最大的优势是轻量和开源。MIT 许可证意味着你可以随便用，不用操心授权费。它的控件库很丰富，按钮、滑块、图表、键盘都有，而且支持样式定制。
我记得有个项目需要在 240×240 的圆形屏幕上做菜单，LVGL 的圆角裁剪和动画系统帮了大忙。不过要注意，LVGL 的默认渲染是单缓冲的，如果你要做复杂动画，最好自己实现双缓冲，否则会有撕裂感。
TouchGFX：STM32 的黄金搭档
TouchGFX 被 ST 收购后，和 STM32 的绑定越来越深。它的硬件加速能力很强，可以利用 STM32 的 Chrom-ART 和 LTDC 外设，实现非常流畅的动画效果。开发工具也很完善，有 TouchGFX Designer 可以拖拽设计界面。
但有个坑：它只免费支持 STM32 芯片。如果你用其他厂家的 MCU，就得买商业授权。我之前有个客户想用 NXP 的芯片跑 TouchGFX，最后发现授权费比芯片还贵，只好换方案。
emWin：老牌商业框架
emWin 是 SEGGER 公司的产品，在工业领域用了很多年。它的稳定性是出了名的，很多医疗设备、工业 HMI 都在用。内存占用极低，16KB RAM 就能跑起来，这在低端 MCU 上很有优势。
不过 emWin 的 API 设计比较老，用起来不如 LVGL 顺手。而且它是商业软件，需要付费。我建议如果你做的是大批量产品，且对成本敏感，可以考虑 emWin；如果是小批量或原型开发，LVGL 更合适。
Qt for MCU：跨界选手
Qt for MCU 是 Qt 公司针对 MCU 推出的版本。它最大的卖点是QML 开发，可以用声明式语言快速构建界面，开发效率很高。但代价是内存需求大，至少 512KB RAM，而且需要较强的 CPU 性能。
说实话，Qt for MCU 更适合那些从 Linux 平台迁移过来的团队。如果你之前用 Qt 做嵌入式 Linux 开发，转到 Qt for MCU 会很顺手。但如果你是从裸机或 RTOS 起步，学习曲线会有点陡。
我的建议：选框架时别只看功能，要看你的硬件资源、团队技术栈、产品生命周期。我个人习惯先评估 RAM 和 Flash 余量，再决定用哪个。如果资源紧张，LVGL 或 emWin 是稳妥的选择；如果追求视觉效果且用 STM32，TouchGFX 值得一试。
嵌入式 GUI 的核心架构：分层与驱动
不管用哪个框架，嵌入式 GUI 的架构都逃不开下面这张图。我画了个简化的分层结构，你看看就明白了。
你看，从下往上分别是硬件层、驱动抽象层、渲染层、框架层、应用层。每一层只关心自己的事，上层调用下层接口，下层向上层提供服务。这种分层设计的好处是：更换硬件或框架时，只需要改对应层，其他层基本不动。
举个例子，我在一个项目里从 ILI9341 屏幕换到 SSD1963 屏幕，只需要重写驱动抽象层的显示驱动，上层的应用代码一行没改。这就是分层架构的魅力。
避坑指南：我曾经在一个项目里把渲染逻辑和业务逻辑混在一起写，结果后期换框架时，整个界面代码几乎重写。后来我学乖了，强制分层，哪怕多写几层接口，也比后期重构强。
双缓冲：解决撕裂问题的关键
说到渲染层，就不得不提双缓冲。这是本课程的核心，也是很多嵌入式 GUI 工程师容易忽略的地方。
单缓冲模式下，CPU 直接在显存里画图，画完一帧就刷到屏幕上。但问题是，如果屏幕刷新和 CPU 绘图不同步，就会出现撕裂——屏幕上同时显示两帧的内容，看起来像画面被撕开了。
双缓冲的思路很简单：准备两个缓冲区，一个叫前台缓冲区（正在显示），一个叫后台缓冲区（正在绘制）。CPU 在后台缓冲区里画图，画完后交换两个缓冲区，前台变成后台，后台变成前台。这样用户看到的始终是完整的帧。
嗯，这里要注意：交换缓冲区不是简单的内存拷贝，而是通过修改显示控制器的帧缓冲地址来实现的。如果直接 memcpy，反而会引入额外的延迟。
后面的章节我会详细讲双缓冲的实现细节，包括如何适配不同的显示控制器、如何处理多缓冲、如何优化交换效率。这些都是我在实际项目中踩过的坑，希望能帮你少走弯路。