1. TouchGFX 性能调优概述：为什么需要性能调优？
大家好，我是你们这趟性能调优之旅的向导。说实话，我最早接触 TouchGFX 的时候，也踩过不少坑。那时候项目赶得急，界面做出来是能跑，但一上真机就卡成幻灯片。嗯，从那以后我就明白了——性能调优不是锦上添花，而是雪中送炭。
你想想看，一个嵌入式 GUI 项目，硬件资源就那么点。CPU 主频可能才几百兆，RAM 更是捉襟见肘。如果界面响应慢、动画掉帧、触摸延迟高，用户的第一印象就毁了。所以，性能调优的本质，就是在有限的硬件资源下，榨出最好的用户体验。
1.1 性能瓶颈的常见类型
我个人习惯把性能瓶颈分成四类。你在项目中遇到的 90% 的问题，基本都能归到这几类里。
| 瓶颈类型 | 典型表现 | 根因 |
|---|---|---|
| CPU 瓶颈 | 界面卡顿、帧率低、触摸响应慢 | 主循环中计算量过大，或渲染管线被阻塞 |
| GPU 瓶颈 | 动画撕裂、混合效果闪烁、帧率不稳 | 像素填充率不足，或过度使用透明混合 |
| 内存瓶颈 | 程序崩溃、纹理加载失败、动态分配失败 | 帧缓冲区过大，或纹理缓存未合理复用 |
| 带宽瓶颈 | 屏幕刷新延迟、DMA 传输超时 | 外部存储器（如 SDRAM）读写速度跟不上 |
核心观点： 大多数情况下，瓶颈不是单一的。CPU 和 GPU 经常互相等待，内存和带宽也常常纠缠在一起。调优的第一步，就是先搞清楚「谁在拖后腿」。
1.2 调优的总体策略与流程
调优不是瞎调。我见过有人一上来就改 DMA 配置，结果发现瓶颈根本不在那里。所以，我总结了一套流程，你照着走，基本不会跑偏。
第一步：建立性能基线
没有基线，你根本不知道优化了多少。我习惯在项目初期就加入帧率监控和 CPU 负载打印。比如这样：
// 在 TouchGFX 主循环中打印帧率
void touchgfx_task() {
static uint32_t last_tick = 0;
static uint32_t frame_count = 0;
uint32_t now = HAL::getInstance()->getCPUTicks();
frame_count++;
if (now - last_tick >= 1000) {
printf("FPS: %lu\n", frame_count);
frame_count = 0;
last_tick = now;
}
// ... 其余渲染逻辑
}小技巧： 我建议你在开发板上跑一个「空屏」场景，记录最低帧率。这个值就是你的天花板。后续所有优化，都不能让帧率低于这个值。
第二步：定位瓶颈
用 TouchGFX Designer 自带的性能分析工具，或者自己加时间戳。我个人喜欢用 GPIO 翻转 + 示波器看渲染耗时，比软件打印更直观。
- CPU 高 → 检查回调函数、自定义绘制、业务逻辑
- GPU 高 → 检查透明层数、纹理格式、混合模式
- 内存高 → 检查帧缓冲区大小、缓存策略
- 带宽高 → 检查 DMA 配置、存储器时钟
第三步：分级优化
优化要分优先级。我一般按「投入产出比」排序：
- 低挂果实（改动小、收益大）：减少透明层、合并纹理、使用局部刷新
- 中等优化（需要重构）：改用 L8 纹理格式、优化 DMA 传输
- 深度优化（涉及硬件）：调整帧缓冲区布局、启用双缓冲、修改底层驱动
避坑指南： 我曾经为了省 2KB 内存，把纹理缓存砍了一半，结果导致界面切换时频繁从 Flash 加载，帧率直接腰斩。记住：内存省了，带宽可能就爆了。优化要全局看，不能头痛医头。
第四步：验证与回归
每次优化后，都要回到第一步的基线测试。如果帧率没提升，甚至下降了，说明你优化错了方向。别犹豫，立刻回退。
1.3 性能调优的知识体系
下面这张图，是我自己整理的 TouchGFX 性能调优知识体系。你可以把它当作整个课程的地图。
1.4 写在开始之前
性能调优这件事，说白了就是平衡的艺术。你不可能既要极致流畅，又要超低内存，还要快速开发。你得根据项目需求，找到那个「够用就好」的点。
我个人习惯在项目启动时就定好性能目标。比如：
- 主界面帧率不低于 30 FPS
- 触摸响应延迟小于 50ms
- 内存占用不超过 80%
有了目标，调优才有方向。后面的章节，我会带你一步步深入每个瓶颈的根因，并给出具体的优化方案。准备好了吗？我们开始吧。