12 个月又如流水般过去了，是时候停下脚步，回顾一下这段历程了。
工作成果
今年音流一共更新了 13 个版本，相比去年的 23 个版本，数量上有所退步。
究其原因，一是每次的更新内容比之前更为丰富，不像之前更新几个小问题就要发布一个版本（美其名曰快速迭代），二是开发也进入了深水区，一直在自己所不熟悉的领域摸爬滚打，阻力也会更大一点。
而且最近这段时间自己也有些懈怠，需要调整一下状态。
总体而言，我对目前的开发速度还算满意。虽然版本号涨的不多，但很多实用功能确实已经实打实落地了。
比如现在可以在 Windows 端使用了，并且也简单适配了桌面端的操作逻辑：
甚至连 macOS 也拥有属于自己的界面：
Android TV 自然也拥有自己的操作逻辑：
除了平台适配外，以下几个功能的落地我也觉得蛮重要的：
- 直连模式
- 多资料库切换
- 增加可播放的歌曲格式（mpv的功劳）
直连模式可以让曲库较多的人从同步歌曲数据的地狱中解放出来，多资料库切换则方便了像我这样需要不停在不同资料库切换的人。增加支持播放的歌曲格式自不必多说，谁会嫌播放器支持的歌曲格式太多呢？
虽然我个人是比较推崇
flac + mp3这样的曲库的~
除此之外，我还做了一些个人觉得比较有特色的小功能，不知道你觉得如何：
- 重复歌曲检测——这对我这样的强迫症来说简直是一大福音，如果曲库中有重复歌曲，我一搜搜到好多个，我就该纠结该常听哪个版本，索性一删了事。
- 生成歌词翻译——有时听到喜欢的外国歌曲，却不得其意还是挺难受的，有了这个功能就可以免除这个烦恼。
- 已听标记——没有听过的歌曲序号是绿色，这样听有声书时就不会忘记听到哪一集了，配合歌曲定位功能就可以很快找到上次听的位置了。
除了功能上的增加与改进，代码层面相比去年末的时候可以说又有了翻天覆地的变化：
- 使用
flutter_rust_bridge连接 Rust 代码，用 Rust 跑一些性能要求比较高的任务（如图片模糊），兼容性要求比较高的任务（如 HTTP 请求，DLNA 发现）都是非常合适的。 - 通过
melos管理工作空间，将不同的逻辑拆分到不同的项目中，明确分工，降低后续开发时的理解成本。 - 使用
bloc进行状态管理，将显示层和控制层的逻辑分离，细化更新区域，避免一个状态变化导致整个页面刷新的情况出现。
其中第 2 条和第 3 条的工作还在进行中，现在的代码量已经挺大了，想要完全重构还是需要花费不少时间的。但我相信，重构完成后，应用整体的性能应该会上一个档次。
一年来的成绩
现在这个时间点从谷歌搜索「音流」二字，软件官网已然排名第一了，GitHub 的文档仓库也有了超过 1k 的星星了。
很难想象一年前还没有「音流」这个词语，一个偶发的点子，加上时间的发酵，我竟然创造了一个新词！虽然只在小众领域存在，但也足够让我骄傲了～
音流能取得这样的成绩，用户的自发宣传有着非常大的作用。
没错，就是自发宣传，除了音流第一个版本我在小众软件的那篇推广文章之外，我没有主动联系过任何推广事宜（当然，别人有主动联系过我的）。
有时看到一些阴谋论的评论说那些博主收了推广费的，我就忍不住想笑——我是真穷啊，推广费确实付不起～
其实我不主动推广自己的软件还有一个原因，自己在客户端开发方面算是个新手，到现在为止音流还是存在各种各样的兼容性问题，我很难说服自己把这样的作品推广给别人使用。
现在我在酷安、小红书、什么值得买、少数派、微信以及 B 站上搜索「音流」二字，或多或少都能搜到推荐音流的文章，每当我敲代码敲累的时候，去搜搜看这些文章，就感觉自己又充满了干劲。
今年音流的会员价格随着 1.3.0 的发布上涨了 10 元，我已经做好涨价之后购买会员的人数大幅度下降的心理准备了，结果发现似乎和涨价前并没有太大的区别，这也让我放下心来。
销量的大起大落对一个软件的长期发展来看肯定不是好事，我更喜欢细水长流，这样我能一直保持维护这个软件的兴趣，不至于因为销量的大起大落而（可能）丧失开发这个软件的初心。
最近音流在 App Store 国区音乐分类免费排行榜霸榜了快一个月了，虽然一直在前 200 徘徊，但也是之前没有发生过的事情。
猜测原因，可能是前不久发布的 飞牛 OS 带来的影响吧。再联想到小米的 NAS 也在调研中了，可能国内的 NAS 市场将来会有一小波的扩张？总之这对音流，对 NAS 用户来说都是好事。
提到应用商店，原计划今年上架安卓应用商店的，伴随着自己不断的拖延，终究是一个商店都没有成功上架，这件事我需要检讨。
明年的话，必须得提出明确的上架计划和步骤，勇于面对麻烦，及时公布当前上架进度。
下一年的规划
我是一个及其没有耐心的人，向不同的用户解释同一个问题会让我觉得烦躁。所以音流官网是以文档形式呈现的，我希望用户能够看完文档还有疑问的话再来提问，不过很显然，我的希望算是落空了。
站在用户角度来看，使用软件前先看文档确实不合常理。这也是音流做的不够好的地方，软件内的使用引导近乎为 0，自己特意做的一些奇思妙想在用户看来反而成了问题所在。
所以明年的话，我会做以下两件事情：
- 加强软件内使用引导，尤其是一些非常规操作逻辑。
- 开设音流公众号，自动回答一些常见问题，同时写一些软件使用教程。
在开发音流的直连模式之后，我就十分认同元数据管理是服务端的工作，客户端只需要负责展示数据就好了。这样做分工明确，用户体验也会更好。
奈何现有的服务端要么没有提供接口文档，要么提供的接口能实现的功能十分有限，非常限制我的一些奇奇怪怪的点子的发挥。
所以现在的我迫切想要打造一款专属于音流的服务端，我可以根据自己的需要去修改接口。不过也要承认，同时开工服务端和客户端会分散我的时间和精力。
总之先把服务端的第一个版本做出来吧，我先把自己需要的功能做出来，如果用户有其他需求，则需要依靠开源社区的力量来改进了（如果有大佬愿意的话）。
以下是我预想中音流服务端应该具有的一些特点：
- MIT 开源协议，欢迎社区贡献以及其他客户端适配。
- 使用 Rust 语言编写，音乐服务一般运行在 NAS 这样的性能较弱的机器上，运行效率越高使用体验越好。
- 数据库使用 Postgres，考虑到管理大容量曲库的需要，数据库的性能也必须要好一点。
- 支持设置多个分区，分区类型有歌曲和播客。
- 支持修改文件标签，最好能在网页端做到 mp3tag 这个桌面软件近似的使用体验。
- 服务端保存播放列表，以实现没有数量限制的播放列表。
当然这些并非全部，我只是想说明一点，做一个专属于音流的服务端是非常有意义的，这并不是在浪费时间，我会尽量做到仅用直连模式实现目前一些需要用媒体库模式才能做到的事情。
除此之外，上架安卓应用商店也必须提高优先级了。第一个准备上架华为应用商店，并不是我偏爱华为，只是它的车机系统只能安装商店里的应用。
准备上架的时候，我会按照它的要求，把自己目前进行到的步骤公布出来，算是在鞭策自己不能害怕麻烦，不能偷懒吧。
如果能成功上架第一个国内应用商店，那再去上架其他应用商店对我来说应该就驾轻就熟了。
回归眼前
今年又搬了一次家，换了一个城市生活。回想自己毕业这五年多来，已经换了四个城市了，漂还是我比较能漂的哈～
我感觉自己的适应能力真的挺强的，无论是南方的潮湿还是北方的干冷，无论是阵阵海风还是滚滚热浪，我都没有出现水土不服的情况。感觉如今唯一能考验我适应能力的就是西藏的高原反应了，不过我可不会傻到再搬到西藏去住个一年半载的，最多去旅个游，人还是要有敬畏之心的～
今年六月份的时候去过一次长白山，那里的空气挺好的，湿湿的凉凉的，呼吸起来很新鲜，让人感觉非常舒服。当地人服务态度也挺好的，毕竟是个旅游城市，也发展这么久了。只是可惜去山上的那天下雨了，天池没看成，只记得看了个一片浅绿色的湖，一个贼长的从起点绕回起点的林间步道后就匆匆下山了，完全没有任何体验。这趟旅途可以总结为饱了肺福，没饱眼福，而我又比较喜欢看美景，其他项目只能算加分项，所以总体来说感觉自己踩坑了。
经过这两年的努力，音流的开发也慢慢走上了正轨，我也可以真正确定独立开发者这个身份了。其实从大学开始，当我知道有独立开发者这个职业的时候，我就把它当作自己理想中的职业了——可以专心做自己喜欢的事，与人打交道也不需要拐弯抹角，最重要的是，不用物理层面的上班了。
从那时起自己就在朝这个方向努力了，捯饬过便宜的虚拟主机，参加过算法比赛，尝试做过安卓软件。毕业后的工作，前端后端也都做过，搞过微信小程序，也又有过一次失败的 APP 上架经历。
总之那时的工作说不上多差，就是感觉不怎么顺心，闲的发慌，数着日子拿工资那种感觉，好像后续的人生能看到头了。我决定寻求一次改变，事不过三，我的自制力并不强，大学时做安卓软件半途而废了，工作时趁业余时间做苹果 APP 卡在最后一步了。那么最后我想再试一次，辞职专门做一件事，看自己究竟是不是做独立开发者的料子。
破釜沉舟，不是就趁早认命。
所幸这不留退路的尝试没有令我失望，我现在确实可以依靠自己开发的 APP 的收入养活自己了。这两年做音流这个软件感觉是充分发挥了我各种语言会而不精的特点：
- 需要一次开发多平台运行？Dart 语言学起来！
- 需要多平台恢复会员身份？会员服务器搞起来！
- 需要更好的运行效率？Rust 语言学起来！
- 需要苹果端的原生功能？Swift 语言走起来！
- 需要安卓端的原生功能？Kotlin(Java) 语言走起来！
- 需要Windows端的原生功能？抱歉 C++ 真玩不明白～
总之到现在我也不认为自己是什么大佬（可能就是因为会而不精吧），我比较注重实际，需要什么我再去学什么用什么，不过在 Copilot 的辅助下倒也够用。
如果说我对新的一年有什么展望的话，那就是做大做强哈哈。
评论区