uni-app 离线打包讯飞语音 第一次语音听写正常 第二次听写卡死
uni-app 离线打包讯飞语音 第一次语音听写正常 第二次听写卡死
信息类别 | 详细信息 |
---|---|
产品分类 | uniapp/App |
PC开发环境 | Mac |
PC版本号 | 11.2.1 |
开发工具 | HBuilderX |
工具版本 | 3.1.2 |
手机系统 | iOS |
系统版本 | IOS 14 |
手机厂商 | 苹果 |
手机型号 | iphone11pro max |
页面类型 | vue |
打包方式 | 离线 |
创建方式 | HBuilderX |
操作步骤:
- 就正常配置
预期结果:
- 预期可多次识别语音
实际结果:
- 只识别了一次就卡死
bug描述:
iflyMSC.framework是讯飞的语音听写流式版,自己的appid。第一次使用语音可以正常识别、写入,第二次打开后停留在了倾听中状态卡死。
更多关于uni-app 离线打包讯飞语音 第一次语音听写正常 第二次听写卡死的实战教程也可以访问 https://www.itying.com/category-93-b0.html
2 回复
请提供可以稳定复现的示例demo 我这边帮你看
更多关于uni-app 离线打包讯飞语音 第一次语音听写正常 第二次听写卡死的实战教程也可以访问 https://www.itying.com/category-93-b0.html
根据描述,这是一个典型的讯飞语音SDK在uni-app离线打包中的资源释放问题。常见原因和解决方案如下:
-
核心问题:讯飞语音SDK在第一次听写后没有正确释放资源,导致第二次调用时卡死
-
检查要点:
- 确保每次听写结束后调用
destroy()
方法 - 检查是否重复创建了多个
IFlySpeechRecognizer
实例 - 确认是否在页面销毁时调用了资源释放方法
- 典型修复代码:
// 在methods中
stopListening() {
this.recognizer.stopListening();
this.recognizer.destroy(); // 关键释放操作
this.recognizer = null;
}