关注了下这几天的后续，酷狗音乐进行了像是“回旋镖”的回复，QQ 音乐本身并未回应，TME 这样的做法很厉害

网易云发这个文章，QQ 音乐也不明面在意，同时 QQ 音乐用户也几乎不可能因为这篇文章而转向使用网易云。反而舆论更多是在意网易云本身的版权、会员权益、软件体验问题等问题

所以这个文章对 QQ 音乐没什么大影响而网易云自身问题被放大地摆了出来，以及用户会说你网易云是否存在其他的问题，是否在搞热度，这不是高明的做法

其实音乐播放器这类的主流大致结构已经定型了，国内流媒体音乐的客户端研发可以说已经是过饱和了，在进行没什么意思的“创新”，也是大部分工具类软件面临的问题，同质化非常严重

对大厂来说，这些微小的“创新”，要复刻下简直毫不费力

这些天想着 SPW，其实怎么做就那个样子，有点道心破碎没啥意思

音视频播放器开发很无聊，说白了大部分时间就是在调库，主流的如调 FFmepg、BASS 等，安卓 ExoPlayer 那些，自己造这个轮子？一个人搞十年写得过 FFmpeg？难说

拿安卓来说，我现在重新写个没项目负担的，拿 Media3 做播放器，界面 Compose 糊弄下，播放界面完全抄 Apple Music，一个礼拜大体完成，一个月内做的漂漂亮亮的，没意思

谈这些也是觉得 SPW 没啥意思，每天搞得我很焦虑怕做得不好，每天把自己搞得太累不像一个 20 多岁人的样子，自己都讨厌自己，做软件这么多年心情也不好，钱也没有，还近视腰疼掉头发，不焦虑了

今年年中以来对软件一边测试一边开发开始有点反感，一个是青盐云听面临的开发精力有点崩溃，另外应该是回顾这些年各种软件测试面临的问题

如 Windows 一边修一边产出 Bug；小米发新系统测试版本引发大量问题；QQ/微信测试版本引发批评声音

是因为即便是测试版本，用户也会产生初始印象，而第一印象很重要

想明白了其实没什么，SPW 目前项目进度已经处于严重延期暂停，那就回顾这种“敏捷开发”吧今天直接发个测试版本出来，完全免费

做好心里预期：

1. 功能非常不成熟，同时大部分功能被我手动屏蔽
2. 软件使用的 UI 框架占用非常大，而且此框架本身存在一些泄漏问题，很容易 500 MB+ 内存占用或者爆内存
3. 测试版本可以传播，但不要修改测试版本，比如插入恶意木马、广告

测试版本会存在功能阉割

正式版本时间还是在 2025 年 Steam 首发

SPW 开发版 DEMO 群组：https://t.me/+iVn5ypF1xf80NGE9

设计目标：

SPW 的音乐库设计的非常特别的，设计理念几乎不同于任何现有的本地音乐播放器，用户在使用 SPW 时候更像在扮演一位流媒体音乐后台管理者，抛弃了围绕文件的设计，用户可以手动的添加自己想要的专辑、艺术家以至于这些对应的文件是否存在都没关系，音乐库可以设置的不受文件元数据影响

所以可以完全脱离传统的音乐标签，让对文件的元数据只是其中的桥梁，用户可以自己决定是否有联系

文件丢失与否也会在软件中标记文件无法读取而已，它不会影响到专辑、艺术家以及区分的都是，更不会影响听歌数据以及歌单

文件管理位置？可以自定义重新链接

想给专辑点个红心？给艺术家点个？都没问题

歌曲备注，专辑描述，艺术家头像等等多种数据都可以编辑

让用户完全掌握属于你个人的音乐库，而不是受限于歌曲是否在硬盘上，歌曲元数据是否编辑好了

甚至展望未来，可以指定此歌曲的文件来源于哪台网络设备，以什么呀方式加载（画饼）

SPW 抛弃传统音乐播放器做为一个扫描音乐播放音乐的工具，而是让用户创造音乐库链接音乐，用户自己的想法才是核心而非那些散落的文件

（测试版本没什么体现）

群组里群友的 AI 总结，比较明晰

其实也没啥创新点，主要是为了解决 Salt Player 这些年存在的痛点问题，文件移动了数据丢失了怎么办？封面读取不到元数据乱码怎么办？

这些都由用户决定，是否读取文件怎么读取还是自己编辑都是可以的

专辑、艺术家就是有收集的想法，创建不需要歌曲对应的都可以，自定义介绍、封面等等都可以

（不知道有没有前辈这样做了，我觉得这是我想到的一个不错的解决方法，正式版见）

（现在存在框架问题，解决太慢了，最近身体心理状态很一般，所以后续进度不要有太大期望，预计明年内吧，能上半年最好）

如果失败了就唱一首《淘汰》，只能说我输了

加入 SPW 测试群：https://spw.moriafly.com/changelog.html

Salt UI 发布了 2.3.0-alpha03

https://github.com/Moriafly/SaltUI/releases/tag/2.3.0-alpha03

SPW 1.0.803 演示版本 2024/12/04

## 亮点

### 内存优化

此版本的 SPW 内存占用得到了一些有效改进，预计降低 25% 左右，但目前框架依旧存在各种内存问题。

### 默认霞光特效

无封面歌曲会应用默认的霞光特效，同时改进了播放界面默认封面的显示效果。

## 新增

- 【歌曲】界面新增显示当前歌曲数量。
- 【歌曲】界面歌曲项添加了默认封面。
- 【关于】->【更多】界面添加了一些软件额外信息。

## 优化

- 模糊渲染性能。

## 修复

- 修复部分情况下歌曲列表封面缓存丢失的问题。

## 后续开发重点

- 修复播放器和界面问题。

https://spw.moriafly.com/release/1.0/803.html

这些天大部分时间还是投入在 SPW 的开发中，一些看似很简单的界面问题要耗费大量时间去解决，甚至某些到目前一点头绪都没。

SPW 是一个混合项目，目前一些重算法相关的也在试着用 C 等语言来实现，其实用处不大，内存占用更多是 UI 方面。

按照我自己的技术路线选择来说，Compose Multiplatform（CMP）不是一个差的选项，但目前来说 CMP 在桌面端的体验比较糟糕。JVM 本身性能很好，更多我还是觉得框架本身的问题。

让我回想起几年前椒盐音乐 V3 升级 V4 使用 Jetpack Compose 面临的压力，几年下来，Jetpack Compose 在一些小地方对我来说还是存在问题。

Jetpack Compose 开发很快但并不能说非常稳定会经常出现一些严重问题，而且对开发者要求更高，很容易不小心产生性能问题。我想回到几年前我可能会觉得不这么早使用。

谈回 CMP，JetBrains 对它的投入我觉得并不是很高，仓库看起来维护人员屈指可数。也许是更多的人员在开发 Fleet 吗？Fleet 并不是 CMP 而是另外一个内部的 UI 框架。

看到 JetBrians 25 年计划的重点应该在 iOS 的支持上，我也许应该考虑往 iOS 上靠拢，但又怕进入另外一个坑。对鸿蒙看法也是，需要谨慎考虑什么时候投入。过些时间有 B 站等技术人员在鸿蒙上使用 Kotlin Native 的分享直播，我多关注关注。

在人力和金钱都缺失情况下，为各种平台完全使用原生技术不现实，跨平台是必要的，希望 CMP 发展更好，我 SPW 大半年写了几万行代码不能都白费吧｡°(°¯᷄◠¯᷅°)°｡

1.0.830 Demo 2024/12/06 对比 1.0.803 演示版本。

亮点
1. 全屏模式
- 新增全屏模式，按钮位于软件标题栏最小化按钮左侧，开启可以让软件全屏显示，#1061。

2. 播放界面封面展开动画
- 新的播放界面封面展开动画，更连贯，同时优化了部分其他的动画效果。

优化
- 改进对读取失败的音轨的识别逻辑。
- 优化 DXGI 兼容模式下最小化、最大化等按钮样式。
- 优化了部分情况下标题栏关闭按钮的颜色。
- 优化点击播放错误时的错误捕获。

修复
- 修复快速点击上下首软件卡死的问题，#1056。
- 修复偶现的滚动歌曲列表崩溃的问题（预修复，待验证）。
- 修复部分新版 FLAC 编码文件无法播放的问题。

后续开发重点
- 修复播放器和界面问题。

https://spw.moriafly.com/release/1.0/830.html

这就是我选择的 Steam 原因？我自己都难绷。。。

Salt UI 发布了 2.3.0-beta01

https://github.com/Moriafly/SaltUI/releases/tag/2.3.0-beta01

（🤓到时候塞个俄罗斯方块、2048 或者来个小音游，对外宣称播放器是附带的）

1.0.862 Demo 2024/12/10
对比 1.0.830 演示版本。

亮点
1. 新启动逻辑
重复点击启动应用将不再启动软件新进程而是将已经存在的进程主窗体显示在最前，#1085，详见启动行为。

2. 升序降序
新增歌曲升序降序排序功能。

3. 垂直同步设置
新增垂直同步设置功能，详见外观 -> 垂直同步。

优化
移除迷你播放条的翻转动画。

修复
音量控制面板背景丢失，#1070。
当未载入歌曲的时候播放界面背景全透明，#1079。
播放界面标题文本行异常，#1080。
播放界面展开关闭动画打断偶尔无法快速触发，#1083。
重启软件不记录歌曲界面排序。
后续开发重点
修复播放器和界面问题。

https://spw.moriafly.com/release/1.0/862.html

10.7.0-alpha01-2024121101
移除主界面缩放和播放界面圆角
移除关于界面 Salt Player OPEN
修复一些小问题

有意义的是 10.7.0-alpha01 版本 Salt Player 使用的一些核心库已经完成了 Android/Desktop(Windows/macOS/Linux)/iOS 跨平台的迁移

很累但应该还行，加油开发

晚上洗漱刷朋友圈，看到有些喜欢的人有对象了，我还是和代码过吧

干活 Power

设计一种完全兼容 LRC 的真卡拉 OK 歌词格式，目的要对人类阅读、纯文本编辑非常方便，以及拥有极高的兼容性，处理各种 LRC 格式变种

以及在使用普通 LRC 的歌词时候应用一些技巧模拟卡拉 OK 歌词，对错误的时间戳拥有修复忽略功能

在功能上方便拓展，后期可以设计其他不太适合人类阅读的格式向 SPL LRC 的转换