RWK35xx语音识别资源释放避免内存泄漏

在智能音箱、语音开关这些看似“傻瓜式”的设备背后，藏着一个嵌入式开发者最头疼的问题： 明明代码跑得好好的，怎么几天后就卡死了？

答案往往藏在一个不起眼的角落—— 内存泄漏 。尤其是当你用上了像 RWK35xx 这类主打离线语音识别的SoC芯片时，一旦资源管理没跟上，系统可能不是“慢一点”，而是直接“躺平”。

别急，咱们今天不讲大道理，也不堆术语，就来聊聊： 为什么你每次喊“小智开机”之后，系统悄悄吞了2KB内存？而100次之后，它就没得吐了。

---

你以为的“结束”，其实只是暂停

想象一下这个场景：

用户按下一个物理按键，设备开始监听语音指令。你说完“打开台灯”，它识别成功、执行命令、然后……你以为一切都结束了？

错！这时候，语音引擎内部还躺着一堆“遗物”：
- 音频缓冲区还在堆里占着地盘 📦
- 模型参数还牢牢贴在RAM上 💾
- DMA通道和中断句柄也没退群 🚪

如果你只调用了 rkvr_stop() 就撒手不管，那这些资源就会变成“僵尸内存”——活着没干活，死了不收尸。

这就是典型的 会话未完整闭环 。

RWK35xx 的 SDK 设计是基于“会话（Session）”模型的，就像打电话一样：
拨号 → 讲话 → 挂断 → 收线 ✅
可很多人只做到“挂断”，忘了“收线”。结果就是每次通话都留下一根电话线头在外头晃荡……

---

资源哪来的？又该归哪儿去？

我们拆开看看一次语音识别到底动了哪些资源：

资源类型	来源	是否需手动释放？
上下文句柄 ( rkvr_handle_t )	rkvr_create() → malloc	✅ 必须 rkvr_destroy()
声学模型数据	rkvr_load_model() → 加载到RAM	✅ 必须 rkvr_unload_model()
音频环形缓冲区	内部特征提取使用	✅ stop + deinit 自动释放
中断/DMA 绑定	启动采集时注册	✅ 销毁句柄时解绑

看到没？除了最后一项由底层自动处理外，前面三项全靠你自己“送终”。

特别是那个 .model 文件加载，很多人以为“换词表才卸载”，其实只要你不打算马上再用，就得赶紧清掉——毕竟MCU的RAM可不是云服务器，动不动几十G随便挥霍。

---

异步回调的“陷阱”：你以为结束了，其实还没开始清理

SDK 提供了非常方便的回调机制：

void on_recognition_result(int event, char* word, int score) {
    // 处理识别结果
    if (event == VR_EVENT_WAKEUP) {
        light_on();
    }
}

听着很美好，但问题来了： 回调函数返回了，是不是意味着整个识别流程结束了？

❌ 不一定！

回调只是告诉你“我听到了什么”，并不代表：
- 音频流已停止
- 缓冲区已清空
- 内存已归还

你得自己主动调用 vr_engine_stop() 和 vr_engine_deinit() 才算真正收工。

否则，哪怕识别只花了200ms，剩下的内存却永远留在那里——日积月累，直到OOM（Out of Memory）崩溃。

这就好比吃饭只顾夹菜，从不洗碗，厨房迟早炸锅 🍽️💥

---

正确姿势长什么样？看这个模板 ⚙️

下面这段代码，是我们压箱底的“防泄漏三板斧”写法，已经在多个量产项目中验证过稳定性：

#include "rkvr_api.h"

static rkvr_handle_t g_vr_handle = NULL;

int vr_engine_init(void)
{
    if (g_vr_handle != NULL) {
        vr_engine_deinit(); // 防止重复初始化导致泄漏
    }

    g_vr_handle = rkvr_create();
    if (!g_vr_handle) return -1;

    if (rkvr_load_model(g_vr_handle, "wakeup.model") != 0) {
        rkvr_destroy(g_vr_handle);
        g_vr_handle = NULL;
        return -2;
    }

    rkvr_set_callback(g_vr_handle, on_recognition_result);
    return 0;
}

void vr_engine_stop(void)
{
    if (g_vr_handle) {
        rkvr_stop(g_vr_handle);
    }
}

void vr_engine_deinit(void)
{
    if (g_vr_handle) {
        rkvr_unload_model(g_vr_handle);     // 先卸模型
        rkvr_destroy(g_vr_handle);          // 再销毁句柄
        g_vr_handle = NULL;                 // 防野指针
    }
}

重点来了 👇：
- deinit() 是必须调用的“扫尾仪式”
- 双重检查 g_vr_handle != NULL 是为了防止意外重复释放
- 卸载模型一定要在销毁句柄前完成，顺序不能颠倒！

不然轻则内存漏光，重则触发 hardfault——那种半夜被客户电话叫醒的感觉，谁试谁知道 😵‍💫

---

实际应用场景：按键唤醒为啥一周后失灵？

来看看最常见的使用模式：

[用户按下语音键]
      ↓
vr_engine_init() → 创建上下文
      ↓
vr_engine_start() → 开始监听
      ↓
收到 on_recognition_result()
      ↓
执行动作（如开灯）
      ↓
vr_engine_stop()
      ↓
vr_engine_deinit() ← 啊？这里忘了？

如果漏了最后一步 deinit() ，每次触发都会吃掉约 2~8 KB RAM （取决于模型大小）。

举个例子：
- MCU 总 RAM：192 KB
- 每次识别泄漏：4 KB
- 每天触发 50 次 → 每天流失 200 KB
- 第二天还没重启？抱歉，内存早已耗尽 💀

更惨的是，这种问题很难在测试阶段发现。实验室里一天测十几次没问题，出厂三个月后用户天天用，突然某天就不响应了——售后背锅，研发挠头。

---

怎么查？教你三招快速定位泄漏 🔍

🛠 方法一：堆内存打点监控

利用 FreeRTOS 或裸机环境下的堆统计功能，实时观察剩余内存变化：

void print_heap_status(const char* tag)
{
#ifdef CONFIG_USE_FREERTOS
    printf("[%s] Free Heap: %d bytes\n", tag, xPortGetFreeHeapSize());
#else
    extern char _end;
    extern char __brkval;
    int used = __brkval ? (__brkval - &_end) : 0;
    printf("[%s] Used Heap: %d bytes\n", tag, used);
#endif
}

然后在关键节点插入打印：

print_heap_status("Before init");
vr_engine_init();
print_heap_status("After init");

// ... 识别完成后

print_heap_status("Before deinit");
vr_engine_deinit();
print_heap_status("After deinit");

✅ 正常情况：内存先降后升，形成周期性波动
❌ 存在泄漏：内存一路下滑，永不回升

🧩 方法二：加日志，看配对

简单粗暴但极其有效：

#define VR_LOG(fmt, ...)  printf("[VR] " fmt "\n", ##__VA_ARGS__)

// 初始化时
VR_LOG("Init: handle=0x%p", g_vr_handle);

// 销毁时
VR_LOG("Deinit: released handle");

串口一接，看日志里有没有“有始无终”的记录。比如：

[VR] Init: handle=0x2000abcd
[VR] Init: handle=0x2000bcde
[VR] Deinit: released handle

两个 init ，只有一个 deinit ？立马锁定bug位置！

🤖 方法三：静态分析工具帮你找茬

用 Cppcheck 或 PC-Lint 扫一遍代码，专门查：
- 函数是否有异常路径提前返回但未释放
- rkvr_create() 是否都有对应 rkvr_destroy()
- 全局变量是否可能造成重复申请

这类工具虽然不会百分百准确，但能揪出很多“我以为不会走到这里”的逻辑漏洞。

---

工程最佳实践建议 💡

建议	说明
✅ 使用 RAII 思想封装	把 init/deinit 包成一对函数，对外只暴露 start_recognition() / stop_recognition()
✅ 禁止并发会话	同一时间只允许一个语音任务运行，避免资源竞争
✅ 加超时保护	设置最大监听时间（如10秒），超时自动 stop + deinit
✅ 模型复用	如果多个场景用相同词表，不要反复加载/卸载，共享实例
✅ RTOS中独立任务运行	避免阻塞主线程，便于统一调度与错误恢复

还有一个狠招： 压力测试脚本模拟连续触发1000次 ，配合内存曲线图，一眼看出是否存在缓慢泄漏。

---

最后一句真心话 ❤️

嵌入式开发的魅力，在于每一字节都要精打细算。
你写的每一行 malloc ，都应该想着怎么优雅地 free 。

RWK35xx 这颗芯片很强，本地识别快、功耗低、支持多词条训练，但它不会替你做内存管理。
真正的稳定，不是靠硬件多牛，而是靠程序员对资源的那一份敬畏之心。

所以下次你在写 rkvr_start() 的时候，不妨停下来问一句：

“等会儿我要怎么把它‘送走’？”

答不上来？那就先别启动 😌

毕竟，让设备活得久一点，也是种温柔。