1. 为什么电视端需要一个“聚合播放终端”以及它解决了什么问题做电视端聚合播放这个想法在我脑子里转了挺长时间。客厅里那台电视装了一堆视频App但真要晚上坐下来看点东西的时候反而不知道该点哪个A平台买了这部剧没资源B平台有资源又得再开一个会员很多老片子翻遍几大平台都找不到。后来我干脆自己搭了一个智能电视影视大全方向的全能影音聚合播放终端把在线内容、本地NAS、下载目录和收藏记录全部收拢到一个界面里。这个终端不是简单地把几个App的口令拼在一起而是把“找片、选源、播放、续播”这四件事统一处理。折腾完整个项目之后我最直观的感受是电视端缺的从来不是资源而是一个能把这些资源理清楚的入口。这篇文章就把整个项目从思路、选型到落地、调优的过程写出来。想给电视盒子做点定制内容、或者正在做Android TV应用的朋友可以直接照着里面的链路走。如果你只是想给自己家的电视做一个好用的播放终端这里的思路和坑也能帮你少踩一轮。1.1 电视端观影的核心痛点不是没资源而是找不到、切不动先说第一个痛点资源孤岛。现在内容平台越来越多但内容库是彼此隔离的。想看一部老电影一线平台可能只有标准国语版字幕和外语音轨都不全小众平台可能有完整版本但画质又不行。用户被迫在几个平台之间来回切换等把片源找齐了观影兴致也磨没了。第二个痛点是遥控器操作。手机端可以搜索、可以用语音输入电视端大部分时候还停留在“方向键确认键”的交互上。很多视频应用把移动端的瀑布流直接搬到电视上焦点乱跳、列表没有记忆、搜索键盘烦到怀疑人生。我用过一段时间手机投屏投屏本身能解决一部分资源问题但一来手机不能随便离开二来投屏的控制逻辑不稳定经常出现视频在手机上控制、电视上播放延迟的情况。这些场景叠加起来才让我下决心自己做一个聚合终端而不是继续在各个应用之间来回“手动路由”。1.2 对比单独装App、手机投屏、聚合终端的实际差别我把自己试过的几种方案整理了一下区别其实非常明显方案找片效率播放稳定性续播体验维护成本每台电视装多个视频App低平台内容互相隔离高各玩各的差每个App记录独立基本为零但选择成本高手机投屏/推流中手机上找好再推不稳定取决于AirPlay/推送协议一般手机端和电视端记录割裂低但使用体验割裂自建聚合播放终端高统一搜索和分类高播放内核统一控制好一个数据库记录全局续播需要做源维护和版本迭代单独装App的问题不是不能看而是“决策成本”太高。晚上八点打开电视想着“今晚随便看点什么”结果在十几个图标之间来回切换光选片就选了二十分钟。手机投屏则把问题搬到了手机上电视变成一块单纯的显示屏幕它没有真正参与内容组织。聚合播放终端的价值是在不改变内容来源的前提下把“选择”这个环节收回到一个统一的入口里你在同一个界面搜索、同一个界面选源、同一个界面继续上次没看完的剧播放结束的进度也由同一个数据库记录。体验层面的提升非常明显动手做之前我也没想到一个入口能把家庭影院的可用性拉高这么多。1.3 我定义的目标形态聚合、检索、播放、记录一盘棋这个项目的目标形态我一开始就定成了四件事聚合、检索、播放、记录。聚合是把各种来源的内容统一成同一种数据结构检索是在聚合后的数据上做统一搜索播放是让所有内容都走同一个播放内核记录是把观看历史和续播位置统一存起来。这四件事缺一不可。如果只做聚合和检索那只是个“目录工具”点进去还是调用外部播放器如果只做播放和记录那又回到单平台播放器的老路上。只有四个环节一起打通才算得上“全能影音聚合播放终端”。后面讲技术选型和搭建过程也都是围绕这四个环节展开的。2. 技术选型播放内核、容器方案与数据流设计技术选型这部分我没有做什么特别激进的选择反而尽量用社区维护比较稳定、电视端兼容性好的方案。原因很简单电视端不像手机用户不会三天两头更新App也不好接受频繁出问题后“重启试试”。选型的时候稳定性优先级高于新特性。2.1 播放内核ExoPlayer是电视端最稳的起点播放内核我最终选了AndroidX Media3里的ExoPlayer准确说就是现在的Media3 ExoPlayer。对比过IjkPlayer和系统自带的MediaPlayerIjkPlayer在本地局域网播放和部分RTSP流上确实有优势但它现在维护节奏慢升级到新系统后问题也比较多。系统MediaPlayer虽然省事但封装层太黑想控制缓冲策略、日志、解码器选择就很费劲。用ExoPlayer最直接的收益是三点。第一它把缓冲、加载、出错状态都暴露成事件我可以根据这些事件做自动切源和失败重试这是MediaPlayer做不到的。第二它对HLS、DASH、SS这些流媒体协议的支持都内置了不用我再引入一堆第三方库。第三它在Android TV盒子上硬件解码适配做得不错大多数1080P和4K片源都能平滑播放。如果你的项目里有比较多本地局域网或者特殊直播流的场景可以把IjkPlayer作为备选内核一起封装但主内核我还是建议ExoPlayer。两个内核封装成同一个播放接口切换时只需要替换实现类上层UI和业务逻辑都不用动。2.2 源适配层把所有“不可控”挡在外面聚合终端最大的技术难点不是播放器本身而是“源”。在线内容的格式千奇百怪有的直接给一个MP4链接有的是M3U8直播流有的是JSON接口返回一串分集数据还有的是网页里需要解析才能提取的视频地址。如果把这些差异直接铺到业务层代码会腐烂得很快。我的做法是加了一个适配层叫SourceAdapter。每一类源实现同一个接口输出统一的数据模型MediaItemModel。这个模型里包含标题、封面、简介、类型、年份、集数列表、播放地址、清晰度列表、字幕地址等字段。上层界面只认这个模型完全不关心数据来自哪里。public interface SourceAdapter { String getSourceId(); boolean isAvailable(); MediaListResult fetchMediaList(String category, int page); MediaDetailResult fetchMediaDetail(String mediaId); ListPlayUrl resolvePlayUrls(String mediaId, String episodeId); }这样做的好处非常明显。新增一种内容源时我只需要新增一个适配器接入解析逻辑注册到适配器列表里点播、搜索、更新记录的功能全部自动生效。聚合终端的“聚合”二字本质上是靠适配层实现的而不是靠把所有逻辑写在一个巨大Activity里。2.3 元数据封面、简介、集数列表的统一管理聚合之后下一个问题就是元数据从哪来。有的源会返回很完整的标题、简介、海报图有的源只给个标题和播放地址简介、海报都需要补。我的方案是分层处理优先用源自带的数据缺的字段用后台补充任务去填。后台补元数据时可以抓取豆瓣/IMDb这类公开信息源但要注意频率不要对第三方站点造成压力也不要保存不该保存的数据。封面图管理这块我直接用Glide做加载和磁盘缓存。电视端封面通常要比手机显示得大很多分辨率低了模糊分辨率高了又占内存所以我让Glide统一按电视UI需要的尺寸裁剪并且开了diskCacheStrategy.ALL。不过实测发现如果图片服务器不稳定缓存策略再强也没用后面我会在性能调优部分细说。数据存储方面我用的是Room数据库。观看历史、收藏列表、续播位置、源配置这四类数据全部落本地。没有做账号系统因为是家庭场景一个电视盒子一个数据库就够了。3. 搭建过程实测从空壳工程到可点播的核心链路选型完成之后我直接搭了一个Android TV工程的空壳包名就叫tv.tvplayer.aggregator。这里不打算把每一行代码都贴出来工程代码量太大贴出来反而看不了重点。我更想把从空壳到“能正常点播”这一路最关键的几个实现节点讲清楚。3.1 遥控器焦点与电视UI第一道坎也是最容易返工的坎Android TV和手机最大的区别就是交互模型。手机是触摸电视是焦点。焦点处理不好哪怕功能再完整用户也想卸载。Android官方提供了一套Leanback组件BrowseFragment、DetailsFragment、RowsSupportFragment这些专门用来做电视端界面。我建议直接用Leanback别自己造列表控件。但Leanback也不是银弹。它默认的焦点样式比较死板卡片放大和阴影效果需要自己调。这里有几个关键参数调好之后手感完全不一样dimen namelb_basic_card_activated_animation_duration150/dimen dimen namelb_basic_card_activated_scale_factor1.06/dimen焦点缩放动画时长控制在120到180毫秒太长显得拖沓太短会感觉生硬。缩放倍数建议在1.04到1.08之间千万不要超过1.2否则相邻卡片会被挤得乱七八糟。另外焦点状态下的阴影一定要用Z轴高度的变化不要用setPadding模拟那样会在滚动时产生严重的性能问题。我在第一版里就是用的Padding模拟焦点效果结果在低端盒子上滚动列表时候明显掉帧后来改成setElevation之后流畅度立刻上来了。既然提到了代码里贴一个示例public class FocusableCardView extends androidx.cardview.widget.CardView { Override protected void onFocusChanged(boolean gainFocus, int direction, Nullable Rect previouslyFocusedRect) { super.onFocusChanged(gainFocus, direction, previouslyFocusedRect); animate().scaleX(gainFocus ? 1.06f : 1.0f) .scaleY(gainFocus ? 1.06f : 1.0f) .setDuration(150) .start(); setElevation(gainFocus ? dp(8) : dp(2)); } }3.2 搜索与选集聚合做得不好就是纯摆设搜索是聚合终端里最容易做砸的功能。做砸的典型表现是搜索结果出了几十个同名词条但用户不知道哪个源能播、哪个源是高清。我的做法是搜索结果按“可播性”排序。先在数据库里查本地记录和收藏再查已配置的在线源最后把搜索命中的条目统一展示并且对每个条目标注来源和清晰度。选集列表也是电视端的操作重灾区。列表太长遥控器一格格按下去非常痛苦。我的做法是两级设计默认按剧集分组展示用户按“只看简介”时收起剧集列表剧集列表支持“跳转页”模式直接输数字跳集。选集焦点还要记住上次看得位置这一点放到体验调优部分细说。搜索输入框则直接用系统软键盘虽然体验一般但胜在兼容性最好不用自己写一个电视端键盘。3.3 多源切换与失败重试机制聚合终端一定会有“这个源挂了换一个源再播”的需求。我实现的逻辑分三档第一档是播放开始前预检用户点击播放时先快速请求播放地址发现超时就直接标记该源不可用并尝试下一个第二档是播放中出错通过 ExoPlayer 的Player.Listener.onPlayerError捕获错误如果错误类型是网络或IO层问题就自动切到备用源继续播第三档是手动切换详情页放一个“播放源”按钮用户自己选择源和清晰度手动切换记录会被存为偏好下次优先选同一个源。自动切源有一个非常关键的细节切换源之后要从上次的播放位置继续而不是从头播放。很多播放器实现切源时都会把这个逻辑做丢用户切个源之后又得手动拖进度条体验大打折扣。我在切源时会把currentPosition保存下来等新源拉流成功后直接seekTo到对应位置。4. 聚合源接入能用什么、失效规律与合规边界聚合终端的成败很大程度上取决于“现在聚合了什么源”。但源的接入也是一件需要持续维护的事情不存在一劳永逸。这一节讲一下源的分类、接入方式和我在合规方面采用的实际策略。4.1 源的类型、生命周期与日常维护源大体分成三类。第一类是本地媒体库也就是家里NAS、老旧硬盘上的电影和剧集SMB和WebDAV协议都可以扫到这类源最稳定几乎不需要维护。第二类是有公开API或官方Feed的在线内容源比如一些提供开放接口的影音站点、播客、公开课平台通过API拿到数据后直接播放稳定性也不错。第三类是网页型内容需要从页面结构里提取播放地址这类源最容易失效页面改版一次就要重新适配。第三类源失效是常态不是例外。我维护的时候发现平均每隔两三个月就要检查一遍解析规则通常都是网站改版导致选择器失效。我的做法是给每个源适配器加一个“健康度”指标根据请求失败率、平均响应时间、连续失败次数自动打分分数低于阈值的源在界面上自动降级排序避免用户每次点开一个坏源。4.2 嗅探、API与解析三种接入方式的取舍接入方式大致有三种嗅探、API、解析。嗅探是指在设备端通过抓取网络请求找出网页中的真实播放地址。这种方式实现成本低但非常脆弱而且容易被站点反制。我一般只在本地自建服务或者实验室环境里做嗅探测试不会把它当成日常使用的接入方式。API方式是最稳定的。源方直接返回JSON格式的数据包括标题、封面、剧集、播放地址。缺点是能提供公开API的内容源并不多很多要你自行申请授权。解析方式介于两者之间通过加载源站页面用正则或XPath提取播放地址。选择器写得好效率很高但源站页面一旦改版就会失效。如果要做强烈建议在适配层增加“选择器配置化”让选择器规则可以在本地配置里热更新而不是每改一次都发新版本。4.3 版权与合规我采用的实际策略这一部分我必须说清楚。聚合播放终端的开发过程中一定会遇到“要不要接入第三方未授权内容”的选择。我的原则是只在自己有使用权的范围内做测试和验证具体来说有三条。第一个人本地媒体库只存自己拥有版权或获得授权的内容。家里人拍的家庭录像、买的数字拷贝、有授权的下载内容都在这个范围内。第二在线源只接入有公开授权或明确允许聚合的站点。第三解析和嗅探只使用在自有站点或测试环境中不用于绕开任何平台的付费墙、访问限制、版权保护措施。做技术研究和做内容分发是两回事。技术本身是中性的但聚合终端的实际使用场景必须守住边界。如果你准备把这个项目长期维护下去这一块的自觉性比任何代码实现都重要。5. 性能与体验调优解码、预加载与焦点记忆电视盒子的性能跨度非常大旗舰盒子能跑4K高码率老盒子连1080P都卡。所以调优不是简单地把参数调到最高而是让终端能感知设备能力自动选择合适的解码和缓冲策略。5.1 电视设备差异大优先保流畅还是保画质我的终端里加了一个“解码能力探测”逻辑启动时检测设备的解码器支持列表、内存大小和CPU核数生成一个能力等级。能力等级高时默认允许4K分辨率和更激进的预加载能力等级低时自动把默认清晰度降到1080P并关闭背景模糊、动画特效这些拉高负载的UI元素。画质和流畅度之间电视端场景我倾向于优先保流畅。客厅里的观看距离通常在2到3米720P和1080P在这个距离上感知差异不大但卡顿会立刻被感知。唯一例外是本地局域网或NAS里的高码率片源这种场景用户可以自己手动切到4K原画。5.2 网络加载、缓存目录与存储空间管理在线播放的体验很大程度上取决于预加载策略。我用DefaultLoadControl配置了一组比较保守的缓冲参数最小缓冲3秒最大缓冲15秒缓冲低于1.5秒时开始补加载。这个参数在大多数家庭宽带下表现都不错不会短时间预载过多导致带宽占用也不会因为缓冲太小频繁loading。缓存目录要认真管理。ExoPlayer的缓存和Glide的图片缓存在同一块存储空间里如果不限制大小用几个月就能把盒子撑爆。我的方案是视频缓存限制2GB图片缓存限制200MB超过之后自动按LRU清理。清理时还要注意避开正在播放的文件。存储空间不足时优先清图片缓存再清最久没看的视频缓存。5.3 断点续播与焦点记忆细节决定“像不像正规App”断点续播是聚合终端最值得做的功能之一。我的实现是把观看进度实时写入Room数据库每15秒写一次退出播放页面时再强制写一次。下次点开同一个媒体时自动从上次位置继续播放并弹出一个“已从xx:xx继续播放”的提示条。如果用户倾向于从头看提示条上也可以手动选择从头播放。焦点记忆包括两层。一层是垂直列表的焦点比如用户看了“电影”分类退出再回来时还停在“电影”分类而不是回到默认的“首页”。另一层是横向列表的焦点比如用户在某一行里选中第10部影片回来后焦点尽量还停在那一行附近。这个功能看起来不起眼但一旦习惯了再用别的App就会觉得很别扭因为很多甚至是大厂的电视App也没做这层记忆。6. 联调与稳定性验证踩坑、修复和上线前检查做完功能之后真正的麻烦才开始。电视App的稳定性验证比手机严格得多因为用户不会像手机用户那样频繁换机也不会因为某个版本有bug就去写差评他们会直接卸载。下面几个坑都是我在真机联调阶段踩过的。6.1 真实盒子上的卡顿与异常崩溃第一个坑低端盒子上的内存溢出。电视盒子的内存通常只有1到2GB系统还要占掉一部分。第一版我用Glide加载封面时不限制尺寸结果每次滑动瀑布流内存就涨最后卡死。后来把封面加载改成了“显示分辨率下采样”并在列表滚动停止之后再进行图片加载这个问题就基本消失了。第二个坑播放过程中的硬件解码线程崩溃。这个崩溃不是我们App代码的问题而是部分盒子的视频解码器对特定编码格式不兼容导致系统进程崩溃。解决办法是捕获MediaCodec.CodecException然后自动切换到软件解码器。软件解码吃CPU但至少能保证视频播得出来。第三个坑音频直通和采样率切换。很多盒子接功放音频输出格式会随片源变化。某些片子没声音是因为音频直通时没有通知功放切换采样率我在这里加了一层AudioManager.setPreferredDevice的逻辑并在播放器初始化时先探测音频输出设备能力。6.2 超时、重试与网络探测的平衡聚合源的网络环境千差万别有的源响应慢但能播有的源响应快但实际拉流失败。所以要区分“连接超时”和“读取超时”。连接超时设置8秒太长了电视用户没耐心我统一压缩到4秒。读取超时设置成15秒低于这个值会导致大文件预加载时频繁超时。重试策略上我采用最多重试1次而且只在首次播放失败时重试。用户手动切源时不做自动重试避免切源后还是坏源变成“无限转圈”。网络探测放到统一入口里做也就是开机或者从后台返回时用 TCP 快速通道探测已配置的源站点是否可达可达性数据用来更新源的展示顺序。这样用户看到的列表前面永远是最可能能播的源。6.3 崩溃日志、线上监控与后续扩展上线前的最后一步是崩溃日志收集。电视端不像手机那么容易连USB调试所以我会在App里内置一个崩溃日志模块捕获到未处理异常后写入本地文件下次启动时通过用户允许的通道上报。上报通道我用的是自建且受控的接口没有接第三方统计SDK因为电视盒子上很多统计SDK反而带来额外耗电和隐私争议。日志内容只包含崩溃堆栈、设备型号、系统版本、播放器状态这几项绝不包含用户观看记录和家庭网络细节。这一块隐私边界做得越保守越少给自己找麻烦。后续扩展方向我目前在做两个。一是把源适配器做成可配置的脚本化规则这样源失效时不用天天改代码发版直接在规则管理界面更新即可。二是加一个“局域网多端同步”的功能让家庭里几台电视共享同一份观看历史和收藏表。同步方案还在自测阶段准备用局域网发现协议加手动配对不上云不经过第三方服务。最后分享一个小技巧。如果你也在做电视端的聚合播放器一定要把“播放记录”当成核心功能排在优先级最高的位置。我见过很多技术很强的人做了很漂亮的聚合界面但唯独忘了续播这个功能结果用户每次打开都得重新找片源、重新拖进度条体验完全撑不起来。一个播放终端是不是真正“全能”很多时候不是取决于它接了多少个源而是取决于它有没有把“这次看到哪里了”这件事做好。 
长河君 · 2026/10/7 22:32:26 · 阅读 1.2k 打造全能影音聚合播放终端：ExoPlayer与源适配实战
1. 为什么电视端需要一个“聚合播放终端”以及它解决了什么问题做电视端聚合播放这个想法在我脑子里转了挺长时间。客厅里那台电视装了一堆视频App但真要晚上坐下来看点东西的时候反而不知道该点哪个A平台买了这部剧没资源B平台有资源又得再开一个会员很多老片子翻遍几大平台都找不到。后来我干脆自己搭了一个智能电视影视大全方向的全能影音聚合播放终端把在线内容、本地NAS、下载目录和收藏记录全部收拢到一个界面里。这个终端不是简单地把几个App的口令拼在一起而是把“找片、选源、播放、续播”这四件事统一处理。折腾完整个项目之后我最直观的感受是电视端缺的从来不是资源而是一个能把这些资源理清楚的入口。这篇文章就把整个项目从思路、选型到落地、调优的过程写出来。想给电视盒子做点定制内容、或者正在做Android TV应用的朋友可以直接照着里面的链路走。如果你只是想给自己家的电视做一个好用的播放终端这里的思路和坑也能帮你少踩一轮。1.1 电视端观影的核心痛点不是没资源而是找不到、切不动先说第一个痛点资源孤岛。现在内容平台越来越多但内容库是彼此隔离的。想看一部老电影一线平台可能只有标准国语版字幕和外语音轨都不全小众平台可能有完整版本但画质又不行。用户被迫在几个平台之间来回切换等把片源找齐了观影兴致也磨没了。第二个痛点是遥控器操作。手机端可以搜索、可以用语音输入电视端大部分时候还停留在“方向键确认键”的交互上。很多视频应用把移动端的瀑布流直接搬到电视上焦点乱跳、列表没有记忆、搜索键盘烦到怀疑人生。我用过一段时间手机投屏投屏本身能解决一部分资源问题但一来手机不能随便离开二来投屏的控制逻辑不稳定经常出现视频在手机上控制、电视上播放延迟的情况。这些场景叠加起来才让我下决心自己做一个聚合终端而不是继续在各个应用之间来回“手动路由”。1.2 对比单独装App、手机投屏、聚合终端的实际差别我把自己试过的几种方案整理了一下区别其实非常明显方案找片效率播放稳定性续播体验维护成本每台电视装多个视频App低平台内容互相隔离高各玩各的差每个App记录独立基本为零但选择成本高手机投屏/推流中手机上找好再推不稳定取决于AirPlay/推送协议一般手机端和电视端记录割裂低但使用体验割裂自建聚合播放终端高统一搜索和分类高播放内核统一控制好一个数据库记录全局续播需要做源维护和版本迭代单独装App的问题不是不能看而是“决策成本”太高。晚上八点打开电视想着“今晚随便看点什么”结果在十几个图标之间来回切换光选片就选了二十分钟。手机投屏则把问题搬到了手机上电视变成一块单纯的显示屏幕它没有真正参与内容组织。聚合播放终端的价值是在不改变内容来源的前提下把“选择”这个环节收回到一个统一的入口里你在同一个界面搜索、同一个界面选源、同一个界面继续上次没看完的剧播放结束的进度也由同一个数据库记录。体验层面的提升非常明显动手做之前我也没想到一个入口能把家庭影院的可用性拉高这么多。1.3 我定义的目标形态聚合、检索、播放、记录一盘棋这个项目的目标形态我一开始就定成了四件事聚合、检索、播放、记录。聚合是把各种来源的内容统一成同一种数据结构检索是在聚合后的数据上做统一搜索播放是让所有内容都走同一个播放内核记录是把观看历史和续播位置统一存起来。这四件事缺一不可。如果只做聚合和检索那只是个“目录工具”点进去还是调用外部播放器如果只做播放和记录那又回到单平台播放器的老路上。只有四个环节一起打通才算得上“全能影音聚合播放终端”。后面讲技术选型和搭建过程也都是围绕这四个环节展开的。2. 技术选型播放内核、容器方案与数据流设计技术选型这部分我没有做什么特别激进的选择反而尽量用社区维护比较稳定、电视端兼容性好的方案。原因很简单电视端不像手机用户不会三天两头更新App也不好接受频繁出问题后“重启试试”。选型的时候稳定性优先级高于新特性。2.1 播放内核ExoPlayer是电视端最稳的起点播放内核我最终选了AndroidX Media3里的ExoPlayer准确说就是现在的Media3 ExoPlayer。对比过IjkPlayer和系统自带的MediaPlayerIjkPlayer在本地局域网播放和部分RTSP流上确实有优势但它现在维护节奏慢升级到新系统后问题也比较多。系统MediaPlayer虽然省事但封装层太黑想控制缓冲策略、日志、解码器选择就很费劲。用ExoPlayer最直接的收益是三点。第一它把缓冲、加载、出错状态都暴露成事件我可以根据这些事件做自动切源和失败重试这是MediaPlayer做不到的。第二它对HLS、DASH、SS这些流媒体协议的支持都内置了不用我再引入一堆第三方库。第三它在Android TV盒子上硬件解码适配做得不错大多数1080P和4K片源都能平滑播放。如果你的项目里有比较多本地局域网或者特殊直播流的场景可以把IjkPlayer作为备选内核一起封装但主内核我还是建议ExoPlayer。两个内核封装成同一个播放接口切换时只需要替换实现类上层UI和业务逻辑都不用动。2.2 源适配层把所有“不可控”挡在外面聚合终端最大的技术难点不是播放器本身而是“源”。在线内容的格式千奇百怪有的直接给一个MP4链接有的是M3U8直播流有的是JSON接口返回一串分集数据还有的是网页里需要解析才能提取的视频地址。如果把这些差异直接铺到业务层代码会腐烂得很快。我的做法是加了一个适配层叫SourceAdapter。每一类源实现同一个接口输出统一的数据模型MediaItemModel。这个模型里包含标题、封面、简介、类型、年份、集数列表、播放地址、清晰度列表、字幕地址等字段。上层界面只认这个模型完全不关心数据来自哪里。public interface SourceAdapter { String getSourceId(); boolean isAvailable(); MediaListResult fetchMediaList(String category, int page); MediaDetailResult fetchMediaDetail(String mediaId); ListPlayUrl resolvePlayUrls(String mediaId, String episodeId); }这样做的好处非常明显。新增一种内容源时我只需要新增一个适配器接入解析逻辑注册到适配器列表里点播、搜索、更新记录的功能全部自动生效。聚合终端的“聚合”二字本质上是靠适配层实现的而不是靠把所有逻辑写在一个巨大Activity里。2.3 元数据封面、简介、集数列表的统一管理聚合之后下一个问题就是元数据从哪来。有的源会返回很完整的标题、简介、海报图有的源只给个标题和播放地址简介、海报都需要补。我的方案是分层处理优先用源自带的数据缺的字段用后台补充任务去填。后台补元数据时可以抓取豆瓣/IMDb这类公开信息源但要注意频率不要对第三方站点造成压力也不要保存不该保存的数据。封面图管理这块我直接用Glide做加载和磁盘缓存。电视端封面通常要比手机显示得大很多分辨率低了模糊分辨率高了又占内存所以我让Glide统一按电视UI需要的尺寸裁剪并且开了diskCacheStrategy.ALL。不过实测发现如果图片服务器不稳定缓存策略再强也没用后面我会在性能调优部分细说。数据存储方面我用的是Room数据库。观看历史、收藏列表、续播位置、源配置这四类数据全部落本地。没有做账号系统因为是家庭场景一个电视盒子一个数据库就够了。3. 搭建过程实测从空壳工程到可点播的核心链路选型完成之后我直接搭了一个Android TV工程的空壳包名就叫tv.tvplayer.aggregator。这里不打算把每一行代码都贴出来工程代码量太大贴出来反而看不了重点。我更想把从空壳到“能正常点播”这一路最关键的几个实现节点讲清楚。3.1 遥控器焦点与电视UI第一道坎也是最容易返工的坎Android TV和手机最大的区别就是交互模型。手机是触摸电视是焦点。焦点处理不好哪怕功能再完整用户也想卸载。Android官方提供了一套Leanback组件BrowseFragment、DetailsFragment、RowsSupportFragment这些专门用来做电视端界面。我建议直接用Leanback别自己造列表控件。但Leanback也不是银弹。它默认的焦点样式比较死板卡片放大和阴影效果需要自己调。这里有几个关键参数调好之后手感完全不一样dimen namelb_basic_card_activated_animation_duration150/dimen dimen namelb_basic_card_activated_scale_factor1.06/dimen焦点缩放动画时长控制在120到180毫秒太长显得拖沓太短会感觉生硬。缩放倍数建议在1.04到1.08之间千万不要超过1.2否则相邻卡片会被挤得乱七八糟。另外焦点状态下的阴影一定要用Z轴高度的变化不要用setPadding模拟那样会在滚动时产生严重的性能问题。我在第一版里就是用的Padding模拟焦点效果结果在低端盒子上滚动列表时候明显掉帧后来改成setElevation之后流畅度立刻上来了。既然提到了代码里贴一个示例public class FocusableCardView extends androidx.cardview.widget.CardView { Override protected void onFocusChanged(boolean gainFocus, int direction, Nullable Rect previouslyFocusedRect) { super.onFocusChanged(gainFocus, direction, previouslyFocusedRect); animate().scaleX(gainFocus ? 1.06f : 1.0f) .scaleY(gainFocus ? 1.06f : 1.0f) .setDuration(150) .start(); setElevation(gainFocus ? dp(8) : dp(2)); } }3.2 搜索与选集聚合做得不好就是纯摆设搜索是聚合终端里最容易做砸的功能。做砸的典型表现是搜索结果出了几十个同名词条但用户不知道哪个源能播、哪个源是高清。我的做法是搜索结果按“可播性”排序。先在数据库里查本地记录和收藏再查已配置的在线源最后把搜索命中的条目统一展示并且对每个条目标注来源和清晰度。选集列表也是电视端的操作重灾区。列表太长遥控器一格格按下去非常痛苦。我的做法是两级设计默认按剧集分组展示用户按“只看简介”时收起剧集列表剧集列表支持“跳转页”模式直接输数字跳集。选集焦点还要记住上次看得位置这一点放到体验调优部分细说。搜索输入框则直接用系统软键盘虽然体验一般但胜在兼容性最好不用自己写一个电视端键盘。3.3 多源切换与失败重试机制聚合终端一定会有“这个源挂了换一个源再播”的需求。我实现的逻辑分三档第一档是播放开始前预检用户点击播放时先快速请求播放地址发现超时就直接标记该源不可用并尝试下一个第二档是播放中出错通过 ExoPlayer 的Player.Listener.onPlayerError捕获错误如果错误类型是网络或IO层问题就自动切到备用源继续播第三档是手动切换详情页放一个“播放源”按钮用户自己选择源和清晰度手动切换记录会被存为偏好下次优先选同一个源。自动切源有一个非常关键的细节切换源之后要从上次的播放位置继续而不是从头播放。很多播放器实现切源时都会把这个逻辑做丢用户切个源之后又得手动拖进度条体验大打折扣。我在切源时会把currentPosition保存下来等新源拉流成功后直接seekTo到对应位置。4. 聚合源接入能用什么、失效规律与合规边界聚合终端的成败很大程度上取决于“现在聚合了什么源”。但源的接入也是一件需要持续维护的事情不存在一劳永逸。这一节讲一下源的分类、接入方式和我在合规方面采用的实际策略。4.1 源的类型、生命周期与日常维护源大体分成三类。第一类是本地媒体库也就是家里NAS、老旧硬盘上的电影和剧集SMB和WebDAV协议都可以扫到这类源最稳定几乎不需要维护。第二类是有公开API或官方Feed的在线内容源比如一些提供开放接口的影音站点、播客、公开课平台通过API拿到数据后直接播放稳定性也不错。第三类是网页型内容需要从页面结构里提取播放地址这类源最容易失效页面改版一次就要重新适配。第三类源失效是常态不是例外。我维护的时候发现平均每隔两三个月就要检查一遍解析规则通常都是网站改版导致选择器失效。我的做法是给每个源适配器加一个“健康度”指标根据请求失败率、平均响应时间、连续失败次数自动打分分数低于阈值的源在界面上自动降级排序避免用户每次点开一个坏源。4.2 嗅探、API与解析三种接入方式的取舍接入方式大致有三种嗅探、API、解析。嗅探是指在设备端通过抓取网络请求找出网页中的真实播放地址。这种方式实现成本低但非常脆弱而且容易被站点反制。我一般只在本地自建服务或者实验室环境里做嗅探测试不会把它当成日常使用的接入方式。API方式是最稳定的。源方直接返回JSON格式的数据包括标题、封面、剧集、播放地址。缺点是能提供公开API的内容源并不多很多要你自行申请授权。解析方式介于两者之间通过加载源站页面用正则或XPath提取播放地址。选择器写得好效率很高但源站页面一旦改版就会失效。如果要做强烈建议在适配层增加“选择器配置化”让选择器规则可以在本地配置里热更新而不是每改一次都发新版本。4.3 版权与合规我采用的实际策略这一部分我必须说清楚。聚合播放终端的开发过程中一定会遇到“要不要接入第三方未授权内容”的选择。我的原则是只在自己有使用权的范围内做测试和验证具体来说有三条。第一个人本地媒体库只存自己拥有版权或获得授权的内容。家里人拍的家庭录像、买的数字拷贝、有授权的下载内容都在这个范围内。第二在线源只接入有公开授权或明确允许聚合的站点。第三解析和嗅探只使用在自有站点或测试环境中不用于绕开任何平台的付费墙、访问限制、版权保护措施。做技术研究和做内容分发是两回事。技术本身是中性的但聚合终端的实际使用场景必须守住边界。如果你准备把这个项目长期维护下去这一块的自觉性比任何代码实现都重要。5. 性能与体验调优解码、预加载与焦点记忆电视盒子的性能跨度非常大旗舰盒子能跑4K高码率老盒子连1080P都卡。所以调优不是简单地把参数调到最高而是让终端能感知设备能力自动选择合适的解码和缓冲策略。5.1 电视设备差异大优先保流畅还是保画质我的终端里加了一个“解码能力探测”逻辑启动时检测设备的解码器支持列表、内存大小和CPU核数生成一个能力等级。能力等级高时默认允许4K分辨率和更激进的预加载能力等级低时自动把默认清晰度降到1080P并关闭背景模糊、动画特效这些拉高负载的UI元素。画质和流畅度之间电视端场景我倾向于优先保流畅。客厅里的观看距离通常在2到3米720P和1080P在这个距离上感知差异不大但卡顿会立刻被感知。唯一例外是本地局域网或NAS里的高码率片源这种场景用户可以自己手动切到4K原画。5.2 网络加载、缓存目录与存储空间管理在线播放的体验很大程度上取决于预加载策略。我用DefaultLoadControl配置了一组比较保守的缓冲参数最小缓冲3秒最大缓冲15秒缓冲低于1.5秒时开始补加载。这个参数在大多数家庭宽带下表现都不错不会短时间预载过多导致带宽占用也不会因为缓冲太小频繁loading。缓存目录要认真管理。ExoPlayer的缓存和Glide的图片缓存在同一块存储空间里如果不限制大小用几个月就能把盒子撑爆。我的方案是视频缓存限制2GB图片缓存限制200MB超过之后自动按LRU清理。清理时还要注意避开正在播放的文件。存储空间不足时优先清图片缓存再清最久没看的视频缓存。5.3 断点续播与焦点记忆细节决定“像不像正规App”断点续播是聚合终端最值得做的功能之一。我的实现是把观看进度实时写入Room数据库每15秒写一次退出播放页面时再强制写一次。下次点开同一个媒体时自动从上次位置继续播放并弹出一个“已从xx:xx继续播放”的提示条。如果用户倾向于从头看提示条上也可以手动选择从头播放。焦点记忆包括两层。一层是垂直列表的焦点比如用户看了“电影”分类退出再回来时还停在“电影”分类而不是回到默认的“首页”。另一层是横向列表的焦点比如用户在某一行里选中第10部影片回来后焦点尽量还停在那一行附近。这个功能看起来不起眼但一旦习惯了再用别的App就会觉得很别扭因为很多甚至是大厂的电视App也没做这层记忆。6. 联调与稳定性验证踩坑、修复和上线前检查做完功能之后真正的麻烦才开始。电视App的稳定性验证比手机严格得多因为用户不会像手机用户那样频繁换机也不会因为某个版本有bug就去写差评他们会直接卸载。下面几个坑都是我在真机联调阶段踩过的。6.1 真实盒子上的卡顿与异常崩溃第一个坑低端盒子上的内存溢出。电视盒子的内存通常只有1到2GB系统还要占掉一部分。第一版我用Glide加载封面时不限制尺寸结果每次滑动瀑布流内存就涨最后卡死。后来把封面加载改成了“显示分辨率下采样”并在列表滚动停止之后再进行图片加载这个问题就基本消失了。第二个坑播放过程中的硬件解码线程崩溃。这个崩溃不是我们App代码的问题而是部分盒子的视频解码器对特定编码格式不兼容导致系统进程崩溃。解决办法是捕获MediaCodec.CodecException然后自动切换到软件解码器。软件解码吃CPU但至少能保证视频播得出来。第三个坑音频直通和采样率切换。很多盒子接功放音频输出格式会随片源变化。某些片子没声音是因为音频直通时没有通知功放切换采样率我在这里加了一层AudioManager.setPreferredDevice的逻辑并在播放器初始化时先探测音频输出设备能力。6.2 超时、重试与网络探测的平衡聚合源的网络环境千差万别有的源响应慢但能播有的源响应快但实际拉流失败。所以要区分“连接超时”和“读取超时”。连接超时设置8秒太长了电视用户没耐心我统一压缩到4秒。读取超时设置成15秒低于这个值会导致大文件预加载时频繁超时。重试策略上我采用最多重试1次而且只在首次播放失败时重试。用户手动切源时不做自动重试避免切源后还是坏源变成“无限转圈”。网络探测放到统一入口里做也就是开机或者从后台返回时用 TCP 快速通道探测已配置的源站点是否可达可达性数据用来更新源的展示顺序。这样用户看到的列表前面永远是最可能能播的源。6.3 崩溃日志、线上监控与后续扩展上线前的最后一步是崩溃日志收集。电视端不像手机那么容易连USB调试所以我会在App里内置一个崩溃日志模块捕获到未处理异常后写入本地文件下次启动时通过用户允许的通道上报。上报通道我用的是自建且受控的接口没有接第三方统计SDK因为电视盒子上很多统计SDK反而带来额外耗电和隐私争议。日志内容只包含崩溃堆栈、设备型号、系统版本、播放器状态这几项绝不包含用户观看记录和家庭网络细节。这一块隐私边界做得越保守越少给自己找麻烦。后续扩展方向我目前在做两个。一是把源适配器做成可配置的脚本化规则这样源失效时不用天天改代码发版直接在规则管理界面更新即可。二是加一个“局域网多端同步”的功能让家庭里几台电视共享同一份观看历史和收藏表。同步方案还在自测阶段准备用局域网发现协议加手动配对不上云不经过第三方服务。最后分享一个小技巧。如果你也在做电视端的聚合播放器一定要把“播放记录”当成核心功能排在优先级最高的位置。我见过很多技术很强的人做了很漂亮的聚合界面但唯独忘了续播这个功能结果用户每次打开都得重新找片源、重新拖进度条体验完全撑不起来。一个播放终端是不是真正“全能”很多时候不是取决于它接了多少个源而是取决于它有没有把“这次看到哪里了”这件事做好。