uni-app App端无法实时绘制录音波形，因getRecorderManager()不提供PCM数据流且onFrameRecorded事件不支持；需通过原生插件提取频域能量值后轻量渲染。
uni-app App端为什么不能直接用 canvas 实时绘制录音波形
因为 App 端（iOS/Android）的 uni.getRecorderManager() 不提供原始 PCM 数据流，只返回临时文件路径；而波形图依赖实时采样点（如每 20ms 一组幅值），没有原始音频帧就无法生成动态柱状或线条图。
常见错误现象：onFrameRecorded 在 App 端始终不触发，或回调里 frameBuffer 为空——这不是代码写错了，是平台限制。
- 微信小程序支持
onFrameRecorded，但 App 端（包括 HBuilderX 打包的 apk/ipa）不支持该事件 - App 端只能走「录完再解析」路线：先保存为
.mp3或.aac，再用 WebAssembly 或原生插件解码提取 PCM - 纯 JS 解码（如
ffmpeg.wasm）在 App 端性能极差，首帧延迟常超 3s，不适合语音消息场景
推荐方案：用原生插件预处理 + 小数据量频谱模拟
真正能落地的做法，是绕过“实时波形”，改用「轻量级频谱映射」：不还原真实波形，而是根据音频能量分布生成近似视觉反馈。这既满足 UX 需求，又规避了 App 端的解码瓶颈。
实操建议：
- 录音完成后，调用原生插件（如
uni.requireNativePlugin('AudioAnalyzer')）快速提取 32–64 个频段的能量值，返回数组如[0.12, 0.45, 0.88, ...] - 前端用
uni.createCanvasContext绘制柱状图，每根柱子高度 = 对应能量值 × 最大高度（如 80rpx），刷新频率控制在 15fps 以内 - 避免使用
echarts渲染频谱：它初始化重、内存占用高，在低端安卓机上易卡顿甚至 crash - 若无原生插件能力，可退化为「伪波形」：按播放进度线性生成 20–30 个随机波动值（带平滑插值），配合音频播放状态同步启停
uni-app 中频谱图渲染的三个关键兼容点
同一个绘图逻辑，在不同端表现差异极大，尤其容易在真机上失效。
- iOS App：
canvas的drawImage不支持直接绘制audio标签，必须转成base64或本地临时路径后才能贴图 - Android 旧机型（如骁龙625）：
context.fillRect超过 40 根柱子就会掉帧，建议上限设为 32，并关闭抗锯齿（context.imageSmoothingEnabled = false） - H5 端需注意：音频文件路径若为
http://，会被浏览器阻止读取音频数据，必须走https或本地file:// - 所有端都禁止在
onReady阶段立即绘图——canvas dom 可能未挂载完成，务必加nextTick或setTimeout(..., 0)延迟
为什么不要自己实现 FFT？
看到网上很多教程教用 JS 写 FFT 算法来解析音频，但在 uni-app App 端这是典型“高投入低回报”操作。
- FFT 计算本身不难，但输入必须是等长、对齐、无压缩的 PCM，而 App 端拿到的录音文件几乎全是 AAC/MP3，JS 解码精度和速度都不达标
- 即使硬解成功，单次分析耗时常达 800ms+，用户点“播放”后要等近一秒才出第一帧波形，体验断裂
- 原生层已有成熟音频分析库（如 iOS 的
AVAudioEngine、Android 的Visualizer），插件调用一次即可返回频域能量数组，效率高出两个数量级 - 如果你团队没有原生开发人力，建议直接接入已验证的商业插件（如 DCloud 插件市场里的
audio-spectrum-analyzer），比自研稳定得多
真正的难点不在怎么画，而在怎么让数据来得快、来得稳——其它都是修修补补。
