Optimize WEB source auto-selection with concurrent probing after sour…

[black4der]

背景 / 动机

在日常使用 Animeko 的过程中，我发现一个比较明显的体验问题：在线播放源的加载、筛选和切换速度有时会比较慢。尤其是在某个源加载失败之后，系统往往还会等待较长时间，才继续切换到下一个源重新缓冲和加载。实际使用中，这种等待有时会持续十几秒，甚至接近 20 秒，对播放体验影响比较明显。

基于这个问题，我尝试自己做了一些优化。因为我并不是长期维护这个模块的开发者，所以不确定所有实现细节是否都是最优解，但就我目前的本地测试结果来看，整体播放前的等待时间明显缩短了，而且没有再频繁遇到“长时间卡住后才失败切源”的情况。如果实现思路或代码风格和项目现有方案有不一致的地方，也欢迎指出，我可以继续配合修改。

改动内容

这次改动主要针对 WEB 源的自动选择逻辑，核心目标是减少用户在播放前等待“慢源 / 失效源”的时间。

主要变化

1. 保留现有“优先使用上一次播放源”的思路

   • 如果上一集已经使用过某个 WEB 源，下一集仍然优先考虑它

2. 不再过早开始测速

   • 先等待可用源被筛选出来
   • 只有在可用源达到一定数量，或者候选源已经基本稳定后，才开始并发探测

3. 将原先偏串行的 WEB 探测改为并发探测

   • 默认并发探测多个可用 WEB 源
   • 如果部分源失败，会继续使用后续候选补位
   • 每个源最多只尝试一次，避免死循环

4. 测速标准

   • 先解析到可播放地址
   • 再对解析后的真实播放地址做一个短暂的下载采样
   • 对于 m3u8，会尽量下钻到真实分片进行采样，而不是只测 manifest 本身
   • 这样可以避免“解析很快但实际播放很慢”的源被错误选中

5. 探测超时

   • 复用现有“视频连接解析超时”设置

6. 新增并发探测设置

   • 在播放偏好中增加 WEB 并发探测数量配置
   • 默认值为 5
   • 最低可以设置为 1(会退化为串行探测)

实现说明

这次改动只作用于 WEB 源快选逻辑，不会改变“在线优先 / 下载优先 / 混合模式”这些原有播放模式本身的策略。

整体逻辑可以概括为：

• 先等待候选 WEB 源真正进入可用列表
• 以“上一次播放源优先”为基础排序
• 从当前可用源中取最多 N 个候选并发探测
• 对每个候选执行：
  • 解析可播放地址
  • 对可播放地址做短下载采样测速
• 从成功候选里选择综合耗时最优的源
• 如果某些源失败，则继续从后续可用候选中补充尝试
• 如果最终全部失败，则退回现有兜底逻辑

测试情况

自动化测试

已补充并通过相关定向测试，包括：

• 保持上一次播放源优先，但若其明显更慢，仍可切换到更快源
• 某个源解析更快但真实下载更慢时，不再错误优先选中它
• 手动选择相关测试仍然通过

手动测试

我在本地做了以下验证：

• macOS 桌面端直接运行测试
  • 体感上播放前等待明显变短
  • 当源加载完成并完成测速后，实际播放和后续加载速度都很快
• Android debug 包进行功能验证
  • 功能表现符合预期
  • 但 debug 包本身流畅度不如正式版，这更像是 debug 构建类型带来的差异，不一定是这次逻辑修改导致

可能需要关注的点

• 这次实现偏向“先提升用户真实播放体验”，如果项目对 WEB 源探测策略有更明确的长期设计，也欢迎继续调整
• m3u8 的测速目前已经尽量下钻到真实分片，但不同站点实现差异较大，后续也许还有继续细化的空间
• 并发数目前已经做成可配置项，如果后续需要，也可以继续围绕默认值和上限做调优

结论

这次 PR 的目标比较直接：减少用户在 WEB 播放前等待慢源、坏源的时间，并尽量更快地拿到“真正能播而且实际速度更好”的源。

就我目前的本地使用和测试结果来看，这个方向是有效的，也明显改善了我自己在实际使用中的体验。

[StageGuard]

感谢贡献。
因为 Media Selector 涉及到播放体验的核心链路，我们需要确保这个环节不能出现致命问题。
PR 的内容太大了，你可以考虑拆分一下并分次提交吗（2-3 次）？这样可以减少我们的 review 复杂度并且更详细地说明你的改动，也可以方便我们理解你对播放体验改进的心路历程和想法。

[StageGuard]

Since this PR is inactive, I will set the state to Draft.