[大妈吐糟] 虾米音乐的系列猜想

最新推荐文章于 2025-09-05 14:24:44 发布

weixin_33768481

最新推荐文章于 2025-09-05 14:24:44 发布

阅读量72

点赞数

CC 4.0 BY-SA版权

文章标签：数据库移动开发

原文链接：https://segmentfault.com/a/1190000002538467

本文详细记录了一位资深音乐爱好者在使用虾米音乐应用时遇到的一系列问题，包括播放顺序混乱、下载与播放冲突、专辑封面丢失、批量操作困难等。作者提出了解决方案，如直接使用用户上传的音乐文件表、优化元数据处理和多线程处理下载等功能，以提升用户体验。

88720847.jpg (600×368)

背景

习惯泛听的专辑顺序强迫症重症患者!

音乐历史:

从有条件配置录音机开始
上百盒带,几百CD,MP3CD
硬盘常备 30G+ APC
以往移动音乐习惯:
- iOS 用 podcast 下载有关频道的音乐
- Android 用自行上传的音乐,以 类别/音乐人/专辑 为目录形式组织
- 用内置播放器以目录为线索播放
- 管理/播放流程继续电脑中 cmus 的习惯
为制作大小丸子:"情人节快乐;-)" 才知道 xiami
- 变成移动音乐主力陪伴平台
- 下载过 900+ 专辑
- 播放 20000+ 首音乐

实际上定心使用 xiami 音乐应用,也经过了很长时间的折腾:

基本上,俺对手机上的音乐品质已经不报希望了,
只要求:

但是,以上三个基本需求,无一能在当前已知所有移动播放器中作到:

选择艺人, 只有 Google Play音乐基本作到舒心了:
- 点击进入 我的乐库 优先进入音乐人, 而不是其它 tab
- 所有卡片用的是现有专辑的拼贴
- 杯具的是, 从本地导入音乐的过程,以及目录是无法控制的
- 如果通过其它应用删除了相关音乐, GPlayer 是不知道何时能更新的
快速根据需要组合出当前播放清单, 没有应用能满足:
- 多数强行要求创建播放列表/精华没有7次以上的操作不可能完成
- xiami 还限定只能有 50 首音乐的上限制
- 这就很杯具了: 俺播放本地的音乐,为毛要限制俺的 playlist 长度?!
按照一张专辑接一张专辑,音乐依从专辑原有顺序播放
- 这应该是最吻合音乐人当初创意的音乐收听顺序了
- 但是,这竟然成为所有音乐类应用最不愿意实现的功能?!
- 为什么呢?! 细思恐极....

参考:

从 mpeg-1 时代开始, 音乐文件中就已经能包含完备的专辑/艺人/播放顺序的信息!

xiami 也好,其它音乐应用也好, 走的都是 ucg 模式,以便避开版权纠纷;

这就导致各家音乐库中的音乐文件本身 meta 信息混乱/不全
进一步的,为了避免在移动设备上进行大量的目录操作, 大家都将下载文件放在一个目录中
更加可悲的, 为了快速开发使用 SQLite 来管理所有音乐 meta 信息
综上, 导致了:
- 无法合理的触发下载/meta提取/刷新/使用时机
- 人为形成多重等待
- 并在错误的信息基础上,几乎无法进行合理的控制识别
最终形成类似情景:
- 根据音乐人信息, 从专辑列表,下载多个专辑后
- 在音乐人界面, 看到的就是这种专辑顺序混杂的情景
- 实际播放时,可以想象是多么难受的事儿
xiami 中还有一个诡异的现象是:
- 即使相关专辑都下载到了本地
- 但是,在一个专辑播放过程中
- 动态的从其它本地专辑界面,点击加入当前播放列表后
- 当播放追加专辑音乐时, xiami 不从本地播放,而是无视音乐已经下载的状态,尝试从网络中下载播放!
- 这得是什么样的脑洞经理,才作的出这种产品决策呢...

基于用户上传的音乐文件表直接使用:
- 根据官方的信息, 在服务端统一刷一下 meta 信息吧
- 并将相关 meta 信息,独立保存一下
- 在其它用户下载音乐文件的同时, 直接向客户端 push 对应的meta 信息, 就别生从本地文件中再遍历读取了吧
下载/管理/播放, 用多线程/进程来处理吧
- 最简单的,别将 meta 信息和其它控制信息放在同一 DB 中哪
SQLite 这货就是单用户单线程最轻量级DB
- 对于这种专辑信息,又不涉及交叉关系索引
- 就是用个内存 KV 效率也比用 SQL 高哪

总之, 亲, 大家喜欢 xiami 的音乐库, 努磨 SD 卡拼命下载了几千音乐到本地了

就让俺们愉快的自由播放 ,不好嘛?!