2 Commits

Include renames

Author	SHA1	Message	Date
lxh2875931338	98db2321fb	fix(playback): 冷启动不再预加载音频，首次播放按保存进度打开 ... 按今日日志定位：所谓"后台假死"其实是进程被系统回收 （13:14:46 ActivityManager: has died: prcp FGS，当时内存压力下批量杀进程）。 冷启动后旧代码会先联网 play→seek→pause，既慢又会和用户点播放打架。 - restorePlaybackState: 只恢复队列/进度/UI，不联网，不再调用 _loadRestoredPlayback - 新增 playOrResume(): UI 按钮、通知栏、耳机键统一入口； 冷启动首次播放走 _playCurrent（open + seek 到保存位置 + play） - AudioPlayerHandler.play() 改走 playOrResume() - 播放中每 10s 持久化一次进度，冷启动恢复更准确 - 窗口期收紧：网络轮询 10s→3s、切换去抖 3s→2s、 起播看门狗 15s→10s、中段卡死 30s→20s 真机验证（release）： 冷启动 8s 内 play 调用 0 次（不再预加载） 按键播放：冷启动首次播放 → open 21ms → restored position 15.751s → 1.5s 出声	2026-10-24 20:04:42 +08:00
lxh2875931338	b517c75cdd	feat(playback): 网络切换后自动重连当前歌曲 ... mpv 的 HTTP 长连接不会跟随网络迁移：换 Wi-Fi / Wi-Fi<->移动数据 会换掉出口 IP，旧连接失效但不一定报错，表现为进度停住、一直缓冲。 - 新增 NetworkWatcher：每 10s 枚举 IPv4 接口，签名变化即视为网络切换 （不依赖插件和额外权限，也能覆盖"同类型网络换 AP"的情况） - AudioService 收到变化后 3s 去抖，然后强制重连当前歌曲并 seek 回原位置 （force 参数跳过 2 分钟节流，因为这是明确的外部事件） 真机验证（公网链路 + 移动数据）： 21:43:23.123 检测到网络变化 21:43:26.124 主动重连（3s 去抖） 21:43:26.289 自动恢复完成（165ms） 随后 position 35.5s -> 41.7s 正常推进	2026-10-23 21:44:55 +08:00