我低估了音频波形在浏览器中处理的难度。
几个月前，我以为在浏览器中显示音频波形只是一个周末项目。<p>我错了。<p>第一个原型在处理短音频片段时运行良好，但当我尝试加载几个小时长的录音时，一切都崩溃了。<p>内存使用量激增。<p>用户界面变得无响应。<p>缩放操作非常痛苦。<p>甚至生成波形峰值所需的时间也超出了预期。<p>让我最惊讶的是，真正的挑战并不是解码音频，而是高效地渲染和管理大量的时间线数据。<p>我最终尝试了 Web Workers、IndexedDB 缓存、虚拟化渲染和渐进加载策略，只为保持浏览器的响应性。<p>对于那些构建过基于浏览器的音频工具的人：<p>你遇到的最困难的性能瓶颈是什么？<p>是解码、渲染、内存管理，还是完全不同的东西？
查看原文
A few months ago I thought displaying an audio waveform in the browser would be a weekend project.<p>I was wrong.<p>The first prototype worked fine with short audio clips, but everything fell apart when I tried loading recordings that were several hours long.<p>Memory usage exploded.<p>The UI became unresponsive.<p>Zooming was painful.<p>Even generating waveform peaks took longer than expected.<p>What surprised me most is that the actual challenge wasn't decoding audio. It was rendering and managing huge amounts of timeline data efficiently.<p>I ended up experimenting with Web Workers, IndexedDB caching, virtualized rendering and progressive loading strategies just to keep the browser responsive.<p>For those who have built browser-based audio tools:<p>What was the hardest performance bottleneck you encountered?<p>Was it decoding, rendering, memory management, or something else entirely?