2. 嵌入式GUI基础
做嵌入式GUI优化，第一件事就是搞清楚——你的画面到底是怎么跑到屏幕上的？
我见过太多人一卡顿就怀疑CPU太弱，结果查了半天，瓶颈在GPU驱动没喂饱。说白了，你得先看懂整条渲染管线，才能知道该从哪里下刀。
渲染管线的四个阶段
我把嵌入式GUI的渲染链路分成四个阶段。你想想看，从你写下一行lv_label_set_text()，到像素真正亮起来，中间经历了什么？
| 阶段 | 负责方 | 主要工作 | 典型耗时占比 |
|---|---|---|---|
| 应用层 | CPU | 事件处理、状态更新、布局计算 | 5% - 15% |
| 图形引擎层 | CPU | 绘制命令生成、裁剪、脏矩形合并 | 10% - 25% |
| 渲染后端层 | CPU + GPU | 像素填充、纹理合成、混合 | 40% - 60% |
| 显示驱动层 | DMA + 显示控制器 | 帧缓冲传输、时序控制、刷新 | 10% - 20% |
嗯，这里要注意——不同阶段的耗时占比会随着硬件和场景剧烈变化。我做过一个项目，用STM32F4跑LVGL，结果渲染后端占了70%以上的时间，因为根本没有GPU，全靠CPU逐像素画。
应用层：事件与状态
这一层是GUI框架的入口。用户触摸屏幕、定时器触发、传感器数据变化……所有这些事件都会在这里被消化。
我个人习惯先看这一层有没有「无效更新」。举个例子：
// 糟糕的做法：每次定时器都重绘
void timer_cb(lv_timer_t *t) {
lv_label_set_text(label, get_sensor_value());
// 即使数值没变，也会触发重绘
}
// 好的做法：先判断再更新
void timer_cb(lv_timer_t *t) {
static char last_val[16];
char cur_val[16];
get_sensor_value(cur_val);
if (strcmp(last_val, cur_val) != 0) {
lv_label_set_text(label, cur_val);
strcpy(last_val, cur_val);
}
}
我曾经在一个智能家居面板上遇到过——每秒刷新30次温湿度，但数值根本没变。去掉这些无效更新后，CPU占用直接降了40%。
图形引擎层：命令生成与裁剪
这一层是GUI框架的核心。它把「我想画一个蓝色圆角矩形」翻译成一系列绘制命令。
关键点在于裁剪和脏矩形。你想想看，如果整个屏幕有100个控件，但只有1个按钮改变了状态，难道要把全屏都重绘一遍？
脏矩形机制：GUI引擎只重绘状态发生变化的区域。LVGL、TouchGFX、emWin都支持这个机制。但要注意——如果脏矩形合并策略太激进，反而会把多个小区域合并成一个大区域，导致不必要的重绘。
我建议你在调试时打开GUI框架的「显示脏矩形」功能。LVGL里是lv_disp_drv_t->direct_mode = 0配合lv_conf.h里的LV_USE_PERF_MONITOR。看到屏幕上闪烁的方框了吗？那就是每次实际重绘的区域。
渲染后端层：CPU与GPU的分工
这里是最容易出问题的地方，也是CPU和GPU真正「干活」的阶段。
CPU负责什么
- 像素格式转换（ARGB8888 → RGB565）
- 字体渲染（尤其是FreeType的矢量字库）
- 复杂路径裁剪（比如异形窗口）
- 软件混合（alpha blending）
GPU负责什么
- 批量像素填充（fill）
- 图像缩放与旋转（blit + transform）
- 硬件加速的混合操作
- 帧缓冲切换（double/triple buffer）
常见误区：很多人以为GPU一定比CPU快。其实不是。GPU有启动延迟（几十微秒），如果只是画一个小图标，CPU直接写像素反而更快。我见过一个项目，把每个小按钮的绘制都丢给GPU，结果性能反而下降了——因为GPU的启动开销比绘制本身还大。
怎么判断该用CPU还是GPU？我有个经验法则：
- 面积小于32×32像素的简单图形 → CPU直接画
- 大面积纯色填充 → GPU fill
- 带透明度的图像叠加 → GPU blit + blend
- 文字渲染 → CPU（除非GPU支持矢量加速）
显示驱动层：最后一公里
渲染完成后，像素数据在帧缓冲里。但要让屏幕显示出来，还得通过显示控制器和物理接口。
这一层的瓶颈通常不在计算，而在带宽。举个例子：
// 假设屏幕分辨率 480×272，颜色深度 RGB565
// 一帧数据量 = 480 × 272 × 2 = 261,120 字节
// 60fps 时需要的带宽 = 261,120 × 60 ≈ 15.7 MB/s
// 如果使用 SPI 接口，最大速度 40MHz
// SPI 理论带宽 = 40 / 8 = 5 MB/s
// 实际可用带宽（考虑协议开销）≈ 3.5 MB/s
// 15.7 > 3.5 → 瓶颈在显示驱动层！
我曾经在一个产品上踩过这个坑。屏幕分辨率不高，但用了SPI接口，刷新率死活上不去。后来换成8位并口，带宽翻了三倍，问题就解决了。
CPU与GPU的分工边界
这张图是我自己总结的，帮你快速定位瓶颈在哪一端：
如何定位渲染管线中的瓶颈
知道了管线长什么样，接下来就是怎么找到卡点。我一般按这个顺序排查：
- 先看帧率——用GUI框架自带的性能监视器，看实际FPS是否达标
- 再看每帧耗时分布——用
lv_disp_drv_t->monitor_cb或类似回调，统计各阶段耗时 - 然后看脏矩形数量——如果每帧的脏矩形数量超过控件总数的30%，说明事件处理层有问题
- 最后看带宽——计算帧缓冲数据量，对比显示接口的实际带宽
实用技巧：在LVGL中，你可以用lv_disp_drv_t->flush_cb里加一个GPIO翻转，然后用示波器看波形。高电平持续时间就是渲染后端+显示驱动的耗时。这个方法我在好几个项目里用过，比任何软件profiler都直观。
一个真实案例
去年我做了一个智能手表项目，屏幕是圆形LCD，分辨率240×240，用STM32U5 + 内部GPU。刚开始帧率只有12fps，卡得不行。
我按上面的方法排查：
- 帧率监视器显示12fps，目标30fps
- 每帧耗时分布：应用层3ms，图形引擎层8ms，渲染后端层55ms，显示驱动层12ms
- 问题很明显——渲染后端层占了55ms
- 进一步分析发现，圆形屏幕需要大量裁剪操作，每次裁剪都触发了CPU的软件路径
解决方案：把圆形裁剪改为「先画一个矩形，再用GPU的stencil buffer做圆形遮罩」。修改后渲染后端层降到18ms，帧率提升到28fps。
你看，找到瓶颈在哪一层，问题就解决了一半。