体验地址：博客，github，npm前言博客上的音乐播放器，大部分看起来都一样，小，塞在页面的一角，在别人听阅读文章时听音乐可以增加某些体验的满意度指数。而我做了一件不同的事情：博客不就是给人看文章的吗？再次播放音乐甚至可能会降低阅读质量。听歌不好吗？既然要体验，那自己沉浸在体验中岂不是很爽？有一天，无意间打开了豆瓣FM的网页版，非常符合豆瓣的感觉，干净简洁。当然，网上也有很多类似的音乐播放，这也为我后面要做的事情埋下了伏笔。我的博客是用[vuepress]()搭建的，主题是vuepress-reco，一开始想找一个播放音乐的插件，于是就去awesome-vuepress，发现了唯一一个和音乐相关的插件，只有一个叫：vuepress-plugin-music-bar的插件.....还是个吧...有点失落。那么，没有人吗？那么……让我试试看？最后的效果图就是上面看到的四张图：明/暗歌词，明暗视觉解码。看了vuepress官网上的插件api，就开始动手了！无论页面如何绘制，初衷都是身临其境的体验。找了很多播放器的大体结构，还是觉得网易云的播放界面舒服一些。我曾尝试在脑海中画出播放界面，但最终还是选择了使用。网易云效果（给你带来）：左边黑胶唱片滚动，右边歌词滚动。目前不需要上一曲和下一曲，有播放和分享的按钮，大概是这样的：一天半，匆匆忙忙的搞定，之后发布了一个版本的npm包npm链接调试成功。便于使用？很难说。可以用吗？有能力的！这里优化完成后，有种身临其境的感觉，体验？复制它是一种很好的体验吗？不，还需要加点东西，比如可视化。这里特别感谢网易云前端团队的一篇文章：WebAudio在音频可视化中的应用，基本照着做，看了里面的文献，可以做出上面的效果。说实话，文献量真大。。。波长，正弦余弦，频域时域，奈奎斯特定理，还有什么快速傅里叶变换，头发都偷偷掉了。。。顺便附上一张截图adocument：但是你不看这些也能搞定！基本思路是：创建AudioContext，关联音频输入，解码，控制音频播放和暂停，创建分析器，获取音频数据（FrequencyData）和时域数据（TimeDomainData）设置快速傅里叶变换值，信号采样窗口大小，interval为32-32768，默认为2048创建一个音源，音源关联分析仪，分析仪关联输出设备（耳机，音箱等）获取频率数组，转换格式，然后使用requestAnimationFrame通过canvas绘制这些东西上面的文章写的很详细，我这种外行就不多说了。遇到的问题在npmlink之前使用npmlink时，依赖包没有三方/四方依赖，所以没注意到如果开发的npm包有其他依赖，那么应该在package中调试时的主项目。先将这些包添加到json中，这样就不会报resolvefailed之类的错误了。调试完记得断开npmunlink。接口本来想用网易云音乐NodeJS版的API，但是有些东西不好找。比如我需要songid,cover,lyrics，但是文档里没有songid去查albumid（cover在albumid里），只有A歌的详细信息，但是这个接口还是需要认证的和重定向...对于用户来说，我不需要让用户多做这么一步，而且很容易出错。所以我换了一个api：PaulAPI。这个API能解析的网易云歌没有那么多，不过一般的就够用了。唯一的缺点就是多频刷新会一直pending。应该是后台设置了ipfrequency。既然有问题，不使用接口行吗？尝试找到一个mp3文件来解析歌词和封面？找个jsmediatags仓库，可以解析ID3v2、MP4、FLAC等字段，可是……这不是给用户添麻烦吗？需要找到一个包含专辑、歌词、歌曲和艺术家信息的音频文件...如果我是用户，我不会使用它。想来想去，最后还是决定让歌曲的user传入，然后通过接口传入一个歌曲id，cover和歌词，歌曲就是传入的音频链接。使用方法如下：
