佐伯楽

> Hey guys, anny follow on this issue? > @SauloNunes 😢 Sadly, I have no more progress, and I give up at last. Because some packages like `xfonts` `libdbus` can't...

Hi, sorry for I responded late. Please follow the instruction of the Bug Report template and provide the basic information, so that I can confirm how the problem happened preliminary....

@JavaCS3 感谢！不过 60MB 对于一个插件来说确实不算小了。无论是整合进插件本身，还是启动后下载，个人感觉用户体验都没有很大的提升。因为在执行播放动作前，都需要用户进行操作或等待，并且为了稳定的网络访问，可能还需要镜像服务器。 BTW，我还发现了一个有趣的插件：https://github.com/auchenberg/vscode-browser-preview ，借助 Chrome Headless（本机仍需安装 Chrome，不过我感觉这几乎是大部分程序员的标配）在 VSCode 内嵌入一个全功能浏览器，这样也无需用户手动启动浏览器了，并且插件体积也比较容易接受（vscode-browser-preview 10MB）

@JavaCS3 Chrome Headless 的优势是不需要所有人都下载前置依赖，劣势是内存占用70MB，远大于 ffplay 的 6MB 内存。我觉得这里的问题是在于权衡用户是更能忍受 60MB 前置依赖的下载时间，还是更能忍受 70MB 的内存占用。

@JavaCS3 不知道还有没有更小一些的工具，ffplay 还内置了GUI/绘图等操作，而且还有一堆不太需要的解码器。实际情况下，我觉得只需要支持一小部分的音频格式就行了。 --- 我觉得用 Golang 处理这件事不错，编写简单、容易维护还跨平台，单纯只解码播放MP3也许可以做到足够小巧。目前的一些简单的检索结果： * https://github.com/hajimehoshi/oto * https://github.com/lieff/minimp3

@JavaCS3 这个我理解，不过我不太了解 ffplay 的源码实现，不知道其剔除依赖的工作量有多大。我想的是将平台相关的播放部分和音频解码剥离开，播放部分单独找个小型库，解码部分单独找库，由 Golang 串联起来进行编译，这样可以尽可能的小一些，实现也不复杂，还有一部分自行定制的能力和空间。

@muyichenfeng 就之前的讨论来看，个人目前比较倾向于 @ouuan 的方式，默认仍然通过浏览器进行播放（或 Chrome Headless），由不介意等待依赖下载和安装的用户自行配置希望使用的音频播放工具。

@LottoDog 他这个只是一个音频文件的包，没有写配置。语音包配置文档：https://saekiraku.github.io/vscode-rainbow-fart/#/zh/voice-packages.md

@LottoDog 文档有标注（ https://saekiraku.github.io/vscode-rainbow-fart/#/zh/#%E5%BC%80%E6%BA%90%E5%8D%8F%E8%AE%AE ）@JustKowalski

感谢反馈，总结需求来看，似乎是对程序员工作状态进行一个大致的评估然后进行相应的反馈？ P.S. 😂我害怕这个功能被人事盯上，改成绩效分析插件……