16、ExoPlayer架构：设计理念、核心组件
聊到Android上的播放器，很多人第一反应是MediaPlayer。但如果你做过几个播放器项目，就会发现MediaPlayer的坑实在太多了——生命周期耦合、扩展困难、自定义渲染基本没门。嗯，ExoPlayer就是Google为了解决这些问题而生的。
我个人最早接触ExoPlayer是在2017年，当时公司要做个直播回放功能，MediaPlayer死活搞不定HLS的seek问题。换了ExoPlayer后，问题迎刃而解。从那以后，我基本就没再用过MediaPlayer了。
ExoPlayer的设计理念
ExoPlayer的核心设计理念，说白了就四个字：模块化、可定制。
你想想看，MediaPlayer是一个黑盒——你只能通过setDataSource、start、stop这些接口去控制它，内部怎么解码、怎么渲染、怎么选轨道，你完全插不上手。而ExoPlayer不一样，它把播放器的各个功能拆成了独立的组件，你可以自由替换、组合。
ExoPlayer vs MediaPlayer 核心差异
- MediaPlayer：系统级组件，底层由C++实现，扩展困难
- ExoPlayer：应用级组件，纯Java/Kotlin实现，每个模块都可替换
- MediaPlayer：生命周期绑定Activity，容易内存泄漏
- ExoPlayer：生命周期独立，开发者完全控制
我记得有一次，产品经理要求给视频加个自定义滤镜。用MediaPlayer的话，你得去搞SurfaceView的帧数据，效率低还容易掉帧。但ExoPlayer只需要写一个自定义Renderer，把解码后的帧数据过一遍滤镜再渲染就行了。这就是模块化的威力。
核心组件概览
ExoPlayer的架构可以拆成三大核心组件：MediaSource、Renderer、TrackSelector。它们各司其职，又紧密配合。
先看一张整体架构图，帮你建立直观印象：
MediaSource：数据源的抽象
MediaSource是ExoPlayer的数据层。它负责从各种来源获取媒体数据，并把它解析成ExoPlayer能理解的格式。
ExoPlayer内置了多种MediaSource实现：
| MediaSource类型 | 适用场景 | 特点 |
|---|---|---|
| ProgressiveMediaSource | MP4、WebM等本地/网络文件 | 简单直接，适合点播 |
| HlsMediaSource | HLS直播/点播流 | 支持m3u8，自动切换码率 |
| DashMediaSource | DASH流媒体 | 支持MPD，自适应码率 |
| SsMediaSource | SmoothStreaming | 微软的流媒体协议 |
| MergingMediaSource | 合并多个音视频源 | 比如视频来自A，音频来自B |
我在项目中遇到过这样一个场景：需要把一段视频和一个单独的音频轨合并播放。用MediaPlayer的话，你得先手动把两个文件合成一个，再播放。但ExoPlayer的MergingMediaSource直接搞定：
// 合并视频和音频源
MediaSource videoSource = new ProgressiveMediaSource.Factory(dataSourceFactory)
.createMediaSource(MediaItem.fromUri(videoUri));
MediaSource audioSource = new ProgressiveMediaSource.Factory(dataSourceFactory)
.createMediaSource(MediaItem.fromUri(audioUri));
MergingMediaSource mergedSource = new MergingMediaSource(videoSource, audioSource);
player.setMediaSource(mergedSource);
player.prepare();嗯，这里要注意：MergingMediaSource要求所有子源的时长必须一致，否则会出现音画不同步。我曾经踩过这个坑，后来在合并前先检查了时长。
Renderer：解码与渲染的核心
Renderer是ExoPlayer的渲染引擎。它负责把解码后的音视频数据渲染到输出设备上。
ExoPlayer默认提供了这些Renderer：
- MediaCodecVideoRenderer：基于MediaCodec的视频解码渲染
- MediaCodecAudioRenderer：基于MediaCodec的音频解码渲染
- TextRenderer：字幕渲染
- MetadataRenderer：元数据渲染（比如ID3标签）
每个Renderer都运行在独立的线程上，通过ExoPlayer内部的调度机制同步。这也是ExoPlayer性能好的原因之一——解码和渲染是并行的。
个人经验：如果你需要自定义渲染效果（比如加滤镜、做截图），可以继承BaseRenderer写自己的Renderer。我做过一个项目，需要在视频上叠加实时水印，就是通过自定义Renderer实现的。代码量不大，但效果很灵活。
TrackSelector：轨道选择的决策者
TrackSelector负责决定播放哪个音轨、哪个视频轨、哪个字幕轨。说白了，它就是播放器的「选片员」。
ExoPlayer内置了两种TrackSelector：
- DefaultTrackSelector：根据系统能力和用户偏好自动选择
- AdaptiveTrackSelector：在自适应流中动态切换码率
DefaultTrackSelector的决策逻辑是这样的：
- 先看用户有没有指定偏好（比如「我要英文音轨」）
- 如果没有，就看系统支持哪些格式
- 最后选一个「最优」的轨道
举个例子，假设视频流里有两条音轨：AAC 128kbps和MP3 192kbps。如果设备硬件支持AAC硬解，DefaultTrackSelector会优先选AAC，因为硬解更省电。但如果用户明确指定要MP3，那就会选MP3。
// 自定义TrackSelector，强制选择特定音轨
DefaultTrackSelector trackSelector = new DefaultTrackSelector(context);
trackSelector.setParameters(
trackSelector.buildUponParameters()
.setPreferredAudioLanguage("eng") // 优先英文
.setMaxVideoSize(1920, 1080) // 限制最大分辨率
.setForceLowestBitrate(false) // 不强制最低码率
);
ExoPlayer player = new ExoPlayer.Builder(context)
.setTrackSelector(trackSelector)
.build();避坑指南：我曾经在直播项目里遇到过一个问题——用户切换音轨后，画面卡住了。排查了半天，发现是TrackSelector的切换时机不对。直播流在切换音轨时，需要等关键帧到来才能切换，否则解码器会崩。解决方案是在切换前先暂停播放，等TrackSelector完成切换后再恢复。
三者如何协作？
ExoPlayer的工作流程，其实就是一个「数据管道」：
- MediaSource 从网络或本地读取数据，解析成Sample（样本）
- TrackSelector 决定这些Sample应该交给哪个Renderer处理
- Renderer 解码Sample，渲染到屏幕或扬声器
ExoPlayer内部维护了一个播放循环（Playback Loop），不断从MediaSource拉取数据，通过TrackSelector分发，最后由Renderer消费。这个循环是异步的，所以播放器不会因为某个环节卡住而完全阻塞。
我个人觉得，理解这个协作关系是掌握ExoPlayer的关键。你不需要记住每个类的所有方法，但一定要知道「数据从哪里来、经过谁、到哪里去」。
一句话总结：MediaSource管数据，Renderer管渲染，TrackSelector管决策。ExoPlayer是老板，协调三个部门干活。
好了，这一章的内容就到这里。ExoPlayer的架构其实不复杂，但它的模块化设计给了我们极大的灵活性。下一章我们会深入MediaSource的实现细节，看看它是怎么处理各种流媒体协议的。
公众号:蓝海资料掘金营，微信deep3321