DEV6 主要修一些特别扎眼的响应式 bug，配 CI，写 Readme，不打算做新功能
写完项目中期汇报，从社区收点意见之后再接着做
DEV 5 周期 TODO：
[ ] 实现 About Page
[ ] 实现工具栏自定义功能
[X] 实现新的 Cover Art 缓存机制
[X] 系统媒体控制功能集成 Cover Art 显示
[X] 实现新默认 Cover Art
[ ] 部分格式 Metadata 读取与写入异常Читать полностью…
[X] Mix Page Cover Art 查询混乱
[X] 进度栏标题布局错误
[X] 排查推荐系统输出异常的问题
[X] 修复音量控制异常的问题
讲一下我做的设计，我这里需要高速 cover art 查询，因为每一个文件查 cover art 的方式都不一样而且 parse metadata header 再提图，还要确保格式正确之类的很麻烦，所以我把所有 cover art 全都缓存到数据库里了，用的时候直接查表提文件。
关于为什么不像有些播放器的实现，把 cover art 提前提取出来跟媒体文件放一个目录里，我是觉得这样会污染用户目录，很恶心。
关于为什么不放 .rune 目录里，因为毕竟它还是一大堆很小的文件，全都堆在一起用户迁移的时候复制会很崩溃。
所以我最后选择了一个会恶心我但是不会恶心用户的方法，在程序启动的时候创建一个临时目录，查到哪个 cover art 就从数据库里面提哪个文件存临时目录里，再把 path 交给 dart，但这个过程很绕……
现在每个有可能会取到 cover art 的 API 都会返回一个 bake_cover_art 的选项，如果是 true，就会把 cover art 从数据库里面提出来，放硬盘上回传地址，我在想有没有更优的做法。
这种实现带来的最大问题是，四处都得处理 bake 的条件判断……
因为喜欢二次元，所以去了日本，结果却发现日本之所以二次元发展蓬勃，是因为所有人都在逃避现实
充分证明了一件事，复杂度不会凭空消失，只会转移，我只是把所有的复杂度全都压缩在了一个 API 里，结果就是这个 API 内部已经没法看了……
Читать полностью…
我们都知道，哪怕脑子想不清楚，也要先开始做，不实际做根本不会知道自己会往什么方向走；我们也知道，如果架构歪了就要重构，不要迁就缔造屎山。
我都知道，但是……超大型重构还是好痛……
https://detail.tmall.com/item.htm?id=688678897844
要不要给我的 beepy 配个这玩意接耳机……
