4、性能评估指标体系：定义CPU占用率、任务延迟、响应时间、吞吐量、栈水位等关键指标及其测量单位

TinyML RTOS 的性能评估不能停留在“感觉系统还行”的层面，必须建立一套可量化、可对比、可追踪的指标体系。CPU 占用率、任务延迟、响应时间、吞吐量和栈水位是衡量系统实时性与资源效率的五大核心维度。每一项指标都有其明确的物理含义、测量单位、采集方法和适用场景。只有先统一这些“度量衡”，后续的调优和排障才有共同语言。本章将逐一拆解这些指标的定义边界、测量单位、采集手段，并给出一个综合案例说明如何在实际项目中落地这套指标体系。

上图展示了五大指标在 RTOS 性能评估中的整体关系。CPU 占用率反映系统资源负载，任务延迟和响应时间刻画实时性，吞吐量衡量处理能力，栈水位则关乎系统稳定性。这五个维度相互独立又彼此影响——例如 CPU 占用率过高会直接拉长任务延迟，栈水位不足可能导致系统崩溃。下面逐一深入解析。

4.1 CPU 占用率：系统负载的“温度计”

核心原理：CPU 占用率（CPU Utilization）指在一段统计周期内，CPU 执行任务代码、中断服务程序（ISR）和内核代码的时间占总时间的百分比。在 TinyML 场景中，CPU 占用率直接决定了系统是否还有余量处理突发任务或增加新的算法模块。测量单位是百分比（%），统计周期通常取 100ms、1s 或 10s，具体取决于应用对实时性的敏感度。

判断方法与操作流程：RTOS 通常提供空闲任务（Idle Task）钩子函数。当系统无任务可运行时，空闲任务被执行，在钩子函数中累加计数器。CPU 占用率计算公式为：

CPU_Usage = (1 - idle_count / total_count) × 100%
其中：
- idle_count：统计周期内空闲任务执行的次数（或时间）
- total_count：统计周期内总计数（通常由周期定时器累加）

实际操作中，可以在空闲任务钩子中递增一个 volatile 变量，同时用系统 tick 中断维护总计数。每 1 秒读取一次并清零，即可得到近似的 CPU 占用率。对于 Cortex-M 系列，也可以使用 DWT->CYCCNT 寄存器获取精确的 CPU 周期数。

4.2 任务延迟与响应时间：实时性的“双胞胎”

核心原理：任务延迟（Task Latency）和响应时间（Response Time）经常被混用，但二者有严格区别。任务延迟指从任务就绪（Ready）到任务开始执行（Running）的时间差，它反映的是调度器的调度效率；响应时间指从事件发生（如中断触发）到任务完成相应处理的时间差，它包含中断延迟、调度延迟和任务执行时间三部分。测量单位均为微秒（us）或毫秒（ms）。

判断方法与操作流程：测量任务延迟的常用方法是在任务入口处读取时间戳，减去任务被置为就绪状态的时间戳。响应时间则需要在中断服务程序中记录事件到达时间，在任务处理完成处记录结束时间。使用 Cortex-M 内核的 DWT->CYCCNT 寄存器可以获得纳秒级精度的时间戳。

// 伪代码示例：测量响应时间
volatile uint32_t event_time, response_time;
void ISR_Handler(void) {
    event_time = DWT->CYCCNT;  // 记录事件到达时刻
    // 设置事件标志或发送信号量
}
void Task_Handler(void) {
    uint32_t start = DWT->CYCCNT;
    // 处理事件...
    uint32_t end = DWT->CYCCNT;
    response_time = end - event_time;  // 总响应时间
    task_latency = start - event_time; // 调度延迟
}

4.3 吞吐量：处理能力的“吞吐口”

核心原理：吞吐量（Throughput）指单位时间内系统成功处理的任务数量或数据量。在 TinyML 场景中，常见的吞吐量指标包括：每秒处理的推理请求数（FPS）、每秒处理的消息数（msg/s）、每秒传输的字节数（Bps）。吞吐量直接反映系统的数据处理能力上限。

判断方法与操作流程：测量吞吐量需要构造一个稳定的负载源。例如，在传感器数据采集任务中，可以统计 10 秒内成功处理的数据帧数量，除以时间得到平均吞吐量。对于推理任务，可以连续运行 100 次推理，用总时间除以 100 得到单次推理时间，再取倒数得到 FPS。

4.4 栈水位：稳定性的“水位线”

核心原理：栈水位（Stack Watermark）指任务栈中已使用的最大深度与栈总大小的差值。它反映任务运行过程中栈空间的最大消耗量。测量单位是字节（Byte）。栈水位过低意味着栈可能溢出，导致内存踩踏、系统崩溃等严重问题。

判断方法与操作流程：RTOS 通常在任务创建时初始化栈区域为特定模式（如 0xCC）。任务运行后，从栈底向上扫描，找到最后一个未被覆盖的标记字节，即可计算出最大栈使用深度。FreeRTOS 提供 uxTaskGetStackHighWaterMark() API 直接返回栈水位值。

// FreeRTOS 示例：获取栈水位
TaskHandle_t xTaskHandle;
uint32_t ulHighWaterMark;
ulHighWaterMark = uxTaskGetStackHighWaterMark(xTaskHandle);
// 返回值表示该任务自创建以来，栈中剩余的最小可用空间（字节）

4.5 综合案例：智能音箱唤醒词检测系统的性能评估

背景与约束：某智能音箱产品使用 Cortex-M4 内核（主频 80MHz），运行 FreeRTOS，包含音频采集任务（优先级 3）、VAD 语音活动检测任务（优先级 2）、唤醒词推理任务（优先级 1）和 LED 控制任务（优先级 0）。内存仅 128KB，其中任务栈总预算 32KB。产品要求：唤醒词检测准确率 >95%，响应时间 <300ms，CPU 占用率 <70%。

初始现象：在实验室测试中，唤醒词检测功能正常，但偶发“唤醒无反应”现象。通过日志发现，推理任务有时超过 500ms 才完成，且系统偶尔重启。

关键数据采集：使用 4.1~4.4 节的方法进行一周的持续监测，得到以下数据：

分析判断过程：CPU 占用率超标且推理任务延迟偶发剧增，怀疑是音频采集任务占用过多 CPU。进一步使用 DWT 计数器分析发现，音频采集任务在 DMA 中断中执行了过多的数据拷贝操作，导致中断关闭时间长达 80us。同时，推理任务栈水位最低仅剩 0.4KB，说明栈空间接近耗尽，存在溢出风险。

实际操作步骤：

1. 优化音频采集任务：将 DMA 中断中的数据拷贝改为双缓冲机制，中断中仅切换缓冲区指针，拷贝操作放到任务中执行。中断关闭时间从 80us 降至 15us。
2. 调整任务优先级：将 VAD 任务优先级从 2 提升至 3，使其在音频采集后立即执行，减少推理任务的无效唤醒。
3. 增大推理任务栈：从 4KB 增至 6KB，同时将 LED 控制任务栈从 2KB 减至 1.5KB（其栈水位实测仅需 0.8KB）。
4. 增加栈水位监控：在系统 tick 钩子中每 100ms 检查一次所有任务的栈水位，低于阈值时输出告警日志。

结果对比：优化后，CPU 占用率降至 55%，推理任务最大延迟降至 80ms，响应时间最大 260ms，栈水位稳定在 1.8KB 以上。系统连续运行 72 小时无重启，唤醒无反应现象消失。

风险与代价：双缓冲机制增加了 1KB 内存占用（两个缓冲区各 512B），但换来了中断延迟的大幅降低。任务优先级调整后，VAD 任务执行频率增加，CPU 占用率上升约 3%，仍在可接受范围内。

4.6 常见误区与总结复盘

误区一：只关注 CPU 占用率而忽略其他指标。CPU 占用率只是资源使用的一个侧面，无法反映调度延迟和栈风险。一个 CPU 占用率 50% 的系统可能因为优先级配置不当导致任务饿死。

误区二：用平均值代替最坏值。实时系统的性能评估必须关注最坏情况。建议在报告中同时给出平均值、P95、P99 和最大值，并明确设计阈值对应的是哪个统计量。

误区三：栈水位只在开发阶段检查。栈使用量会随代码路径变化，功能迭代后必须重新验证。建议在正式发布前进行 72 小时压力测试，并开启栈水位监控。

误区四：测量工具本身影响结果。使用 DWT 计数器或 GPIO 翻转测量时，测量代码本身会占用 CPU 周期。对于时间敏感场景，建议使用 DMA 或外部逻辑分析仪进行无侵入测量。

总结：五大指标构成了 TinyML RTOS 性能评估的完整闭环。CPU 占用率回答“系统忙不忙”，任务延迟回答“调度快不快”，响应时间回答“事件处理及时不及时”，吞吐量回答“处理能力强不强”，栈水位回答“系统稳不稳”。在实际项目中，应建立指标基线，定期采集，形成趋势报告。当任一指标偏离基线超过 20% 时，必须启动根因分析。这套指标体系不仅是调优的工具，更是保障产品长期稳定运行的生命线。