侧边栏壁纸
博主头像
贯耳症博主等级

瓜虫冬匕ing……

  • 累计撰写 69 篇文章
  • 累计创建 49 个标签
  • 累计收到 902 条评论

目 录CONTENT

文章目录

2024 年中回顾

贯耳症
2024-05-07 / 17 评论 / 6 点赞 / 2,505 阅读 / 2,439 字
温馨提示:
本网站有 CDN 缓存,一般刷新 3 次左右即可获取最新页面。

讲个鬼故事 👻,2024 已经过完一半了~

突然发觉自己已经好久没有更新过博客了,所以趁此机会,自说自话一下。

近期见闻

最近在我所了解的新闻中,Vidhub 开始收费算是最热闹的事情了。

我记得自己第一次用 Vidhub 好像是好几年前了吧,具体记不清楚了,不过当时似乎不支持连接媒体服务器,所以简单试了下就没用过了。直到最近我才重新安装回来,毕竟可以直连 Emby 了。

但免费了这么久感觉挺不容易的,还是 5 个人的团队。所以在可以购买之后我就立刻买了,一是浅表支持,二是这可是早鸟优惠啊,Infuse 买不起 88 我还花不起嘛~

不过看他们群里用户的反馈,感觉这次收费的决策确实是有失误的地方,我觉得最关键的一点是,之前一直是免费的,现在开始收费之后,一是强制升级,二是不购买播放三次就不能继续播放了,这肯定和大部分用户的心理预期是不同的。

既然是从免费转到付费,那之前的功能即使不能全部使用,也应该让部分基础功能可以免费使用,比如连接网盘免费播放或连接媒体服务器免费播放之类的,或是限制免费播放的媒体格式都行,结果他们偏偏选择了不购买完全不让用……这和我之前逛 DS Player 在 App Store 的评论区大家吐槽的某个点似乎很像……

他们虽然会接受建议,但收费这么重要的事,具体应该怎么做,不应该深思熟虑之后再推出吗?

说到这就不得不夸一下自己做的音流了,写的第一篇推广文章就明确表示后续有收费计划,收费功能上线之后也只有极少的用户来反馈相关问题,且几乎没有吐槽付费、恢复购买的方式不合理的。

这不禁让我对这个软件的前途充满了担忧,所以最近我找了个备胎 SenPlayer 哈哈,目前只有 iOS 能用,希望后续至少能在苹果全家桶上运行。


除了 Vidhub,另一个新闻就是网易竟然下场做网盘/NAS视频播放器了!名字叫 Filmly,我没下载试用,但听体验过的人说毕竟是第一个版本,还有很多不完善的地方。

但是,这可是大厂啊,难道要对我们这些小开发者形成降维打击了吗?我已经开始瑟瑟发抖了,音流才刚刚起步啊,会不会没过几个月大厂的竞品就要出来了?

现状

当时为音流定下买断制的付费策略时,其实内心还是很忐忑的,怕这个圈子太小,怕越到后期就越没有收入。但至少从这几个月的情况来看,每个月的付费用户数量还算稳定,勉强达到我之前上班时的收入水平了(初级程序员),暂时还是可以支撑我继续完善这个软件滴。

另外,可能是幸存者偏差吧,在音流的付费用户当中,安卓用户要稍微多于苹果用户,这可能和大家一直以来的认知是不同的(一直以来我也从未引导用户用安卓购买或是其他渠道购买)。

尽管最近这段时间付费用户数是持平的,但总体来说安卓付费用户数量是要多于苹果用户的,而且支付宝的抽成只有 0.6%。

所以啊各位大佬开发者们,别再只为苹果开发软件了,安卓用户也值得更多更好用的软件~

安卓容易被破解在我看来不算理由,如果你做的是跨端软件,某一两个平台被破解其实也还能接受。只要这个软件的生命周期足够长,定价没有过于离谱,也还是会有破解用户逐渐转正的,至少我是这样的。

觉得开发多个平台成本太高的话可以用 Flutter 开发呀,开发的时候可以顺便开源几个好用的轮子好让我白嫖哈哈哈~~


最近在 1.2.8 为音流更换了新的播放插件,音乐格式的兼容性确实提升了,但却遇到了一些新的问题,部分在 1.2.9 解决了,但还有一些问题需要时间慢慢处理。

1.2.9 开发的直连模式真的比想象中要艰难,因为软件内的每个操作都需要去找对应服务端的接口,最难处理的就是服务端没有这个接口的情况,然后就要去抉择是要禁用这个功能还是通过变通方式实现。

媒体库模式则得益于这次直连模式的改造,终于是支持了我拖了好久的歌曲分页功能,以后打开歌曲列表的速度那会是嗖嗖滴~

活动预告

1.2.9 开发完成之后,下个版本就是 1.3.0 了,在下个版本中,我将加入对安卓 TV 的支持,允许同时在线的设备也将增加 1 台达到 7 台。

在 1.3.0 上线后的两周内,会有第二波的早鸟优惠,降价 10 元左右,优惠期结束后会在 48 元的基础上涨价 10 元左右。

这应该就是我所设想的软件做活动的节奏,不会随着春节之类的节日而变动,而是跟随软件自己的生命周期而变动,虽然这样子看起来有些死板,但我是个死脑筋,我坚持哈哈~

测试版本发布频道

随着使用音流的用户数量不断增加,每次发布新版本,为用户提供稳定的使用体验就变成了至关重要的事情。

因此新开设 devmusic.aqzscn.cn 作为测试版本发布频道,每个测试版本不一定会放上所有平台的安装包,且安卓只提供通用版本的安装包(这意味着与之前使用的安装包架构不同会导致无法安装的问题)。

对于 iOS 版本想要抢先体验新功能的用户,请通过邮件申请 TF 测试名额:

邮箱:aqzscn@qq.com
主题:申请音流 TestFlight
内容请包含(缺一不可):

  1. 会员购买凭证(Apple 的邮件收据截图或支付宝的订单购买记录截图,需包含订单号信息)
  2. 接收邀请的邮箱
  3. 常用的音乐服务器类型

发送邮件之后请耐心等待,我会定期处理这些申请。

一些设想

在这次开发直连模式的过程中,我愈发觉得这些服务端提供的接口不合我意,我急需一个可以任由自己改造的服务端来实现我对一个音乐客户端的所有构想,而不是在现有接口的基础上缝缝补补,做出各种妥协依旧达不到我想要的效果。

因此我打算在现有服务端的功能都适配差不多之后,开始着手开发一个音流专属的音乐服务端,采用 Rust 语言编写,原因是我对 Rust 一无所知,而我又很想通过 Flutter_Rust_Bridge 这个项目,去用 Rust 跑一些原生的代码,一是提高音流的性能,二是可以利用 Rust 丰富的开源生态来增强音流的功能。

因此,这个音乐服务端也将承担我学习 Rust 的重担。这个音乐服务器将会开源,采用 MIT 协议,专注于管理音乐数据,欢迎大佬们的贡献。

那么第一步就是起个名字,Rusic 似乎不错,Rust 和 Music 各取一部分,就是读起来有些费事,摸优z克?优z克?原谅我英语是个渣渣 😭。

音乐森林 music_forest, 音乐海洋 music_sea 这类名字似乎也还行,不过没有 Emby, Plex 这种一个单词的读着顺口。造中文词简单,造英文词难啊~

如果要简单一些,把「音流」倒过来似乎也不错:留音。只是该对应什么英文呢挺头疼的。

所以,你有更好的名字推荐吗?


此外,今年已过半,是时候做一些除了开发之外的事情了,比如一次旅游,成立公司用于上架国内安卓应用商店,希望一切都能朝着更好的方向发展吧~

6

评论区