2. 嵌入式UI基础
嵌入式UI并不是“把桌面界面缩小”，它运行在资源受限、硬件差异大、实时性要求高的设备上。理解嵌入式UI，需要同时看四件事：资源约束、框架选型、显示与输入硬件、交互模式。这四者共同决定了界面能否流畅、稳定、可测试地运行。
一、嵌入式UI的核心特点
嵌入式UI的第一约束是资源。典型MCU可能只有几十KB到几MB RAM，Flash从几百KB到几十MB不等，CPU主频从几十MHz到几百MHz。界面刷新、动画、字体、图片解码都会直接消耗这些资源。因此，嵌入式UI设计强调按需绘制、局部刷新、资源复用和确定性响应。
第二约束是实时性。工业控制、汽车仪表、医疗设备等场景要求界面在固定时间内响应输入并完成刷新。如果UI线程阻塞，可能导致触摸无响应、动画卡顿，甚至影响控制逻辑。因此，嵌入式UI常采用事件驱动、双缓冲、DMA传输和分层渲染来降低延迟。
第三约束是硬件多样性。同一套UI代码可能运行在RGB LCD、MIPI DSI、SPI屏、I2C OLED等不同显示接口上，输入设备也可能是电阻触摸、电容触摸、按键、旋钮或编码器。UI框架必须提供硬件抽象层，否则移植成本会非常高。
核心结论：嵌入式UI的本质是在有限资源下，通过框架抽象硬件差异，用确定的刷新与输入机制，提供稳定、可交互、可测试的人机界面。
二、常见嵌入式UI框架对比
选型时不能只看“功能多不多”，而要看资源占用、渲染方式、硬件适配、开发效率、授权成本和可测试性。下表列出常见框架的典型特征：
| 框架 | 典型定位 | 资源占用 | 渲染特点 | 适用场景 |
|---|---|---|---|---|
| Qt / Qt for MCUs | 中高端嵌入式Linux或MCU | 较高到中等 | 场景图、硬件加速、控件丰富 | HMI、车载、医疗、工业面板 |
| LVGL | 轻量级MCU GUI库 | 低 | 对象树、局部刷新、C API | 智能家居、穿戴、小家电 |
| Embedded Wizard | 商业嵌入式GUI工具链 | 中等 | 可视化设计、代码生成、平台抽象 | 工业、汽车、消费电子 |
| TouchGFX | ST生态图形框架 | 中等 | MVP架构、部分硬件加速 | STM32带LCD产品 |
| emWin | 传统商业GUI库 | 低到中等 | 窗口/控件、稳定成熟 | 工业控制、仪器仪表 |
LVGL适合资源紧张、需要快速迭代的MCU项目；Qt适合复杂交互和Linux平台；Embedded Wizard和TouchGFX强调可视化设计与代码生成，适合产品化团队。选型时要特别关注：是否支持目标显示控制器、是否有触摸校准、是否支持多语言字体、是否便于自动化测试。
三、硬件与显示接口
显示接口决定了刷新带宽和CPU负载。常见接口包括：
- SPI/I2C屏：引脚少、成本低，但带宽有限，适合小尺寸、低刷新率界面，如OLED状态屏。
- 8080/6800并口：传统MCU屏接口，速度快于SPI，但占用引脚多。
- RGB LCD：需要LCD控制器和帧缓冲，适合中等分辨率，常用DMA刷新。
- MIPI DSI：高速串行接口，适合高分辨率移动与车载屏，通常需要SoC支持。
- LVDS/eDP：常见于工业与嵌入式Linux设备，支持较大尺寸和较高分辨率。
输入设备同样影响交互设计。电阻触摸需要ADC采样和校准，电容触摸通过I2C上报坐标，按键和编码器则产生GPIO中断或脉冲。UI框架通常提供输入设备抽象层，把原始事件转换为“按下、移动、释放、点击、长按”等语义事件。
四、输入设备与交互模式
嵌入式设备的交互模式与桌面差异很大。触摸屏适合点击、滑动、长按；按键适合菜单导航和确认取消；旋钮/编码器适合参数调节；语音和手势则用于特定场景。设计时要考虑误触、戴手套操作、强光环境、振动环境等实际因素。
一个常见的交互状态机如下：
IDLE → PRESSED → MOVING → RELEASED → CLICKED
↘ LONG_PRESS → REPEAT
↘ CANCELED
触摸采样 → 去抖 → 坐标校准 → 手势识别 → 事件分发 → 控件响应在自动化测试中，输入事件需要可注入、可回放。例如，通过模拟触摸坐标或按键事件，验证界面状态是否正确切换。如果UI框架没有提供事件注入接口，测试就会变得非常困难。
五、案例：智能温控器界面
某智能温控器采用LVGL + SPI LCD + 电阻触摸，MCU为Cortex-M4，RAM 128KB。界面包含温度显示、目标温度调节、模式切换和告警图标。开发中遇到两个问题：一是刷新整屏导致动画卡顿，二是触摸坐标漂移导致按钮误触。
解决方法是：使用LVGL局部刷新，只重绘温度数字和滑块区域；触摸驱动增加三点校准和滑动平均滤波；把UI刷新放在独立任务中，通过消息队列接收传感器数据。最终刷新率稳定在30fps，触摸响应小于50ms。
测试视角：该案例中，可自动化验证的点包括：温度变化后数字是否更新、模式切换后图标是否变化、触摸坐标注入后按钮是否触发、长时间运行后内存是否泄漏。
六、常见误区与复盘
- 误区一：直接移植桌面UI。桌面UI假设内存充足、刷新率高，移植到MCU后容易卡顿甚至崩溃。
- 误区二：忽视显示接口带宽。SPI屏刷大图会阻塞CPU，必须用DMA和分块传输。
- 误区三：触摸没有校准和滤波。电阻触摸易漂移，电容触摸易受噪声干扰，必须做去抖和校准。
- 误区四：UI逻辑与业务逻辑耦合。导致无法单独测试界面，也无法复用业务代码。
- 误区五：没有考虑自动化测试接口。输入事件和界面状态无法注入与读取，持续集成难以落地。
复盘建议：在项目初期就确定UI框架、显示接口、输入设备和测试接口。把UI拆分为“状态、渲染、输入、通信”四部分，分别提供可测试的边界。这样后续接入持续集成时，才能用自动化脚本稳定地验证界面行为。
嵌入式UI基础决定了后续自动化测试的可行性和成本。理解资源约束、框架差异、硬件接口和交互模式，才能在持续集成中设计出稳定、可重复、可维护的UI测试方案。