不要糖醋放椒盐

Salt UI 发布了 2.3.0-beta01 https://github.com/Moriafly/SaltUI/releases/tag/2.3.0-beta01

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

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

这些天大部分时间还是投入在 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 大半年写了几万行代码不能都白费吧｡°(°¯᷄◠¯᷅°)°｡

SPW 1.0.803 演示版本 2024/12/04 ## 亮点 ### 内存优化 此版本的 SPW 内存占用得到了一些有效改进，预计降低 25% 左右，但目前框架依旧存在各种内存问题。 ### 默认霞光特效 无封面歌曲会应用默认的霞光特效，同时改进了播放界面默认封面的显示效果。 ## 新增 - 【歌曲】界面新增显示当前歌曲数量。 - 【歌曲】界面歌曲项添加了默认封面。 - 【关于】->【更多】界面添加了一些软件额外信息。 ## 优化 - 模糊渲染性能。 ## 修复 - 修复部分情况下歌曲列表封面缓存丢失的问题。 ## 后续开发重点 - 修复播放器和界面问题。 https://spw.moriafly.com/release/1.0/803.html

Salt UI 发布了 2.3.0-alpha03 https://github.com/Moriafly/SaltUI/releases/tag/2.3.0-alpha03

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

（现在存在框架问题，解决太慢了，最近身体心理状态很一般，所以后续进度不要有太大期望，预计明年内吧，能上半年最好） 如果失败了就唱一首《淘汰》，只能说我输了

群组里群友的 AI 总结，比较明晰 其实也没啥创新点，主要是为了解决 Salt Player 这些年存在的痛点问题，文件移动了数据丢失了怎么办？封面读取不到元数据乱码怎么办？ 这些都由用户决定，是否读取文件怎么读取还是自己编辑都是可以的 专辑、艺术家就是有收集的想法，创建不需要歌曲对应的都可以，自定义介绍、封面等等都可以 （不知道有没有前辈这样做了，我觉得这是我想到的一个不错的解决方法，正式版见）

设计目标： SPW 的音乐库设计的非常特别的，设计理念几乎不同于任何现有的本地音乐播放器，用户在使用 SPW 时候更像在扮演一位流媒体音乐后台管理者，抛弃了围绕文件的设计，用户可以手动的添加自己想要的专辑、艺术家以至于这些对应的文件是否存在都没关系，音乐库可以设置的不受文件元数据影响 所以可以完全脱离传统的音乐标签，让对文件的元数据只是其中的桥梁，用户可以自己决定是否有联系 文件丢失与否也会在软件中标记文件无法读取而已，它不会影响到专辑、艺术家以及区分的都是，更不会影响听歌数据以及歌单 文件管理位置？可以自定义重新链接 想给专辑点个红心？给艺术家点个？都没问题 歌曲备注，专辑描述，艺术家头像等等多种数据都可以编辑 让用户完全掌握属于你个人的音乐库，而不是受限于歌曲是否在硬盘上，歌曲元数据是否编辑好了 甚至展望未来，可以指定此歌曲的文件来源于哪台网络设备，以什么呀方式加载（画饼） SPW 抛弃传统音乐播放器做为一个扫描音乐播放音乐的工具，而是让用户创造音乐库链接音乐，用户自己的想法才是核心而非那些散落的文件 （测试版本没什么体现）

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

谈这些也是觉得 SPW 没啥意思，每天搞得我很焦虑怕做得不好，每天把自己搞得太累不像一个 20 多岁人的样子，自己都讨厌自己，做软件这么多年心情也不好，钱也没有，还近视腰疼掉头发，不焦虑了 今年年中以来对软件一边测试一边开发开始有点反感，一个是青盐云听面临的开发精力有点崩溃，另外应该是回顾这些年各种软件测试面临的问题 如 Windows 一边修一边产出 Bug；小米发新系统测试版本引发大量问题；QQ/微信测试版本引发批评声音 是因为即便是测试版本，用户也会产生初始印象，而第一印象很重要 想明白了其实没什么，SPW 目前项目进度已经处于严重延期暂停，那就回顾这种“敏捷开发”吧今天直接发个测试版本出来，完全免费 做好心里预期： 1. 功能非常不成熟，同时大部分功能被我手动屏蔽 2. 软件使用的 UI 框架占用非常大，而且此框架本身存在一些泄漏问题，很容易 500 MB+ 内存占用或者爆内存 3. 测试版本可以传播，但不要修改测试版本，比如插入恶意木马、广告 测试版本会存在功能阉割 正式版本时间还是在 2025 年 Steam 首发