1. 性能调优总览：为什么 TouchGFX 会卡顿？

大家好，我是你们的老朋友。做嵌入式 UI 这么多年，我见过太多项目在最后关头被卡顿问题拖垮。明明功能都写好了，一跑动画就掉帧，客户那边脸色比屏幕还难看。说实话，TouchGFX 本身是个好框架，但用好它和用对它，中间差着十万八千里。

这一章，我们先从全局视角看看——卡顿到底从哪来？ 我个人习惯，遇到问题先别急着动手改代码，先把瓶颈类型摸清楚。你想想看，连敌人是谁都不知道，你怎么打？

TouchGFX 的动画流畅度，核心指标就是 帧率（FPS）。理想情况下，60 FPS 意味着每帧只有 16.67 ms 的处理时间。一旦某帧超时，下一帧就得等，人眼就感觉到了「卡」。

关键公式：

帧预算 = 1000 ms / 目标帧率

60 FPS → 16.67 ms/帧
30 FPS → 33.33 ms/帧

你的所有渲染、逻辑、内存操作，都得挤在这个时间窗口里完成。

我在项目中遇到过，有人把帧预算全花在软件渲染上，结果 CPU 跑满，GPU 闲着。嗯，这就是典型的资源错配。

根据我的经验，TouchGFX 的性能瓶颈可以归为四类。我习惯把它们画成一张图，方便团队一眼看懂。

这张图我每次做项目评审都会贴出来。你看，四个象限之间还有连线——瓶颈往往不是孤立的。比如 CPU 太忙，可能导致 DMA 请求排队，进而引发带宽瓶颈。我曾经在一个项目里追了三天，最后发现是内存碎片导致帧缓冲区分配变慢，间接拖垮了 GPU 渲染。

光知道分类还不够，你得能快速识别。我整理了一个对照表，平时调试时直接对着看：

瓶颈类型	典型症状	常用检测手段	我踩过的坑
CPU 瓶颈	CPU 占用 > 70%，帧率波动大	HAL_GetTick() 打点、RTOS 任务统计	曾经在回调里做了大量字符串拼接，一帧花了 40ms
GPU 瓶颈	渲染时间 > 10ms，混合模式越多越卡	TouchGFX 内置帧率监视器、DMA2D 计数器	用了 5 层半透明叠加，GPU 直接罢工
内存瓶颈	malloc 失败、屏幕闪烁、随机崩溃	内存池统计、MPU 保护检查	动态分配太多小对象，堆碎片化到无法分配一帧
带宽瓶颈	屏幕撕裂、LTDC 报 FIFO 错误	逻辑分析仪抓 SDRAM 时序、DMA 传输时间测量	SDRAM 时钟配低了，带宽只有理论值的一半

我的小技巧： 调试时先看 CPU 占用。如果 CPU 空闲但帧率低，大概率是 GPU 或带宽问题。如果 CPU 跑满，先优化逻辑，别急着动渲染。

做性能调优，最忌讳「头痛医头，脚痛医脚」。我总结了一套工作流，每次按这个步骤走，基本不会跑偏：

建立基线 —— 先跑一遍基准测试，记录当前帧率、CPU 占用、渲染时间、内存使用。没有基线，你都不知道优化有没有效果。
定位瓶颈 —— 用工具（TouchGFX Designer 的帧率监视器、STM32CubeMonitor、逻辑分析仪）找到最慢的环节。我习惯先看渲染时间，再看 CPU 时间。
分析根因 —— 瓶颈是表象，根因才是关键。比如渲染时间长，是因为纹理太大？还是混合模式太多？还是 DMA 配置不对？
制定方案 —— 针对根因，选择优化手段。优先级：算法优化 > 内存优化 > 硬件加速。别一上来就开 DMA2D，先看看能不能少画几层。
实施并验证 —— 每次只改一个变量，改完重新跑基线。我曾经一次性改了三个地方，结果帧率没变，根本不知道哪个有效。
回归测试 —— 确保优化没有引入新问题。比如减少了纹理大小，但图片模糊了，用户不买账。

调优黄金法则：

不要优化你不知道的东西。
不要优化你测量不了的东西。
不要优化你不需要的东西。

做这行久了，有些坑我闭着眼都能绕过去。分享几个最常见的：

别信直觉，信数据。 我曾经觉得某个图片是瓶颈，优化了半天，结果发现是定时器中断太频繁。嗯，白忙活一场。
优化要渐进。 一次改太多，出了问题你都不知道是哪个改动导致的。我习惯每次只改一个参数，跑一次测试，记录一次。
别忘了硬件限制。 有些瓶颈是硬件天花板，比如 SDRAM 带宽上限。这时候软件优化只能改善，不能根治。该换芯片就换芯片，别死磕。
帧率不是唯一指标。 有时候 30 FPS 比 60 FPS 更流畅，因为帧时间更稳定。我见过 60 FPS 但每帧时间波动 10ms 的项目，用户照样说卡。

警告： 不要在 Release 版本里做性能调试。优化开关、日志打印、调试断言都会影响性能。所有测量必须在 Release 配置下进行，否则你优化的都是「调试模式下的假象」。

好了，这一章我们聊了卡顿的本质、四大瓶颈类型、以及一套可落地的工作流。说白了，性能调优就是 测量 → 分析 → 优化 → 验证 的循环。没有捷径，但有方法。