实践总结
开发 Electron 桌面端应用时，我遇到了一个常见但又棘手的问题：录音功能。本文将分享我的实践经历，包括为什么 ScriptProcessor 蓝屏、为什么 AnalyserNode 会导致音频噪声，以及最终使用 AudioWorklet 的完整解决方案。
一、背景
在 Electron 桌面端项目中，我需要实现实时音频采集 ，并通过 WebSocket 将 PCM 数据发送给后端进行 AI 处理或存储。最初的方案是使用 Web Audio API 中的 ScriptProcessorNode ，后来尝试过 AnalyserNode ，最终才稳定使用 AudioWorkletNode。
ScriptProcessorNode：在mac和windows环境下打开麦克风以后，系统蓝屏了。
AnalyserNode：在mac和windows环境下打开麦克风以后，系统没有蓝屏，但是实时语音给后端，后端最后生成的录音文件有噪音， AnalyserNode 本来就不是用来"录音"的，AnalyserNode 的设计目的只有一个："可视化音频（波形 / 频谱）"
AudioWorkletNode： 高性能、低延迟、干净 PCM。
录音功能涉及的技术点：
- 浏览器端获取麦克风权限（
getUserMedia） - 实时音频采集与处理（Web Audio API）
- WebSocket 流式传输音频
- Electron 特有环境适配（桌面端文件路径、协议差异）
二、方案演变
1️⃣ ScriptProcessorNode
使用场景： Web Audio API 的老方案，支持实时 PCM 处理。
代码示例：
const processor = audioContext.createScriptProcessor(4096, 1, 1);
processor.onaudioprocess = (e) => {
const inputData = e.inputBuffer.getChannelData(0);
// 转 Int16 并发送给后端
};
source.connect(processor);
processor.connect(audioContext.destination);遇到的问题：
- Electron 桌面端开启麦克风时容易蓝屏或崩溃。
- 原因是 ScriptProcessor 在渲染线程执行，CPU 占用高且对系统兼容性差。
- 在 Windows 上尤其明显，低版本 Electron / Node 环境容易触发系统级错误。
结论： ScriptProcessor 不适合 Electron 桌面端稳定录音。
2️⃣ AnalyserNode
使用场景： 我尝试用 AnalyserNode 采集音频信号，通过 getFloatTimeDomainData 获取 PCM 数据。
实现逻辑：
const analyser = audioContext.createAnalyser();
analyser.fftSize = 2048;
source.connect(analyser);
function captureAudio() {
const buffer = new Float32Array(analyser.fftSize);
analyser.getFloatTimeDomainData(buffer);
// 转 Int16 并发送
}遇到的问题：
- 音频文件播放时出现明显噪声。
- 原因：
-
- AnalyserNode 的主要用途是可视化频谱分析，而不是精确音频捕获。
getFloatTimeDomainData的采样可能存在丢帧和抖动。- 导致 PCM 数据质量下降，音频后端识别或播放不稳定。
结论： AnalyserNode 不适合生成干净的音频流。
3️⃣ AudioWorkletNode
解决方案： Web Audio API 的新标准，专门用于高性能、低延迟音频处理。
特点：
- 在音频渲染线程（AudioWorkletGlobalScope）运行，不阻塞主线程。
- 可以处理任意采样率、精确输出 PCM 数据。
- 与 WebSocket 流式传输结合，可以实时发送音频给后端。
核心实现逻辑：
-
获取麦克风流
const stream = await navigator.mediaDevices.getUserMedia({
audio: {
sampleRate: 16000,
channelCount: 1,
echoCancellation: true,
noiseSuppression: true,
}
}); -
创建 AudioContext 并加载 Worklet
audioContext = new AudioContext();
await audioContext.audioWorklet.addModule('audio-processor.js');
audioWorkletNode = new AudioWorkletNode(audioContext, 'pcm-processor'); -
接收 PCM 数据并通过 WebSocket 发送
audioWorkletNode.port.onmessage = (event) => {
const { type, data } = event.data;
if(type === 'pcmData') {
ws.send(data.buffer);
}
}; -
音频格式说明
- Raw PCM，16-bit 有符号整型（Int16）
- 单声道（Mono）
- 目标采样率：16,000 Hz
- 无文件头，实时流式发送
⚠️ 注意：AudioContext 采样率可能不是 16k，Worklet 内部需重采样，否则后端 ASR 识别会有问题。
三、Electron 特殊处理
在 Electron 桌面端，有几个问题需要注意：
-
文件路径
const baseUrl = window.location.href;
const processorPath = new URL('./audio-processor.js', baseUrl).href;
await audioContext.audioWorklet.addModule(processorPath);
- 开发环境用
http://localhost:... - 打包后用
file://或相对路径
- 权限问题
- macOS 需在系统偏好设置允许应用访问麦克风
- Windows 需确保应用有麦克风访问权限
- 多次录音清理
- 停止录音前，关闭
AudioWorkletNode、AudioContext、MediaStream，避免内存泄漏或蓝屏。
四、总结经验
|---------------------|----------------|----------------------------|
| 技术方案 | 优点 | 缺点 |
| ScriptProcessorNode | 旧浏览器兼容，API 简单 | Electron 桌面端容易蓝屏，高 CPU 占用 |
| AnalyserNode | 可视化方便 | 音频质量差，噪声明显 |
| AudioWorkletNode | 高性能、低延迟、干净 PCM | API 相对复杂，需要打包路径处理，重采样需自己实现 |
最终选择：AudioWorkletNode
- 稳定性高
- 音频质量好，适合后端 ASR 或语音分析
- 支持实时流式发送，和 WebSocket 完美配合
五、经验建议
- 务必在 Worklet 内重采样，确保和后端期望采样率一致（如 16k）。
- WebSocket 发送时 ，保证数据是 Int16 ArrayBuffer，并按一定缓冲大小发送。
- 停止录音时，彻底清理 AudioWorklet、AudioContext、MediaStream，否则容易内存泄漏。
- Electron 路径适配 ：开发环境用
window.location.origin，打包后用相对路径或new URL()。
六、后续优化方向
- 音频压缩：可将 PCM 转成 Opus / WAV 再发送，降低网络带宽
- ASR 前端降噪：在 Worklet 内实现噪声抑制
- 断网重连：WebSocket 流式发送需考虑网络波动
七、总结
从 ScriptProcessor 蓝屏，到 AnalyserNode 噪声，再到 AudioWorkletNode 的稳定实现，这个过程充分说明了：
- Electron 桌面端录音需要 高性能音频处理
- AudioWorklet 是目前唯一稳定、可控、干净的方案
- 实现流式 PCM 发送需要关注 采样率、数据类型、缓冲大小
通过这套方案，我的桌面端录音功能在 Windows / macOS 都实现了稳定、低延迟、干净的实时音频传输。