zijunchiang
b40a2bdf9b
V1.5.1(重发): 修复"切歌→公放"在老设备（极米 H1S）上卡死
现象: 点歌列表切歌到公放列表，新设备正常，老设备（极米 H1S）卡死。
排查出三个叠加原因，且都是"新设备看不出来、老设备致命"的类型：
1. 切歌任务排在长任务后面（线程池饿死）
切歌用的是 MainActivity.io（固定 4 线程），而"点歌即下即播"(streamDownloadAndPlay)
这类几十秒的长任务也在同一个池里。H1S 网速慢，并发点几首歌就把池占满，
切歌任务一直排队 → 旧歌播完后没声、按什么都没反应。
修复: 切歌/随机续播改用专用单线程 randomPlayExecutor（守护线程），与下载彻底隔离。
2. 切歌时现扫目录找候选（慢 + 可能永久阻塞）
候选来自 localSongInventory() + library.scanLocal()：
- SongFileValidator 对每个文件在头尾各读约 4.3MB 做 TS 校验；
- scanLocal() 会遍历 /storage 各挂载点，老 ROM 上的失效挂载点会让 File.listFiles() 永久阻塞。
修复: 启动时后台预热候选缓存（独立守护线程 + scanWithTimeout 4s 超时保护），
下载完成即时补进缓存；切歌直接读缓存（零 I/O），缓存未就绪时只走安全的库存查询。
3. 主线程上做深度文件校验（直接 ANR）
Song.hasLocalFile() 内部就是 SongFileValidator.inspect（头尾各读 4.3MB），
却被用在 play()、播放错误回调、switchToLocalPlayback，
以及**逐行渲染**的 songRowState() 里 —— 而 advancePlayback 恰好会调 renderQueue()。
H1S 的慢存储上，队列每行一次深度校验就是数秒卡顿。
修复: 播放/渲染路径统一改用廉价检查 hasPlayableLocalFile()（只看存在与大小），
深度校验只保留在后台（localSongInventory() / isDownloaded()）。
顺带修掉一个自己踩的坑: Kotlin 块注释会嵌套，KDoc 里写 /storage/* 会开启嵌套注释导致
KDoc 不闭合、后续代码被吞（报错为 Unclosed comment + Missing '}'）。已改写为不含 /* 的说法。
版本名保持 1.5.1（按用户要求撤回后重发同一版本），versionCode 32 → 33（保证可覆盖升级）。
签名证书不变。测试 8 例全通过。
2026-09-26 22:33:36 +08:00
..
2026-09-04 21:23:21 +08:00
2026-09-26 22:33:36 +08:00
2026-09-26 22:33:36 +08:00
2026-09-04 21:23:21 +08:00