1. 性能优化全景图：TouchGFX渲染管线剖析、性能瓶颈定位方法论、优化前后对比案例
各位做嵌入式UI的同行，大家好。我是老张，在嵌入式图形领域摸爬滚打了十来年。今天咱们开始《TouchGFX性能优化实战》的第一章。
说实话，很多工程师拿到TouchGFX，第一反应是“这框架真漂亮，动画真流畅”。但一旦把项目塞进资源紧张的MCU里，问题就来了——掉帧、卡顿、内存爆掉。我见过太多团队，花了两周做界面，又花了一个月调性能。
为什么会这样？
因为你不了解渲染管线。你不知道每一帧从哪来、到哪去、在哪卡住。今天我就带你把这根管子拆开，看清楚。
1.1 TouchGFX渲染管线：一帧画面的诞生
先看一张图，这是我手绘的渲染管线全景。你盯着它看三分钟，后面讲的所有优化点都能找到位置。
这张图我建议你截图保存。后面每一章讲的具体优化技巧，你都能在这张图上找到对应的位置。
1.2 每个阶段在干什么？
咱们一个一个说。
阶段1：应用逻辑。说白了就是你的Model和Presenter在干活。数据从传感器来了，或者用户点了个按钮，状态变了。这个阶段如果太慢，通常是你业务逻辑写得重了，跟TouchGFX关系不大。
阶段2：UI树遍历。嗯，这里要注意。TouchGFX会遍历整个UI树，找出哪些区域需要重绘。它用的是脏矩形机制——只有标记为“脏”的区域才会被重绘。但如果你整个屏幕都脏了，那跟全屏重绘没区别。
我记得有个项目，客户说“我就放了个背景图，为什么CPU占用这么高？”我一看代码，他把背景图放在了一个Container里，每次更新数据都调用了invalidate()。整个屏幕都红了，能不卡吗？
阶段3：绘制调用。每个Widget的draw()方法被调用，生成绘制指令。这里最耗时的操作是什么？纹理混合、字体渲染、形状绘制。尤其是带透明度的图片叠加，CPU得逐像素算。
阶段4：帧缓冲合成。把绘制指令写入帧缓冲。如果你的MCU有DMA2D（Chrom-ART加速器），这一步可以卸载到硬件。没有？那CPU就得自己搬砖。
阶段5：LTDC传输。LTDC控制器从帧缓冲读数据，通过RGB接口或MIPI DSI发给屏幕。这一步是硬件自动的，基本不占CPU。但帧缓冲的位宽和时钟频率会影响刷新率。
阶段6：显示。LCD面板本身有响应时间。这个一般不是瓶颈，除非你用了特别慢的屏幕。
核心观点： 性能优化的本质，就是让每个阶段的工作量最小化，并且把能卸载的工作卸载到硬件上。
1.3 性能瓶颈定位方法论
光知道管线还不够，你得知道怎么找瓶颈。我总结了一套“三步定位法”，用了好几年，挺管用的。
第一步：看帧率
TouchGFX提供了HAL::getFrameRate()，你可以把帧率打印出来。目标帧率一般是30fps或60fps。如果低于目标，说明有问题。
// 在main.cpp或你的Screen中
uint32_t fps = HAL::getInstance()->getFrameRate();
printf("Current FPS: %lu\n", fps);但帧率低只能告诉你“有问题”，不能告诉你“问题在哪”。所以需要第二步。
第二步：看CPU占用分布
用MCU的定时器或者RTOS的任务统计功能，测量每个阶段的耗时。我个人习惯在以下位置打时间戳：
- T1：进入tick()之前（应用逻辑开始）
- T2：进入draw()之前（UI树遍历开始）
- T3：draw()返回之后（绘制完成）
- T4：帧缓冲交换完成（合成结束）
然后算差值：
| 阶段 | 计算公式 | 典型耗时（@60fps） | 危险信号 |
|---|---|---|---|
| 应用逻辑 | T2 - T1 | < 1ms | > 3ms |
| UI树遍历+绘制 | T3 - T2 | < 8ms | > 12ms |
| 帧缓冲合成 | T4 - T3 | < 2ms | > 5ms |
我曾经遇到一个项目，UI树遍历+绘制耗时15ms，60fps的周期是16.7ms，剩下1.7ms给其他阶段，根本不够。后来发现是一个自定义Widget的draw()里做了大量浮点运算。改成查表法后，直接降到4ms。
第三步：看具体Widget的绘制开销
TouchGFX的Profiler可以帮你。在TouchGFX Designer里启用Profiler，或者在代码里手动加：
// 在draw()方法中手动测量
uint32_t start = HAL::getInstance()->getCPUCycleCounter();
// 绘制代码...
uint32_t elapsed = HAL::getInstance()->getCPUCycleCounter() - start;
printf("Widget draw cycles: %lu\n", elapsed);这样你就能知道哪个Widget是“耗电大户”。
避坑指南： 我曾经在调试时发现某个TextArea的绘制耗时异常高。查了半天，发现是字体缓存没开，每次绘制都要重新解析矢量字体。开了字体缓存后，耗时从2ms降到0.1ms。所以，字体缓存一定要开。
1.4 优化前后对比案例
光说不练假把式。我拿一个真实项目来演示。
项目背景： 某工业手持终端，STM32H743 + 480x272 RGB屏，TouchGFX 4.18。界面包含实时波形图、数值显示、菜单栏。客户反馈：操作卡顿，帧率只有20fps。
优化前状态：
| 指标 | 数值 |
|---|---|
| 平均帧率 | 21 fps |
| UI树遍历+绘制耗时 | 14.2 ms |
| 帧缓冲合成耗时 | 3.1 ms |
| CPU占用率 | 78% |
问题定位：
- 波形图Widget每帧全屏invalidate，导致脏矩形覆盖整个屏幕
- 波形图绘制用了大量浮点运算，且没有使用DMA2D
- 菜单栏使用了半透明背景，每次绘制都要做Alpha混合
优化措施：
- 波形图改为局部invalidate，只更新变化区域
- 波形图绘制改用定点数，并启用DMA2D进行帧缓冲填充
- 菜单栏半透明背景改为纯色背景，用图片代替Alpha混合
- 开启字体缓存，减少字体解析开销
优化后状态：
| 指标 | 数值 | 提升幅度 |
|---|---|---|
| 平均帧率 | 58 fps | +176% |
| UI树遍历+绘制耗时 | 3.8 ms | -73% |
| 帧缓冲合成耗时 | 0.9 ms | -71% |
| CPU占用率 | 32% | -59% |
关键结论： 没有做任何架构调整，只是针对管线中的具体瓶颈做了优化，帧率就从21fps飙到58fps。这就是“对症下药”的力量。
1.5 本章小结
今天咱们干了三件事：
- 拆解了TouchGFX的渲染管线，知道一帧画面是怎么从应用逻辑走到屏幕上的
- 学会了“三步定位法”，用帧率、CPU分布、Widget开销来找到瓶颈
- 看了一个真实案例，优化前后差距有多大
你想想看，如果你连瓶颈在哪都不知道，优化就是瞎猫碰死耗子。现在你手里有地图了，后面每一章我们都会沿着这张图，一个节点一个节点地优化。
嗯，今天就到这儿。记住那张SVG图，它是你后面29章的导航。