1. GUI 性能瓶颈分析：帧率、刷新率与负载模型
做嵌入式 GUI 优化，第一件事就是搞清楚——你的画面到底卡在哪？
我见过不少团队，一上来就怼着渲染引擎改代码，结果发现瓶颈根本不在渲染，而在布局计算。所以这一章，我们先打好基础，把帧率、刷新率、CPU/GPU 负载模型这些概念理清楚。说白了，就是先学会“诊断”，再谈“治疗”。
1.1 帧率（FPS）与刷新率：别再傻傻分不清
这两个概念，我每次面试新人都会问。能讲清楚的人，真不多。
帧率（FPS），是 GPU 每秒能绘制多少帧画面。它取决于你的硬件算力和软件效率。
刷新率（Hz），是屏幕每秒能刷新多少次。它由显示面板的物理特性决定。
你想想看，如果 FPS 只有 30，但屏幕刷新率是 60Hz，那每两帧之间屏幕会重复显示同一帧——这叫“帧重复”。反过来，如果 FPS 是 60，屏幕只有 30Hz，那有一半的帧会被丢弃——这叫“帧丢失”。
核心原则：FPS 必须与刷新率匹配，或者至少是刷新率的整数分之一。否则，画面就会出现撕裂或卡顿。
| 场景 | FPS | 刷新率 | 现象 | 用户体验 |
|---|---|---|---|---|
| 理想匹配 | 60 | 60Hz | 流畅 | 优秀 |
| FPS 不足 | 30 | 60Hz | 帧重复 | 轻微卡顿 |
| FPS 过高 | 90 | 60Hz | 帧丢失/撕裂 | 画面撕裂 |
| 两者都低 | 15 | 30Hz | 明显卡顿 | 不可接受 |
我的经验：在 STM32 这类 MCU 上做 GUI，我习惯把目标 FPS 定在 30。因为 60FPS 对 CPU 和内存带宽的压力太大，而 30FPS 配合 60Hz 屏幕，通过双缓冲机制，人眼基本感觉不到卡顿。
1.2 CPU/GPU 负载模型：谁在拖后腿？
嵌入式 GUI 的渲染流水线，其实就两个角色：CPU 和 GPU。
CPU 负责：事件处理、布局计算、绘制指令生成、内存管理。
GPU 负责：像素填充、纹理映射、混合、抗锯齿。
我遇到过最典型的场景：一个复杂的仪表盘界面，CPU 花 15ms 算布局，GPU 花 5ms 渲染。总耗时 20ms，刚好卡在 50FPS。你优化 GPU 渲染？没用。瓶颈在 CPU 的布局计算上。
反过来，如果 CPU 只花 2ms，但 GPU 要 18ms 去填充一个高分辨率背景图，那瓶颈就在 GPU。
负载模型公式：
单帧耗时 = max(CPU 耗时, GPU 耗时) + 同步开销
最大 FPS = 1000ms / 单帧耗时
举个例子：
// 伪代码：帧耗时分析
uint32_t cpu_time = 12; // ms
uint32_t gpu_time = 8; // ms
uint32_t sync_time = 2; // ms
uint32_t frame_time = max(cpu_time, gpu_time) + sync_time;
// frame_time = 12 + 2 = 14ms
// 最大 FPS = 1000 / 14 ≈ 71 FPS
// 如果优化 CPU 到 6ms
frame_time = max(6, 8) + 2 = 10ms
// 最大 FPS = 100 FPS
注意：千万不要只优化一个方向。我曾经在一个项目里，把 GPU 渲染从 10ms 优化到 3ms，结果 FPS 一点没变。后来才发现 CPU 布局花了 15ms，GPU 再快也没用。这就是典型的“木桶效应”。
1.3 常见的三大性能瓶颈
根据我的经验，嵌入式 GUI 的性能瓶颈，90% 都逃不出这三个坑：
1.3.1 渲染瓶颈
渲染瓶颈，说白了就是 GPU 忙不过来。
- 过度绘制：同一个像素被画了多次。比如一个半透明弹窗盖在背景上，GPU 要算两次颜色混合。
- 大纹理加载：一张 1024x768 的 PNG 背景图，解码后占 3MB 内存，每次刷新都要重新上传到 GPU。
- 无效重绘：整个屏幕全部重绘，哪怕只有一个像素变了。
我的习惯：在 LVGL 或 TouchGFX 里，我通常会开启“脏矩形”机制。只重绘变化的那一小块区域，而不是全屏刷新。这个优化，往往能把 FPS 从 20 拉到 50。
1.3.2 布局瓶颈
这个坑，新手最容易踩。
布局计算是 CPU 干的活。如果你的界面有 100 个控件，每个控件都要计算位置、大小、对齐方式，CPU 很容易就撑不住了。
- 嵌套布局：5 层以上的容器嵌套，每次布局变化都要递归计算。
- 动态布局：每次数据更新都重新计算所有控件的位置。
- 文本重排：中文字体换行计算，比英文字母慢 3-5 倍。
我曾经踩过的坑：做一个智能家居控制面板，用了 8 层 Flexbox 布局。每次切换页面，CPU 要花 40ms 算布局，FPS 直接掉到 20。后来我把布局拍平到 3 层，FPS 回到了 55。记住：布局深度越浅越好。
1.3.3 内存拷贝瓶颈
这个最隐蔽，也最致命。
嵌入式系统里，内存带宽是稀缺资源。一次 800x480 的全屏帧缓冲拷贝，就要拷贝 1.5MB 数据（32位色深）。如果 FPS 是 60，每秒要拷贝 90MB 数据。很多 MCU 的 DMA 带宽根本扛不住。
| 分辨率 | 色深 | 单帧大小 | 60FPS 带宽需求 |
|---|---|---|---|
| 320x240 | 16位 | 150KB | 9MB/s |
| 480x272 | 16位 | 255KB | 15MB/s |
| 800x480 | 32位 | 1.5MB | 90MB/s |
| 1024x600 | 32位 | 2.4MB | 144MB/s |
优化思路：
- 用 DMA2D 硬件加速拷贝，别用 CPU 逐像素搬。
- 用双缓冲 + 交换指针，避免整帧拷贝。
- 用局部刷新，只拷贝脏矩形区域。
1.4 知识体系总览
下面这张图，把本章的核心逻辑串起来了。我建议你保存下来，后面每章都会用到。
嗯，这张图基本把本章的骨架讲清楚了。从帧率刷新率的基础概念，到 CPU/GPU 谁在拖后腿，再到三个具体的瓶颈方向——渲染、布局、内存拷贝。后面每一章，都会围绕这张图里的某个节点展开。
我个人建议，你在开始优化之前，先把这张图打印出来贴在工位上。每次遇到性能问题，就对着图走一遍诊断流程。你会发现，90% 的问题都能在 5 分钟内定位到根因。