1、GUI性能瓶颈分析：帧率与刷新率、CPU/GPU负载、内存带宽与总线延迟
做嵌入式GUI优化，第一步不是动手改代码，而是搞清楚——你的系统到底慢在哪。
我见过太多团队，上来就怼着渲染算法优化，结果发现瓶颈在内存带宽上。白忙一场。所以这一章，咱们先把性能分析的几个核心概念掰扯清楚。
1.1 帧率(FPS)与刷新率：别搞混了
先说两个最容易被混淆的概念。
- 帧率(FPS)：你的GUI应用实际每秒能绘制多少帧。这是软件能力。
- 刷新率(Hz)：显示屏硬件每秒刷新多少次画面。这是硬件能力。
举个例子。屏幕是60Hz，你的GUI跑到了30FPS。那用户看到的就是每两帧才刷新一次，卡顿感明显。反过来，如果你的GUI跑到了120FPS，但屏幕只有60Hz——多出来的60帧全浪费了，还白费CPU/GPU算力。
核心原则：帧率与刷新率需要匹配。通常建议FPS略高于刷新率（比如60Hz屏幕跑65FPS），留一点余量防止掉帧。但不要高出太多。
我个人习惯在项目初期就固定好目标帧率。比如屏幕60Hz，我就锁55-60FPS。这样CPU/GPU负载可控，功耗也稳。
| 指标 | 定义 | 典型值 | 瓶颈方向 |
|---|---|---|---|
| 帧率(FPS) | 应用每秒渲染帧数 | 30 / 60 / 120 | CPU/GPU算力 |
| 刷新率(Hz) | 屏幕每秒刷新次数 | 60 / 90 / 120 | 显示面板+驱动 |
注意：不要盲目追求高FPS。在嵌入式平台上，每多一帧，CPU和GPU就多一份负载。我曾经在一个Cortex-M7项目上把FPS从30提到60，结果CPU占用率从40%飙到85%，触摸响应直接变慢。得不偿失。
1.2 CPU/GPU负载模型：谁在干活？
GUI渲染这件事，CPU和GPU分工不同。
- CPU：负责逻辑处理——事件分发、布局计算、绘制命令生成、纹理上传。
- GPU：负责像素填充——光栅化、片段着色、混合、帧缓冲输出。
说白了，CPU是项目经理，GPU是施工队。项目经理把活拆成任务单（绘制命令），施工队照着单子刷墙（像素填充）。
那瓶颈怎么判断？
我一般看两个指标：
- CPU占用率：如果CPU在渲染阶段持续>70%，说明逻辑处理或绘制命令生成是瓶颈。
- GPU负载：如果GPU的像素填充率接近极限，或者帧缓冲交换延迟高，说明GPU是瓶颈。
这里有个常见的坑——CPU和GPU串行等待。CPU提交完绘制命令后，如果GPU还没处理完上一帧，CPU就得干等。这叫CPU stall。我在一个HMI项目里遇到过，CPU占用率只有30%，但FPS就是上不去。一查，CPU在等GPU释放缓冲区。后来改成双缓冲+异步提交，FPS直接翻倍。
小技巧：用性能分析工具（如perf、ftrace、GPU profiling工具）看CPU和GPU的时间线。如果CPU和GPU的空闲时间段重叠，说明有等待。重叠越多，优化空间越大。
1.3 内存带宽瓶颈：看不见的墙
嵌入式系统里，内存带宽往往是最大的隐形杀手。
你想想看，一个1080p的RGBA8888帧缓冲，一帧就是1920×1080×4 ≈ 8.3MB。如果跑60FPS，每秒需要从内存搬运8.3MB×60 ≈ 500MB的数据。这还只是帧缓冲本身。再加上纹理、字体缓存、图层混合……带宽需求轻松上GB/s。
而嵌入式平台的内存带宽通常是多少？
- 低端MCU（如Cortex-M4）：几十MB/s
- 中端MPU（如Cortex-A7 + DDR3）：1-4 GB/s
- 高端SoC（如Cortex-A72 + LPDDR4）：10-20 GB/s
一旦带宽不够，后果就是帧缓冲写入延迟、纹理加载卡顿、图层混合变慢。
我记得有个项目，用STM32MP157做GUI，分辨率1280x720，跑LVGL。一开始FPS只有20。查了半天，发现是DMA2D（硬件2D加速器）和CPU争抢AXI总线带宽。后来把DMA2D的优先级调高，并启用双缓冲，FPS提到了45。
| 分辨率 | 色深 | 单帧大小 | 60FPS带宽需求 | 常见瓶颈平台 |
|---|---|---|---|---|
| 480×272 | RGB565 | ~260KB | ~15.6MB/s | 低端MCU |
| 800×480 | RGBA8888 | ~1.5MB | ~90MB/s | 中端MPU |
| 1920×1080 | RGBA8888 | ~8.3MB | ~500MB/s | 高端SoC |
避坑指南：我曾经在项目里用了大量半透明图层叠加，每个图层都要做alpha blending。结果内存带宽被吃光，FPS直接掉到个位数。后来改用预乘alpha + 硬件混合，才救回来。记住——图层越少，带宽压力越小。
1.4 总线延迟分析：数据在路上堵车
内存带宽是“路有多宽”，总线延迟是“路上有多少红绿灯”。
嵌入式系统里，CPU、GPU、DMA、显示控制器都挂在总线上（如AXI、AHB、OCP）。它们共享总线带宽。如果多个主设备同时访问内存，总线仲裁就会引入延迟。
典型场景：
- CPU正在从DDR读取纹理数据
- GPU正在写入帧缓冲
- DMA正在搬运字体位图
- 显示控制器正在从帧缓冲读取像素刷新屏幕
这四个设备同时抢总线，谁等谁？
总线仲裁策略通常是优先级+轮询。显示控制器一般优先级最高（因为不能断帧），CPU次之，DMA和GPU靠后。但具体要看芯片设计。
我遇到过一个问题：在某全志SoC上，GUI偶尔出现水平撕裂。查了很久，发现是显示控制器读取帧缓冲时，CPU刚好在写同一块区域。总线仲裁没处理好，导致显示控制器读到了半帧数据。解决方案是把帧缓冲放在独立的内存区域，并启用双缓冲+VSync同步。
建议：在项目初期，就用总线跟踪工具（如Tarmac、Bus tracer）看一下各主设备的总线占用率和延迟。如果某个设备的总线延迟超过10us，就要考虑优化了。
1.5 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作后续优化的地图。
这张图把四个瓶颈、对应的关键指标、以及优化方向串在了一起。后续章节，我们会逐一深入每个方向的具体优化手段。
嗯，这一章的内容就到这。记住——先诊断，再开药。别急着改代码，先搞清楚瓶颈在哪。