myDV

myDY 技术解构：TV 直播这条“窒息赛道”上的深呼吸

项目背景与痛点

先说说那句 slogan：“保持深呼吸！”。做过电视直播类应用的开发者都懂，这五个字本身就是一句自嘲。直播源的生命周期常常只有几天甚至几小时，今天还流畅的 4K 源，明天就变成 404 或者一串无限转圈。用户点开应用看到黑屏的一瞬间，血压最先升起来的是开发者。

myTV-android/myDY 瞄准的正是这个问题：如何在“源不可控”的前提下，把用户体验做成可控的。传统 TV 直播 App 的通病是把一切押在“源列表”上——源一挂，整个产品等于归零。myDY 的思路则相反，它更像一个源治理与调度系统，播放器只是链路的最后一环。这个定位差异，决定了它必须啃下几个硬骨头：异构订阅格式的归一化、失效源的低成本探测、多线路秒级切换，以及在低端电视盒子（1GB RAM、老旧 S905 芯片）上仍然保持可用的内存与渲染预算。

换句话说，它要解决的核心问题不是“能不能播”，而是“源烂成什么样，用户还能看得下去”。

核心技术揭秘

从架构气质上看，myDY 是典型的 MVVM + 单向数据流，Kotlin 打底，播放内核大概率落在 AndroidX Media3（ExoPlayer 的继任者）之上。整个系统可以切成三条纵线：源接入、频道治理、播放调度。

几个值得展开的设计判断：

其一，解析层与仓储层是解耦的。 M3U8 带 #EXTINF 元信息，TXT 往往是“频道名,url”这种裸数据，格式混乱程度超乎想象。myDY 用 SourceParser 做归一化，输出统一的 Channel 实体后写入 Room，而不是在播放时临时解析。这意味着列表页的滑动性能与源解析性能互不干扰，也天然支持“离线浏览频道表”——这一点在源服务器抽风时价值极大。

其二，失效反馈是个闭环。 注意图中的 DeadLinkReporter：播放失败不是简单弹个 Toast，而是把失败事件回写到源路由层，对该线路做降权。这是一个轻量级的信誉积分模型，用失败次数而非复杂算法来排序候选线路。它不需要机器学习，但足够有效，而且计算开销可以忽略——这正是电视盒子上最需要的“廉价智能”。

其三，播放器被刻意做薄。 Media3 只负责解码与渲染，缓冲策略、重试次数、超时阈值全部由上层 PlayerEngine 控制。好处是可观测：每一次 onPlayerError 都能被翻译成业务语义（是 DNS 失败？是 4xx？还是解码器不支持？），从而决定“重试同线路”还是“切换到下一条”。这类判断如果塞进播放器内部，就成了黑盒。

功能亮点与差异

对比同类项目，myDY 的杀手锏不在于功能数量，而在于几个“体验断点”的处理：

• 多源聚合而非单源依赖：允许同时挂多个订阅源，把候选频道池做大，从概率上稀释单源失效的影响。
• 线路切换的连续性：换线时不重建页面，播放状态机保持在同一个 ViewModel 作用域内，视觉上接近“无感切换”。
• 对老旧设备的克制：不追求花哨动画与 Material 3 大动效，列表用轻量适配器，图片加载走缓存优先策略。这种“减法”在 TV 端反而是差异化竞争力。
• 配置可迁移：源与频道表以结构化数据存储，便于备份与跨设备迁移，这对重度用户是刚需。

应用场景与落地建议

适合的场景很明确：家庭电视盒子、老人机顶盒、局域网内自建直播网关的前端。如果你要做的是点播平台或者商业 OTT，它并不是一个好的基座——版权、鉴权、CDN 调度这些企业级需求它并不覆盖。

生产环境落地有几点必须留意：

1. 源质量直接决定口碑。务必建立外部健康检查（比如定时脚本探活 + 自动剔除），不要指望客户端兜底。
2. 控制换线风暴。多线路并发探测要限流，否则在弱网下会引发雪崩式重试，反而拖垮播放。
3. 注意合规边界。直播源的内容合法性由使用方负责，这一点在商用前必须厘清。
4. 给低端设备留降级通道。建议在设置里暴露解码器切换（硬解/软解）与缓冲档位，把选择权交给用户。

综合评价

优点：架构分层清晰，源治理思路务实；对失效源的闭环反馈设计是同类项目里少见的“工程感”；对低端硬件的性能预算控制得当，属于真正为 TV 场景打磨过的实现。

短板：它本质上仍是“源的搬运工”，源本身的稳定性无法被架构解决；EPG 与回看能力受限于源提供方，天花板明显；此外项目文档与二次开发指引偏薄，新贡献者的上手成本不低。

一句话总结：它不是让你不再遇到坏源，而是让你遇到坏源时不至于骂娘。在一个注定不完美的赛道里，能把“不完美”处理得体面，本身就是一种功力。深呼吸，然后继续调那条线路——这大概就是这个项目最真实的气质。