2. 嵌入式GUI基础

做嵌入式GUI优化，第一件事就是搞清楚——你的手指点下去之后，那几十毫秒到底花在哪了？

我见过不少团队，一上来就怼代码优化，结果发现延迟根本没降多少。为什么？因为他们连延迟从哪来的都没摸清楚。今天我们就来拆这条链路，从你指尖触碰屏幕，到像素最终刷新出来，每一站都算清楚。

2.1 完整链路：触摸到反馈的六站旅程

我把这条路径分成六个关键站点。每个站点都有它的“驻留时间”。

你看，从②到⑥，每一站都在吃时间。但最容易被忽视的是哪站？我个人经验是——④应用处理。很多工程师把精力花在驱动层，结果应用层一个回调函数里塞了三个数据库查询，延迟直接爆炸。

2.2 延迟的三大构成要素

我们把六站合并成三大块：硬件延迟、驱动延迟、应用处理延迟。这样更容易定位问题。

2.2.1 硬件延迟

硬件延迟包括触摸屏的物理采样周期和ADC转换时间。说白了，就是硬件本身“反应慢”。

• 触摸屏扫描周期：电容屏通常以60~120Hz扫描，每次扫描耗时1~8ms。扫描频率越低，延迟越大。
• ADC采样与滤波：原始信号需要经过滤波算法（如中值滤波、卡尔曼滤波），这也会吃掉几百微秒到几毫秒。
• 通信接口延迟：I²C通常跑在400kHz，传输一次坐标数据约需0.5ms；SPI会快一些，但也要考虑片选和中断响应。

2.2.2 驱动延迟

驱动层是触摸芯片和操作系统之间的桥梁。这里的问题往往出在中断处理和数据传递上。

驱动延迟来源	典型耗时	优化方向
中断响应延迟	10~100μs	提高中断优先级，减少中断嵌套
I²C/SPI读取耗时	0.5~2ms	使用DMA传输，避免CPU轮询
数据解析与校验	0.1~0.5ms	简化校验算法，预计算坐标映射
上报到系统输入队列	0.1~1ms	使用无锁队列，减少上下文切换

嗯，这里要注意——驱动延迟虽然绝对值不大，但它是“前段延迟”。如果驱动慢了，后面所有环节都得等着。我曾经在一个RTOS项目里发现，触摸中断被一个高优先级的定时器任务频繁抢占，导致触摸数据平均延迟增加了3ms。后来把触摸中断优先级调到最高，问题就解决了。

2.2.3 应用处理延迟

这是大头，也是你最能发挥的地方。应用处理延迟包括：

• 事件分发：触摸事件从系统队列传递到具体控件，中间可能经过多层回调。
• 业务逻辑处理：比如点击按钮后触发数据保存、网络请求、状态切换等。
• 控件状态更新：按钮高亮、滑块移动、列表滚动等UI反馈。
• 重绘请求：标记脏矩形，触发渲染。

2.3 延迟测量：用数据说话

光靠猜不行，得测。我常用的方法有两种：

1. GPIO打码法：在关键节点翻转GPIO电平，用逻辑分析仪抓取时间戳。精度高，适合硬件和驱动层。
2. 软件时间戳法：在应用层用系统滴答定时器记录时间点。精度稍低，但方便。

/* 软件时间戳测量示例（基于FreeRTOS） */
uint32_t t_start, t_end;

void touch_event_handler(touch_event_t *evt) {
    t_start = xTaskGetTickCountFromISR();  // 记录事件到达时间
    
    // 业务处理...
    process_touch(evt);
    
    t_end = xTaskGetTickCountFromISR();
    uint32_t elapsed = (t_end - t_start) * portTICK_PERIOD_MS;
    
    if (elapsed > 20) {
        // 超过20ms，打印警告
        printf("[WARN] Touch processing took %lu ms\n", elapsed);
    }
}

我个人习惯在项目初期就把这些测量代码埋进去。等优化完了再删掉，或者用条件编译控制。这样随时能拿到第一手数据。

2.4 延迟预算：定个目标

做优化之前，先定个目标。我一般按这个预算来分配：

延迟环节	目标值（60Hz屏幕）	目标值（120Hz屏幕）
硬件采样+驱动上报	≤ 5ms	≤ 3ms
应用处理+渲染	≤ 10ms	≤ 5ms
屏幕刷新等待	≤ 16.7ms	≤ 8.3ms
端到端总延迟	≤ 31.7ms	≤ 16.3ms

你想想看，如果总延迟超过50ms，用户就能明显感觉到“卡”了。超过100ms，用户会觉得这个设备“反应迟钝”。所以，我的底线是：端到端延迟控制在30ms以内。