2. 嵌入式GUI基础
在嵌入式设备上做GUI选型，第一步不是比较LVGL、Qt还是emWin，而是先看清一个GUI系统到底由哪些部分构成。只有把系统组成、显示与输入子系统、渲染管线、事件循环以及嵌入式约束这五件事拆开理解，才能判断某个框架是否适配你的硬件与产品形态。本节从工程视角建立这套基础模型。
一、GUI系统的五层组成
一个完整的嵌入式GUI系统，可以抽象为五个协作层：
- 应用层：页面、控件、业务逻辑，决定“显示什么、响应什么”。
- 控件与布局层：按钮、列表、标签等控件，以及坐标、对齐、层级管理。
- 渲染层：把控件树转换为像素，包括绘制、裁剪、合成、字体与图片解码。
- 显示与输入子系统：对接LCD/OLED、触摸屏、按键、编码器，完成帧缓冲刷新与事件采集。
- 驱动与硬件层：SPI/I2C/RGB/MIPI接口、DMA、GPU、显存与中断。
选型时常见的误区，是只盯着“控件多不多、界面漂不漂亮”，却忽略了渲染层与显示子系统的匹配度。例如一个支持丰富动画的框架，如果运行在没有GPU、只有单缓冲SPI屏的MCU上，实际帧率可能远低于预期。
二、显示子系统与输入子系统
显示子系统的核心是“像素如何从内存到达屏幕”。典型链路为：显存（Frame Buffer）→ 显示控制器 → 接口（SPI/RGB/MIPI-DSI）→ 面板。关键参数包括分辨率、色深（RGB565/RGB888）、刷新率、缓冲策略（单缓冲/双缓冲/三缓冲）以及是否支持局部刷新。
输入子系统则负责把物理动作转为GUI事件：触摸屏经I2C/SPI上报坐标，按键经GPIO中断产生键值，编码器产生增量。输入子系统通常需要做去抖、坐标校准、手势识别和事件队列化，再交给事件循环统一分发。
三、渲染管线：从控件树到像素
渲染管线描述一帧画面如何生成。典型流程为：
- 应用修改控件属性，标记脏区域（Dirty Region）。
- 布局引擎重新计算受影响控件的位置与尺寸。
- 绘制引擎按层级顺序绘制背景、控件、文字、图片。
- 裁剪与合成，处理透明、圆角、阴影等效果。
- 将结果写入显存，由显示控制器刷新到面板。
嵌入式渲染的关键优化点是“少画”。局部刷新只重绘脏区域，能显著降低SPI带宽与CPU占用。下面是一段典型的局部刷新伪代码：
// 标记脏区域
gui_invalidate_rect(&btn_rect);
// 事件循环中统一处理
while (1) {
gui_task_handler(); // 处理输入与定时器
if (gui_has_dirty()) {
gui_render_dirty(); // 只重绘脏区域
lcd_flush_region(); // 刷新到面板
}
os_delay(5);
}四、事件循环：GUI的“心跳”
事件循环是GUI系统的调度中心，负责把输入事件、定时器事件、系统事件分发给对应控件。常见模型有两种：
- 主循环轮询模型：裸机或RTOS任务中循环调用，结构简单，适合资源受限设备。
- 事件驱动模型：由消息队列和回调驱动，响应更及时，但需要处理线程安全与优先级。
无论哪种模型，都要保证“输入采集—事件分发—界面更新—屏幕刷新”形成闭环。若事件循环被长时间阻塞，界面就会卡顿甚至无响应。
五、嵌入式约束：选型的真正边界
嵌入式GUI与桌面GUI最大的区别，是资源与实时性约束。下表列出选型时必须核对的约束项：
| 约束维度 | 典型问题 | 选型关注点 |
|---|---|---|
| RAM/Flash | 显存与控件库占用过大 | 是否支持RGB565、局部刷新、按需裁剪 |
| CPU主频 | 动画与文字渲染慢 | 是否有硬件加速、DMA2D、GPU |
| 显示接口 | SPI带宽不足导致撕裂 | 是否支持双缓冲、TE同步 |
| 实时性 | 触摸响应延迟高 | 事件循环是否可抢占、中断优先级 |
| 功耗 | 持续刷新耗电 | 是否支持休眠、按需刷新 |
六、案例与复盘：一次“点不中”的排查
某项目使用SPI屏+电阻触摸，界面能显示但点击偏移。排查发现：显示子系统做了90°旋转，而输入子系统未同步旋转矩阵，导致坐标映射错位。修复方式是在输入层统一应用与显示一致的变换矩阵。这个案例说明：GUI系统组成中，显示与输入必须共享同一套坐标与变换约定。
把这张系统图记牢，后续比较不同GUI框架时，就能逐层对照：它的渲染管线是否支持局部刷新，事件循环是否可集成到RTOS任务，显示与输入是否共享坐标变换，以及在你的RAM和带宽预算下能否稳定运行。这才是嵌入式GUI选型的工程起点。