如何利用 sysdump 剖析 CPU 降频对端侧推理性能的致命影响

在移动端部署深度学习模型（如使用 ncnn, MNN 或 TFLite）时，开发者经常遇到一个诡异的问题：同样的模型，在实验室测试时推理耗时非常稳定（如 30ms），但集成到 App 运行一段时间后，耗时会突然飙升到 100ms 甚至更高。

这种“性能跳水”通常不是代码逻辑的问题，而是触发了移动设备的 CPU 降频（CPU Throttling）。本文将教你如何利用 Android 的 sysdump 工具及底层内核接口，实操定位降频对推理库 Latency 的影响。

一、 为什么 CPU 频率是端侧推理的生命线？

端侧推理库（如 ncnn）极致利用了 CPU 的 SIMD（NEON）指令集。这些指令的执行效率直接挂钩于 CPU 的时钟频率。当手机发热或电量过低时，系统内核的 DVFS (动态电压频率调整) 会强制降低大核频率以散热。

如果你发现推理耗时在运行 1 分钟后开始线性增长，那么大概率是“撞到了温度墙”。

二、 实操步骤：监控推理时的 CPU 实时频率

要实证降频，我们需要在模型推理的同时，并行记录 CPU 各核的频率。

1. 获取 CPU 核心路径

Android 的 CPU 频率信息存储在 /sys/devices/system/cpu/ 路径下。通常大核（Big Core）对推理贡献最大，我们需要关注这些核心。

2. 自动化监控脚本

我们可以编写一个 Python 脚本，通过 adb 循环读取频率。

import subprocess
import time

def get_cpu_freq(core_index):
    # 读取指定核心的当前频率 (单位: KHz)
    cmd = f"adb shell cat /sys/devices/system/cpu/cpu{core_index}/cpufreq/scaling_cur_freq"
    try:
        result = subprocess.check_output(cmd, shell=True)
        return int(result.strip()) / 1000  # 转换为 MHz
    except:
        return 0

if __name__ == '__main__':
    print("开始监控... 运行你的推理程序后观察频率变化")
    # 假设 4-7 是骁龙平台的大核
    cores = [4, 5, 6, 7] 
    while True:
        freqs = [get_cpu_freq(i) for i in cores]
        print(f"Current Big Core Frequencies: {freqs} MHz")
        time.sleep(0.5)

三、 使用 dumpsys 观察系统状态

除了原始频率，dumpsys 可以提供更宏观的系统视图，帮助确认是否因为电池或热管理导致降频。

1. 查看热管理状态

执行以下命令观察是否存在 Thermal 限制：

adb shell dumpsys thermalservice

如果你看到 Thermal Status: 3 (Severe) 或更高，系统会自动触发降频。

2. 查看 CPU 调度摘要

使用 sysdump 的 cpuinfo 插件查看最近的 CPU 负载占比：

adb shell dumpsys cpuinfo

四、 实验对比分析

在测试你的推理库（如 ncnn_benchmark）时，对比以下两组数据：

1. 冷机启动（Cold Start）： CPU 大核处于 2841 MHz，推理耗时 32ms。
2. 热机运行（Thermal Throttling）： 运行 5 分钟后，大核被压制在 1200 MHz，推理耗时瞬间变为 85ms。

结论： 如果你发现频率下降与 Latency 上升呈现完美的负相关，那么优化方向应从“模型优化”转为“热管理策略优化”。

五、 解决建议

1. 绑定大核（Affinity）： 使用 ncnn::set_cpu_powersave(2) 或类似的 API 强制绑定大核，虽然发热快，但在短时间内能获得最高性能。
2. 降低线程数： 在发热严重的设备上，减少 1 个推理线程反而可能因为发热降低而让剩下的核心维持在高频，从而提升整体 Latency。
3. 异构计算： 考虑将部分算子切到 GPU (Vulkan/OpenCL) 或 NPU，减轻 CPU 的散热压力。

通过这种定量的频率监控，你就能拿证据告诉产品经：不是代码变慢了，而是手机“太烫了”。