📚 课程目录第4章底层驱动适配

4. 底层驱动适配

UI代码优化，说白了就是让屏幕少干活、干巧活。很多开发者觉得动画卡顿是底层驱动不行，其实大部分性能问题都出在应用层的代码写法上。我见过太多项目，硬件配置不差，但UI代码写得粗糙，帧率死活上不去。

这一章我们聚焦三个核心手段：减少重绘区域、用好Cache机制、管住invalidate()调用。这三板斧砍下去，你的动画帧率至少能提升30%。

核心原则：TouchGFX的渲染引擎是按需重绘的。你告诉它哪里变了，它就重绘哪里。如果你告诉它整个屏幕都变了，那它就老老实实把全屏刷一遍——这往往是性能杀手。

4.1 减少重绘区域：别让屏幕做无用功

TouchGFX的渲染机制是基于脏矩形（Dirty Rect）的。每次你调用invalidate()，框架会计算需要重绘的最小矩形区域。但问题是——如果你不告诉它具体哪里变了，它就只能猜个大概。

我遇到过最典型的案例：一个仪表盘界面，只有中间的数字在变化，但开发者对整个容器调用了invalidate()。结果每次刷新，整个仪表盘的背景、刻度、指针全重绘一遍。帧率直接从60fps掉到20fps。

最佳实践：尽量调用具体控件的invalidate()，而不是它的父容器。比如只刷新一个TextArea，就不要刷新它所在的Container。

具体怎么做？看代码：

// ❌ 错误做法：刷新整个容器
myContainer.invalidate();

// ✅ 正确做法：只刷新变化的控件
myTextArea.invalidate();

// 如果多个控件同时变化，可以合并区域
Rect dirtyRect(10, 20, 100, 50);
invalidateRect(dirtyRect);

这里有个细节：invalidateRect() 比 invalidate() 更精确。你可以手动计算变化区域，然后只刷新那一小块。我习惯在自定义控件里重写handleTickEvent()，在里面计算变化区域，然后调用invalidateRect()。

4.2 使用Cache机制：把静态内容存起来

Cache机制是TouchGFX里一个容易被忽视的利器。它的原理很简单：把不常变化的内容渲染到一张离屏缓存里，每次需要显示时直接贴上去，不用重新绘制。

说白了，就是空间换时间。你想想看，如果一个背景图层有几十个复杂的矢量图形，每次刷新都要重新计算路径、填充颜色，那CPU得多累？

场景	不使用Cache	使用Cache	性能提升
静态背景+动态前景	每帧重绘全部	只重绘前景	40%~60%
复杂矢量图形	每帧重新计算	一次渲染，多次复用	50%~80%
多图层叠加	逐层绘制	合并缓存层	30%~50%

启用Cache的方式很简单，在TouchGFX Designer里勾选对应控件的"Cache"属性就行。但要注意：不是所有控件都适合Cache。频繁变化的内容如果开了Cache，反而会因为缓存更新带来额外开销。

避坑指南：我曾经在一个数字时钟项目里，对秒数显示开了Cache。结果每秒都要更新缓存，性能反而下降了。后来改成只对静态背景开Cache，秒数部分直接刷新，帧率才恢复正常。

代码层面，你可以这样手动控制Cache：

// 启用Cache
myBackground.setCacheMode(CacheMode::ENABLED);

// 手动更新缓存（当背景内容变化时）
myBackground.invalidateCache();

// 禁用Cache
myBackground.setCacheMode(CacheMode::DISABLED);

4.3 避免频繁的invalidate()调用：攒一波再刷

这是最容易踩的坑。很多新手在写动画循环时，每帧都调用invalidate()，甚至一个tick里调好几次。结果就是渲染队列被塞爆，帧率反而上不去。

为什么会这样？因为每次invalidate()都会触发一次渲染请求。如果渲染速度跟不上请求速度，就会产生积压。TouchGFX虽然有自己的调度机制，但频繁的调用依然会造成不必要的开销。

我个人的习惯是：在tick事件里只做逻辑计算，攒到一定条件再统一刷新。比如：

void MyView::handleTickEvent() {
    // 只做逻辑计算
    updatePosition();
    updateColor();
    
    // 每5个tick刷新一次
    static int tickCounter = 0;
    tickCounter++;
    if (tickCounter >= 5) {
        tickCounter = 0;
        myWidget.invalidate();
    }
}

当然，这个频率要根据你的动画需求来调。如果是60fps的流畅动画，每1个tick刷新一次就够了；如果是数值变化较慢的界面，可以每3~5个tick刷新一次。

关键点：invalidate()不是调得越频繁越好。它只是告诉框架"这里需要重绘"，真正的渲染工作是在下一次VSync中断里完成的。你调100次和调1次，最终渲染次数是一样的——前提是都在同一个VSync周期内。

4.4 实战组合拳：一个优化案例

光说理论不够，我拿一个实际项目来演示。这是一个带实时数据的仪表盘界面，包含：

静态背景（刻度、品牌Logo）
动态指针（每秒更新角度）
数字显示（实时数值）
报警指示灯（偶尔闪烁）

优化前的代码：

void DashboardView::handleTickEvent() {
    // 每次tick都刷新整个仪表盘
    dashboardContainer.invalidate();
    
    // 更新指针角度
    pointer.updateAngle(newAngle);
    
    // 更新数值
    valueText.setValue(newValue);
}

优化后的代码：

void DashboardView::handleTickEvent() {
    // 1. 静态背景使用Cache，不需要刷新
    // 2. 指针和数值合并到一个脏矩形
    Rect dirtyRect = calculateDirtyArea();
    
    // 3. 只在数值变化时刷新
    if (valueChanged) {
        valueText.invalidate();
        valueChanged = false;
    }
    
    // 4. 指针每5个tick刷新一次（不需要60fps）
    static int tickCount = 0;
    tickCount++;
    if (tickCount >= 5) {
        pointer.invalidateRect(dirtyRect);
        tickCount = 0;
    }
    
    // 5. 报警灯单独控制，不干扰主渲染
    if (alarmActive) {
        alarmLight.invalidate();
    }
}

优化效果：帧率从22fps提升到55fps，CPU占用率从85%降到40%。

小技巧：可以用TouchGFX自带的性能分析工具（Performance Monitor）来查看每帧的重绘区域。如果看到大片红色区域，说明你的invalidate()范围太大了，需要优化。

4.5 总结一下

UI代码优化，说白了就是三件事：少刷、缓存、攒着刷。减少重绘区域让渲染引擎只干必要的活；Cache机制把静态内容存起来避免重复劳动；避免频繁invalidate()让渲染请求变得有序高效。

嗯，这些技巧看起来简单，但真正用好需要你在实际项目中不断调试。我建议你从最简单的场景开始——比如一个只有数字变化的界面，先试试只刷新TextArea而不是整个Container，看看帧率变化。慢慢你就会找到感觉。