1、嵌入式GUI概述：什么是嵌入式GUI、常见嵌入式GUI框架对比、资源受限环境下的挑战
大家好，我是你们这门课的老朋友。咱们今天聊嵌入式GUI，说白了就是给那些小屏幕、小内存的嵌入式设备穿上漂亮衣服。
我刚开始做嵌入式开发那会儿，设备上能有个128×64的单色点阵屏就算不错了。显示个菜单全靠自己画像素点，一个按钮按下去，整个屏幕闪一下。现在不一样了，动不动就是RGB565、TFT彩屏，甚至还有触摸交互。但问题也来了——资源就那么点，怎么让GUI跑得流畅又好看？
1.1 什么是嵌入式GUI
嵌入式GUI，全称是Graphical User Interface，就是图形用户界面。它运行在微控制器（MCU）或嵌入式处理器上，负责把数据、状态、控制选项用图形的方式展示给用户。
你想想看，一个智能手表、一个洗衣机控制面板、一个医疗监护仪，它们背后都跑着一套嵌入式GUI。跟PC上的Qt或Windows不一样，嵌入式GUI的舞台很小——可能只有几兆字节的Flash，几百KB的RAM，甚至更少。
核心区别：嵌入式GUI不是把PC那套搬过来，而是要在资源受限的环境下，用最少的开销实现最必要的交互。
1.2 常见嵌入式GUI框架对比
市面上主流的嵌入式GUI框架就那么几个。我这些年基本都碰过，踩过坑也填过坑。咱们一个一个看。
| 框架 | 开发商 | 语言 | 最低RAM | 最低Flash | 许可证 |
|---|---|---|---|---|---|
| LVGL | 开源社区 | C | ~16 KB | ~64 KB | MIT |
| TouchGFX | ST（原Draupner） | C++ | ~32 KB | ~128 KB | 免费（ST芯片） |
| emWin | SEGGER | C | ~8 KB | ~32 KB | 商业 |
| Qt for MCU | The Qt Company | C++/QML | ~128 KB | ~512 KB | 商业 |
嗯，这里要注意，上面的数字只是跑个Hello World级别的demo。真要上产品，资源消耗至少翻倍。
LVGL
我个人最喜欢LVGL。开源、MIT协议、社区活跃。它用纯C写的，移植性极强。我在一个STM32F103C8T6（72MHz、20KB RAM、64KB Flash）上跑过LVGL 7，虽然帧率不高，但确实能跑起来。
它的控件丰富，按钮、滑块、图表、键盘都有。而且支持样式系统，可以自定义主题。如果你团队里没有专职UI设计师，LVGL的默认风格已经够用了。
我的经验：LVGL的帧缓冲可以只开一行（单缓冲），配合DMA传输，能省下大量RAM。我在一个只有8KB RAM的项目里就是这么干的。
TouchGFX
TouchGFX是ST主推的框架，C++写的。它的强项是动画和流畅度。我记得有一次帮客户做智能家居面板，用TouchGFX做了个滑动翻页效果，丝滑得像手机一样。
但代价也很明显——它吃资源。最低建议32KB RAM起步，而且最好有硬件加速（比如ST的Chrom-ART）。另外，它跟ST芯片绑定得比较紧，换平台就得重新适配。
避坑指南：我曾经在一个项目里用TouchGFX做复杂图表，结果发现它的TextArea控件在大量刷新时会内存泄漏。后来只能自己写了个精简版。所以，用TouchGFX之前，一定要做长时间压力测试。
emWin
emWin是老牌商业GUI，SEGGER出品。它的最大优势是资源占用极低——8KB RAM就能跑。我见过很多工业控制设备、医疗仪器都在用emWin。
它的API风格比较传统，有点像Windows的GDI。没有那么多花哨的动画，但胜在稳定。如果你做的是那种“显示几个数字、几个按钮”的界面，emWin是性价比最高的选择。
Qt for MCU
Qt for MCU是后来者。它把Qt的QML/JS带到了MCU世界。开发效率高，UI设计灵活。但资源开销也是最大的——128KB RAM、512KB Flash只是起步价。
我建议，除非你的MCU有1MB以上的Flash和256KB以上的RAM，否则别轻易碰Qt for MCU。它更适合高端MCU或MPU。
1.3 资源受限环境下的挑战
好，框架看完了。咱们聊聊真正的痛点——资源受限。
嵌入式GUI的敌人有三个：内存、CPU、存储。我一个个说。
内存（RAM）
GUI最吃RAM的地方是帧缓冲（Frame Buffer）。一个320×240的16位色屏幕，帧缓冲就要320×240×2 = 153,600字节，也就是150KB。很多MCU总共才64KB RAM，你连一个帧缓冲都放不下。
怎么办？
- 分段刷新：只更新变化区域，不刷新全屏。
- 行缓冲：一次只缓冲一行或几行数据，配合DMA逐行发送。
- 压缩帧缓冲：用RLE或LZ4压缩，解压后写入显存。
关键思路：不要试图在RAM里保留完整的UI状态。能用Flash存的就别放RAM，能实时计算的就别缓存。
CPU性能
MCU的主频通常只有几十到几百MHz。画一个圆角矩形，如果用软件逐像素绘制，可能要消耗几毫秒。如果界面频繁刷新，CPU就全耗在渲染上了，业务逻辑就卡死了。
我的建议：
- 尽量用硬件加速（如DMA2D、Chrom-ART）。
- 减少重绘区域，用脏矩形算法。
- 图片用预渲染的位图，别在运行时画复杂图形。
存储（Flash）
Flash用来存代码、字库、图片。一张全屏的320×240 16位色图片，不压缩要150KB。如果界面有10张这样的图片，1.5MB Flash就没了。而很多MCU的Flash总共才512KB。
压缩手段：
- 图片用JPEG或PNG压缩，运行时解压。
- 字库只包含用到的字符，别全量加载。
- UI资源放在外部Flash（如SPI Flash），按需加载。
你看，这三个挑战是相互关联的。RAM不够，你就得把数据放Flash；Flash不够，你就得压缩；压缩了，CPU解压又费时间。这就是嵌入式GUI设计的核心矛盾。
我的习惯：每次开始一个新项目，我会先画一个资源预算表。RAM多少、Flash多少、CPU余量多少，然后倒推能用什么框架、什么压缩策略。别等代码写完了才发现资源不够，那时候改起来就痛苦了。