Ai_GirlFriend/xuniYou/语音通话性能优化建议.md
2026-02-28 18:04:34 +08:00

4.5 KiB
Raw Blame History

语音通话性能优化建议

当前状态

功能已实现并正常工作 ⚠️ 响应速度较慢

延迟分析

当前流程的时间消耗:

  1. 录音时间用户说话的时间2-5秒
  2. 文件处理:停止录音 + 读取文件(~100ms
  3. 网络传输:上传音频到服务器(~200-500ms取决于文件大小和网络
  4. 服务器处理
    • 语音识别ASR~500-1000ms
    • LLM 生成回复:~1000-3000ms
    • 文本转语音TTS~500-1000ms
    • 总计:~2000-5000ms
  5. 下载音频:从服务器下载(~200-500ms
  6. 播放音频:解码和播放(~100ms

总延迟:约 3-7 秒

优化方案

方案1服务器端优化推荐

1.1 使用流式 ASR

边接收边识别,不等待完整音频
延迟降低:-1000ms

1.2 使用流式 TTS

边生成文本边合成语音
延迟降低:-500ms

1.3 优化 LLM 调用

使用更快的模型或流式输出
延迟降低:-1000ms

1.4 并行处理

ASR 完成后立即调用 LLM同时准备 TTS
延迟降低:-500ms

预期效果:总延迟降至 1-3 秒

方案2客户端优化

2.1 减小音频文件大小

当前配置:

format: 'mp3',
sampleRate: 16000,
encodeBitRate: 48000  // 较高

优化配置:

format: 'mp3',
sampleRate: 16000,
encodeBitRate: 24000  // 降低比特率

效果:文件减小 50%,上传更快

2.2 压缩音频

// 在发送前压缩
const compressedData = compressAudio(fileRes.data)

2.3 预加载和缓存

// 预先建立连接
// 缓存常用回复

方案3使用实时流式传输

3.1 客户端改造

需要使用原生插件或支持 onFrameRecorded 的方式:

// 实时发送音频帧
recorderManager.onFrameRecorded((res) => {
    socketTask.send({ data: res.frameBuffer })
})

3.2 服务器端改造

需要支持:

  • 流式接收音频
  • 实时 ASR
  • 流式 LLM
  • 流式 TTS

效果:延迟降至 500ms-1s类似 ChatGPT 语音)

当前问题诊断

服务器返回 "idle timeout"

这说明服务器端有问题:

  1. 检查服务器日志

    • 是否收到音频数据?
    • 音频格式是否正确?
    • ASR 服务是否正常?
    • LLM 服务是否正常?
    • TTS 服务是否正常?
  2. 检查超时设置

    # 服务器端可能需要增加超时时间
    timeout = 30  # 秒
    
  3. 检查音频格式

    • 服务器期望什么格式?
    • 是否需要特定的采样率?
    • 是否需要添加文件头?

快速改进建议

立即可做的优化:

  1. 降低音频比特率

    encodeBitRate: 24000  // 从 48000 降到 24000
    
  2. 添加进度提示

    uni.showLoading({ title: '识别中...' })  // 发送后
    uni.showLoading({ title: '思考中...' })  // 识别完成后
    uni.showLoading({ title: '生成语音...' }) // LLM 完成后
    
  3. 优化用户体验

    • 显示波形动画
    • 显示处理进度
    • 添加音效反馈

需要后端配合的优化:

  1. 返回处理进度

    {"type": "progress", "stage": "asr", "percent": 50}
    {"type": "progress", "stage": "llm", "percent": 70}
    {"type": "progress", "stage": "tts", "percent": 90}
    
  2. 使用流式返回

    {"type": "text_chunk", "text": "你好"}
    {"type": "text_chunk", "text": ",我"}
    {"type": "text_chunk", "text": "是"}
    
  3. 分段返回音频

    {"type": "audio_chunk", "data": "..."}
    {"type": "audio_chunk", "data": "..."}
    {"type": "audio_end"}
    

性能对比

方案 延迟 实现难度 用户体验
当前方案 3-7s 简单 一般
优化比特率 2-6s 很简单 一般
服务器优化 1-3s 中等
实时流式 0.5-1s 困难 很好

建议的实施步骤

  1. 第一步:降低音频比特率(立即可做)
  2. 第二步:添加进度提示(立即可做)
  3. 第三步:联系后端,解决 "idle timeout" 问题
  4. 第四步:后端优化(并行处理、流式 ASR/TTS
  5. 第五步:考虑实时流式传输(长期目标)

结论

当前的慢主要是因为:

  1. 服务器端处理时间长2-5秒
  2. 服务器返回了错误idle timeout
  3. 没有使用流式处理

优先解决服务器端的 "idle timeout" 问题,然后逐步优化。