1. 从MediaPlayer到ExoPlayer：为什么我们需要一个更现代的播放器？

如果你在Android平台上做过音视频播放相关的开发，大概率是从 MediaPlayer 这个系统API入门的。它简单、直接，几行代码就能播一个网络视频，对于新手来说非常友好。但当你开始处理更复杂的场景时，比如播放列表、无缝切换、自定义UI、复杂的DRM（数字版权管理）需求，或者需要精细控制缓冲策略时， MediaPlayer 就开始显得力不从心了。它的API设计相对陈旧，扩展性有限，很多高级功能要么不支持，要么实现起来非常别扭。

这时， ExoPlayer 就进入了我们的视野。它不是Android系统内置的API，而是Google开源的一个运行在应用层的媒体播放库。你可以把它理解为一个“播放器框架”或者“播放器引擎”。它的核心设计哲学是 模块化 和 可扩展性 。这意味着，播放器的几乎所有组件——从负责获取媒体数据的 DataSource ，到解析封装格式的 Extractor ，再到进行音视频解码的 Renderer ——都是可以替换和定制的。这种设计让ExoPlayer能够轻松应对各种定制化需求，从简单的本地文件播放，到复杂的直播流、自适应码率流（如DASH、HLS），再到自定义的加密格式，它都能通过组合不同的模块来支持。

我最初接触ExoPlayer是为了实现一个直播App，需要低延迟和抗网络抖动。 MediaPlayer 对HLS直播的支持在当时很基础，缓冲策略不透明，延迟也高。切换到ExoPlayer后，我不仅能通过配置轻松调整缓冲区大小，还能监听网络带宽变化，动态切换不同码率的视频流，用户体验提升非常明显。更重要的是，当遇到一些奇怪的播放问题时（比如某些特定服务器返回的流格式不标准），我可以深入到具体的 DataSource 或 Extractor 模块去排查和修复，而不是对着一个黑盒的 MediaPlayer 束手无策。

所以，学习ExoPlayer，不仅仅是学习一个新的播放器API，更是学习一套构建现代、健壮、可定制媒体播放体验的思维方式。它适合那些不满足于“能播就行”，而是希望对自己的播放器有完全控制权的开发者。

2. ExoPlayer核心架构拆解：模块化是如何工作的？

要理解ExoPlayer的强大之处，必须从它的核心架构入手。与 MediaPlayer 那种“一锅端”的单一实体不同，ExoPlayer更像一个精心设计的“乐团”，每个乐手（模块）各司其职，通过一个指挥（ ExoPlayer 接口）协同工作。这种设计让整个系统既灵活又清晰。

2.1 核心组件与职责

我们可以把ExoPlayer的核心分为几个层次：

1. ExoPlayer 接口 ：这是开发者交互的主要对象。它定义了播放控制（播放、暂停、跳转）、状态查询、事件监听等所有高层API。你通常不会直接实例化它，而是通过 ExoPlayer.Builder 来构建。

2. MediaSource （媒体源） ：这是架构中的关键抽象。它代表了要播放的媒体内容。 MediaSource 并不直接持有数据，而是负责在需要时创建 MediaPeriod （媒体周期，对于点播就是一个文件，对于直播就是一段滑动窗口）。它的核心工作是告诉播放器：“媒体有什么（轨道信息、时长）”，以及“如何获取媒体的数据”。ExoPlayer内置了多种 MediaSource 实现：

   • ProgressiveMediaSource ：用于播放普通的渐进式下载文件，如MP4、MP3。它需要一个 DataSource 来读取数据，一个 Extractor 来解析封装格式。
   • DashMediaSource ：用于播放基于MPEG-DASH标准的自适应流。
   • HlsMediaSource ：用于播放HTTP Live Streaming (HLS) 自适应流。
   • SsMediaSource ：用于播放SmoothStreaming流。
   • ConcatenatingMediaSource ：可以将多个 MediaSource 拼接成一个连续的播放列表，实现无缝切换。

3. Renderer （渲染器） ：负责接收解码后的媒体样本（sample），并将其渲染到输出设备上。主要有三种：

   • MediaCodecVideoRenderer ：使用 MediaCodec 进行视频解码和渲染到 Surface 。
   • MediaCodecAudioRenderer ：使用 MediaCodec 进行音频解码和输出到音频设备。
   • TextRenderer ：用于渲染字幕（如WebVTT、TTML）。
   • MetadataRenderer ：用于处理ID3等元数据。 每个 Renderer 从属于一个 TrackGroup （轨道组），播放器会根据选择的轨道，将数据分配给对应的 Renderer 。

4. TrackSelector （轨道选择器） ：当媒体包含多条音轨、视频轨或字幕轨时（比如一个DASH流包含1080p、720p、480p多种视频质量）， TrackSelector 负责根据当前的约束条件（如网络带宽、设备能力、用户偏好）自动选择最合适的轨道进行播放。默认的 DefaultTrackSelector 已经非常强大，你也可以实现自己的选择逻辑。

5. LoadControl （加载控制器） ：它控制着媒体的加载（缓冲）行为。决定何时开始缓冲、缓冲多少数据、何时停止缓冲以节省流量和电量。你可以通过自定义 LoadControl 来实现更激进的预加载策略或更保守的流量控制。

6. DataSource （数据源） ：这是一个更底层的组件，被 MediaSource 使用，负责从原始位置读取字节数据。它抽象了数据的来源，可以是：

   • DefaultDataSource ：支持文件、Asset、ContentResolver Uri和网络（HTTP/HTTPS）。
   • CacheDataSource ：在 DataSource 之上增加缓存层，可以显著减少重复视频的流量消耗和提升加载速度。
   • 你也可以实现自己的 DataSource 来支持自定义协议（如RTMP）或特殊的加密流。

7. Extractor （提取器） ：对于渐进式媒体文件（如MP4）， Extractor 负责解析文件格式（容器格式），将交织在一起的音视频、字幕等基本流（elementary stream）数据分离出来，并提取出时间戳等元信息。 ProgressiveMediaSource 会使用它。

这个架构的美妙之处在于 解耦 。如果你想支持一种新的流媒体协议，你只需要实现一个新的 MediaSource 。如果你想改变缓冲算法，就实现一个新的 LoadControl 。如果你想支持一种新的文件格式，就实现一个新的 Extractor 。各个模块通过定义良好的接口通信，互不干扰。

2.2 数据流：从URL到屏幕像素

让我们追踪一个典型的HTTP MP4视频播放过程，看看数据是如何在这些模块间流动的：

1. 你创建一个 ProgressiveMediaSource ，传入视频URL。 ProgressiveMediaSource 内部会持有一个 DefaultDataSource.Factory 用于创建网络连接。
2. 你将这个 MediaSource 设置给 ExoPlayer 实例。
3. 调用 player.play() 。 ExoPlayer 会通知 MediaSource 准备。
4. MediaSource 创建 MediaPeriod ，并通过 DataSource 开始读取数据字节。
5. 读取到的字节被送入 Extractor （例如 Mp4Extractor ）。 Extractor 解析MP4盒子结构，识别出视频轨（H.264）和音频轨（AAC），并将压缩的音视频数据包（包含时间戳）分离出来。
6. 分离出的数据包被放入对应的 SampleQueue （样本队列）。
7. TrackSelector 根据当前情况（比如默认选最高清视频）选择要播放的轨道。
8. 对应的 Renderer （ MediaCodecVideoRenderer 和 MediaCodecAudioRenderer ）从各自的 SampleQueue 中取出数据包。
9. Renderer 调用 MediaCodec API，将压缩数据送入解码器。
10. 解码后的视频帧被渲染到 SurfaceView 或 TextureView 上，解码后的音频数据被送入音频输出设备。

整个过程是异步和流水线式的， LoadControl 会监控缓冲区的数据量，决定是否让 DataSource 读取更多数据，从而平衡播放流畅度、延迟和资源消耗。

注意 ：理解 MediaSource 和 DataSource 的区别至关重要。 DataSource 是“搬运工”，只负责搬字节。 MediaSource 是“项目经理”，它知道要搬什么（媒体结构），并指挥 DataSource 去搬，同时用 Extractor 来拆箱。很多初学者混淆两者，导致配置错误。

3. 从零开始集成与基础播放

理论讲得再多，不如动手写一行代码。让我们从一个最简单的集成开始，播放一个网络MP4视频。这里假设你使用Android Studio和Kotlin（Java语法类似）。

3.1 添加依赖与权限

首先，在项目的 build.gradle 文件中添加ExoPlayer核心库的依赖。ExoPlayer由多个模块组成，我们通常从核心库开始。

// 在 app/build.gradle 的 dependencies 块中添加
dependencies {
    implementation "androidx.media3:media3-exoplayer:1.3.1" // 使用最新稳定版
    implementation "androidx.media3:media3-ui:1.3.1" // 用于PlayerView控件
    // 如果需要播放DASH、HLS等，还需添加对应模块
    // implementation "androidx.media3:media3-exoplayer-dash:1.3.1"
    // implementation "androidx.media3:media3-exoplayer-hls:1.3.1"
}

注意：从 2.18.0 版本开始，ExoPlayer已迁移到AndroidX Media3库（ androidx.media3 命名空间）。如果你看到旧教程使用的是 com.google.android.exoplayer ，请注意区分。Media3是官方推荐的未来方向，集成了更多现代Android媒体功能。

然后，在 AndroidManifest.xml 中添加网络权限：

<uses-permission android:name="android.permission.INTERNET" />

3.2 布局与基础播放实现

在布局文件中，我们可以使用Media3提供的 PlayerView ，它封装了视频渲染Surface、播放控制按钮、进度条、错误提示等，非常方便。

<!-- activity_main.xml -->
<androidx.constraintlayout.widget.ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <androidx.media3.ui.PlayerView
        android:id="@+id/player_view"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:show_buffering="when_playing"
        app:controller_auto_show="true"
        app:use_controller="true"/>

</androidx.constraintlayout.widget.ConstraintLayout>

接下来，在Activity中初始化播放器。这是一个最简化的版本：

// MainActivity.kt
import android.net.Uri
import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
import androidx.media3.common.MediaItem
import androidx.media3.common.Player
import androidx.media3.exoplayer.ExoPlayer
import androidx.media3.ui.PlayerView

class MainActivity : AppCompatActivity() {

    private var player: ExoPlayer? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 1. 创建Player实例
        player = ExoPlayer.Builder(this).build()

        // 2. 将Player绑定到PlayerView
        val playerView: PlayerView = findViewById(R.id.player_view)
        playerView.player = player

        // 3. 创建MediaItem并准备播放
        val mediaItem = MediaItem.fromUri("https://your-video-url/video.mp4")
        player?.setMediaItem(mediaItem)
        player?.prepare() // 开始缓冲
        // player?.play() // 如果希望立即播放，可以调用play()
    }

    override fun onStart() {
        super.onStart()
        // 在onStart中恢复播放（如果应用从后台返回）
        if (player != null) {
            player?.play()
        }
    }

    override fun onStop() {
        super.onStop()
        // 在onStop中暂停播放以节省资源（可选，取决于需求）
        player?.pause()
    }

    override fun onDestroy() {
        super.onDestroy()
        // 释放播放器资源，非常重要！
        player?.release()
        player = null
    }
}

这段代码做了以下几件事：

1. 使用 ExoPlayer.Builder 构建了一个默认配置的播放器实例。
2. 将这个播放器实例设置给 PlayerView ，这样UI控件就能控制播放并显示视频。
3. 通过 MediaItem.fromUri 创建了一个代表网络视频的媒体项。 MediaItem 是Media3中描述媒体内容的核心类。
4. 调用 prepare() 方法，播放器开始初始化 MediaSource 、获取媒体信息（如分辨率、时长）并缓冲数据。
5. 在 onStart 和 onStop 中简单管理播放状态，提升用户体验。
6. 在 onDestroy 中**必须调用 release() **来释放播放器占用的所有资源（解码器、网络连接、内存等），否则会导致内存泄漏。

运行这个App，你应该能看到视频加载并播放，并且可以通过 PlayerView 自带的控制栏进行暂停、快进、快退等操作。

3.3 关键API与状态管理

基础的播放实现了，但我们通常需要更精细的控制和状态感知。ExoPlayer通过 Player 接口提供了丰富的API和监听器。

核心控制方法：

• play() / pause() ：开始/暂停播放。
• seekTo(positionMs) ：跳转到指定时间点（毫秒）。
• seekTo(mediaItemIndex, positionMs) ：在播放列表中跳转。
• hasNext() / hasPrevious() ：检查是否有下一项/上一项。
• seekToNext() / seekToPrevious() ：跳转到下一项/上一项。
• setPlaybackSpeed(speed) ：设置播放速度（如1.5倍速）。
• setVolume(volume) ：设置音量（0.0 到 1.0）。
• stop() ：停止播放并重置播放器，可以调用 prepare() 重新开始。

状态监听： 这是ExoPlayer编程中非常重要的一部分。你可以添加 Player.Listener 来监听播放器的各种状态变化。

player?.addListener(object : Player.Listener {
    // 播放状态改变：IDLE, BUFFERING, READY, ENDED
    override fun onPlaybackStateChanged(playbackState: Int) {
        when (playbackState) {
            Player.STATE_IDLE -> { /* 播放器空闲，未设置媒体资源 */ }
            Player.STATE_BUFFERING -> { /* 正在缓冲数据，可以显示加载动画 */ }
            Player.STATE_READY -> { /* 缓冲足够，可以开始或恢复播放 */ }
            Player.STATE_ENDED -> { /* 播放结束 */ }
        }
    }

    // 播放/暂停状态改变
    override fun onIsPlayingChanged(isPlaying: Boolean) {
        if (isPlaying) {
            // 正在播放
        } else {
            // 已暂停或停止
        }
    }

    // 播放出错
    override fun onPlayerError(error: PlaybackException) {
        // 处理播放错误，如网络错误、解码错误等
        Log.e("ExoPlayer", "Playback error: ${error.errorCodeName}, ${error.message}")
        // 可以根据error.errorCode判断错误类型，并给用户友好提示
    }

    // 媒体信息（如时长、轨道列表）加载完毕
    override fun onMediaItemTransition(mediaItem: MediaItem?, reason: Int) {
        // 当切换到新的MediaItem时触发
    }

    // 播放位置变化（可用于更新自定义进度条）
    override fun onPositionDiscontinuity(
        oldPosition: Player.PositionInfo,
        newPosition: Player.PositionInfo,
        reason: Int
    ) {
        // 例如在seek或自动切换片段时触发
    }
})

通过组合这些API和监听器，你可以构建出功能丰富的播放界面，比如自定义控制栏、显示精确的缓冲进度、在出错时重试等。

实操心得 ： Player.Listener 的回调可能来自后台线程，如果你需要在回调中更新UI，记得切换到主线程（ runOnUiThread 或使用 LiveData / Flow ）。另外， onPlayerError 是排查问题的关键入口， PlaybackException 包含了详细的错误码和原因，务必妥善处理并记录日志。

4. 进阶配置：解锁ExoPlayer的真正潜力

基础播放只是开始。ExoPlayer的威力在于其高度可配置性。下面我们深入几个关键的配置点，它们能解决实际开发中的大部分痛点。

4.1 定制化MediaSource：缓存、自定义头与格式支持

直接使用 MediaItem.fromUri 是最简单的方式，但背后ExoPlayer使用的是默认的 ProgressiveMediaSource 和 DefaultDataSource 。我们可以显式地构建它们以获得更多控制。

实现视频缓存： 使用 CacheDataSource 可以轻松为网络视频添加缓存，避免重复下载。

import androidx.media3.datasource.cache.SimpleCache
import androidx.media3.datasource.DefaultDataSource
import androidx.media3.datasource.cache.CacheDataSource

// 在Application或单例中初始化缓存（注意释放）
val cacheDir = File(context.cacheDir, "exoplayer-cache")
val cache = SimpleCache(cacheDir, NoOpCacheEvictor())
// 注意：SimpleCache是单例模式，应全局共享，避免创建多个实例。

// 构建带缓存的DataSource.Factory
val upstreamFactory = DefaultDataSource.Factory(context)
val cacheDataSourceFactory = CacheDataSource.Factory()
    .setCache(cache)
    .setUpstreamDataSourceFactory(upstreamFactory)

// 使用这个Factory创建MediaSource
val mediaSource = ProgressiveMediaSource.Factory(cacheDataSourceFactory)
    .createMediaSource(MediaItem.fromUri(videoUrl))
player?.setMediaSource(mediaSource)
player?.prepare()

添加自定义HTTP请求头： 有些服务器需要特定的Header（如User-Agent、Authorization Token）才能访问视频资源。

import androidx.media3.datasource.DefaultHttpDataSource
import androidx.media3.datasource.HttpDataSource

val httpDataSourceFactory = DefaultHttpDataSource.Factory()
    .setUserAgent("Your-App-Name/1.0")
    .setDefaultRequestProperties(mapOf("Authorization" to "Bearer $yourToken"))

// 可以将其设置为DefaultDataSource的上游工厂
val dataSourceFactory = DefaultDataSource.Factory(context, httpDataSourceFactory)
val mediaSource = ProgressiveMediaSource.Factory(dataSourceFactory)
    .createMediaSource(MediaItem.fromUri(videoUrl))

播放其他格式（如DASH/HLS）： 对于自适应流，你需要添加对应的依赖并使用专门的 MediaSource.Factory 。

// build.gradle 添加依赖
// implementation "androidx.media3:media3-exoplayer-dash:1.3.1"

// 在代码中
val dataSourceFactory = DefaultDataSource.Factory(context)
// 创建DASH媒体源
val dashMediaSource = DashMediaSource.Factory(dataSourceFactory)
    .createMediaSource(MediaItem.fromUri(dashManifestUrl))
// 创建HLS媒体源
// val hlsMediaSource = HlsMediaSource.Factory(dataSourceFactory)
//     .createMediaSource(MediaItem.fromUri(hlsPlaylistUrl))

player?.setMediaSource(dashMediaSource)

4.2 轨道选择与自适应流控制

当播放包含多轨道的媒体（如DASH、HLS）时， TrackSelector 是核心。 DefaultTrackSelector 提供了强大的筛选能力。

import androidx.media3.exoplayer.trackselection.DefaultTrackSelector
import androidx.media3.common.TrackSelectionOverride

// 1. 创建TrackSelector并用于构建Player
val trackSelector = DefaultTrackSelector(context)
val player = ExoPlayer.Builder(context)
    .setTrackSelector(trackSelector)
    .build()

// 2. 获取当前可用的轨道信息（通常在onPlaybackStateChanged到STATE_READY后）
val trackGroups = player.currentTracksInfo.trackGroupInfos

// 3. 应用轨道选择参数（例如：只选择标清视频轨和英文音频轨）
val parameters = trackSelector.buildUponParameters()
    .setMaxVideoSizeSd() // 限制最大视频尺寸为标清（720p以下）
    .setPreferredAudioLanguage("en") // 优先选择英文音频
    .build()
trackSelector.parameters = parameters

// 4. 更精细的控制：手动选择特定轨道
// 假设我们想强制选择第一个轨道组中的第二条视频轨道
// val trackGroup = trackGroups[0].trackGroup // 获取第一个轨道组
// val override = TrackSelectionOverride(trackGroup, listOf(1)) // 选择索引为1的轨道
// val manualParameters = trackSelector.buildUponParameters()
//     .setOverrideForType(override)
//     .build()
// trackSelector.parameters = manualParameters

你还可以通过 TrackSelector 监听轨道选择变化，或者实现自定义的 TrackSelection.Factory 来定义更复杂的自适应算法（比如基于实时网络带宽预测的码率切换）。

4.3 控制缓冲行为：LoadControl详解

缓冲策略直接影响起播速度、卡顿率和流量消耗。ExoPlayer默认的 DefaultLoadControl 已经比较合理，但在特定场景下可能需要调整。

import androidx.media3.exoplayer.DefaultLoadControl
import androidx.media3.exoplayer.LoadControl

val loadControl = DefaultLoadControl.Builder()
    .setBufferDurationsMs(
        minBufferMs, // 最小缓冲时长（毫秒），播放器会尝试至少缓冲这么多数据
        maxBufferMs, // 最大缓冲时长
        bufferForPlaybackMs, // 开始播放所需的最小缓冲时长
        bufferForPlaybackAfterRebufferMs // 卡顿后重新开始播放所需的最小缓冲时长
    )
    .setTargetBufferBytes(-1) // 目标缓冲区大小（字节），-1表示使用基于时长的策略
    .setPrioritizeTimeOverSizeThresholds(true) // 是否优先满足时间阈值而非大小阈值
    .setBackBuffer(5000, true) // 设置后缓冲时长（毫秒）及是否保留后缓冲
    .build()

val player = ExoPlayer.Builder(context)
    .setLoadControl(loadControl) // 应用自定义的LoadControl
    .build()

参数调优经验：

• minBufferMs ：设置得越大，抗网络波动能力越强，但起播越慢。对于短视频，可以设小一点（如15000ms）；对于长视频或直播，可以设大一点（如30000ms）。
• bufferForPlaybackMs ：这个值很关键。设得太小（如500ms），网络稍有不稳就可能卡顿；设得太大（如5000ms），用户每次seek后等待播放的时间会变长。通常2500ms是一个比较平衡的值。
• backBuffer ：后缓冲是指当前播放位置之前保留在内存中的数据。启用后缓冲（ true ）可以让用户小幅回退（比如拖拽进度条往回几秒）时立即播放，无需重新加载。但会占用更多内存。对于内存敏感的应用可以关闭。

踩坑提醒 ：过度增大缓冲区虽然能减少卡顿，但会显著增加内存占用，在低端设备上可能导致OOM（内存溢出）。务必在真实设备上进行压力和性能测试。我曾经在一个需要长时间播放视频列表的应用中，因为缓冲区设置过大，导致在部分老旧设备上播放几个小时后发生崩溃。后来通过监控播放器的内存使用并动态调整 LoadControl 参数才解决。

5. 软解码 vs 硬解码：性能与兼容性的权衡

在Android上，视频解码主要有两种方式： 硬解码 和 软解码 。ExoPlayer默认会优先尝试硬解码，失败后回退到软解码。理解两者的区别对性能优化和问题排查至关重要。

硬解码（Hardware Decoding）：

• 原理 ：利用设备上专用的图形处理单元（GPU）或媒体处理单元（如高通Hexagon、联发科APU）来解码视频。这些硬件电路是为视频编解码算法专门设计的。
• 优点 ：
  • 功耗极低 ：专用电路效率高，发热和耗电远低于CPU。
  • 性能高 ：解码速度快，能轻松处理高分辨率、高码率视频。
  • 系统负载小 ：解放CPU，让CPU可以处理其他任务。
• 缺点 ：
  • 格式支持有限 ：硬件解码器由芯片厂商提供，通常只支持主流格式（如H.264、H.265/HEVC、VP8/VP9）。对于较新或较偏门的编码格式（如AV1），旧设备可能不支持。
  • 兼容性问题 ：不同厂商、不同型号设备的硬件解码器实现可能有差异，偶尔会遇到解码异常、花屏、绿屏等问题。

软解码（Software Decoding）：

• 原理 ：完全使用设备的中央处理器（CPU）运行解码算法（如FFmpeg库）来解码视频。
• 优点 ：
  • 格式支持广泛 ：只要解码库（如ExoPlayer内置的 FFmpegExtension ）支持，就能解码几乎所有格式。
  • 兼容性一致 ：行为由软件库决定，在不同设备上表现一致。
• 缺点 ：
  • 功耗高 ：CPU进行密集运算，耗电快，手机容易发热。
  • 性能瓶颈 ：解码高分辨率视频（如4K）时，CPU可能不堪重负，导致解码帧率跟不上，视频卡顿。
  • 占用CPU资源 ：影响其他应用运行。

在ExoPlayer中如何选择和配置？

ExoPlayer的 MediaCodecVideoRenderer 和 MediaCodecAudioRenderer 默认使用 MediaCodec API，它会自动尝试使用硬件解码器。如果系统认为该格式不适合硬解或硬解失败，它会抛出 MediaCodec.CodecException ，然后ExoPlayer可能会尝试使用软解码渲染器（如果已注册）。

强制使用软解码： 有时为了兼容性（比如遇到某些设备硬解有Bug），你可能需要强制使用软解码。这通常需要集成额外的解码库，如ExoPlayer的 extension-ffmpeg 模块。

1. 添加FFmpeg扩展依赖 ：

   // 在 build.gradle 中添加
   implementation "androidx.media3:media3-exoplayer:1.3.1"
   implementation "androidx.media3:media3-decoder:1.3.1"
   implementation "androidx.media3:media3-extractor:1.3.1"
   // FFmpeg扩展库，提供软解码器
   implementation "androidx.media3:media3-exoplayer-ffmpeg:1.3.1"
   

2. 在构建播放器时注入FFmpeg渲染器 ：

   import androidx.media3.exoplayer.ExoPlayer
   import androidx.media3.exoplayer.mediacodec.MediaCodecSelector
   import androidx.media3.exoplayer.video.MediaCodecVideoRenderer
   import androidx.media3.exoplayer.audio.MediaCodecAudioRenderer
   import androidx.media3.exoplayer.RenderersFactory
   import androidx.media3.exoplayer.ffmpeg.FfmpegAudioRenderer
   import androidx.media3.exoplayer.ffmpeg.FfmpegVideoRenderer
   
   val renderersFactory = RenderersFactory { context, ->
       // 你可以在这里自定义渲染器的创建顺序和类型
       val codecSelector = MediaCodecSelector.DEFAULT
       val mediaCodecVideoRenderer = MediaCodecVideoRenderer(context, codecSelector)
       val mediaCodecAudioRenderer = MediaCodecAudioRenderer(context, codecSelector)
   
       // 创建FFmpeg软解码渲染器
       val ffmpegVideoRenderer = FfmpegVideoRenderer(context)
       val ffmpegAudioRenderer = FfmpegAudioRenderer(context)
   
       // 返回渲染器数组。顺序很重要，播放器会按顺序尝试使用。
       // 如果把FFmpeg渲染器放在前面，就会优先尝试软解。
       arrayOf(
           ffmpegVideoRenderer, // 优先尝试FFmpeg软解视频
           ffmpegAudioRenderer, // 优先尝试FFmpeg软解音频
           mediaCodecVideoRenderer, // 硬解视频作为备选
           mediaCodecAudioRenderer  // 硬解音频作为备选
       )
   }
   
   val player = ExoPlayer.Builder(context)
       .setRenderersFactory(renderersFactory)
       .build()
   

如何判断当前使用的是硬解还是软解？ 可以通过监听 ExoPlayer 的 onVideoDecoderInitialized 或 onAudioDecoderInitialized 事件，或者检查 Player 的 videoDecoderInfo / audioDecoderInfo 属性。解码器名称中如果包含 OMX. （高通、MTK等）、 c2. （Android Codec2）等前缀，通常是硬解码器；如果包含 ffmpeg ，则是软解码器。

选型建议：

• 默认情况 ：信任ExoPlayer的自动选择，优先硬解。
• 遇到特定设备花屏/绿屏 ：可以尝试在该设备型号上强制使用软解码作为临时解决方案，并收集日志反馈给芯片厂商。
• 播放非常规格式 （如FLV、某些编码的AVI）：提前集成FFmpeg扩展，并优先使用软解码。
• 对功耗极其敏感 （如长时间后台播放音频）：确保音频使用硬解码（ MediaCodecAudioRenderer ），它功耗极低。

6. 实战排坑：SampleQueue与常见问题解析

即使理解了原理和配置，在实际开发中依然会遇到各种问题。ExoPlayer内部有一个关键组件叫 SampleQueue （样本队列），它是 MediaSource 和 Renderer 之间的数据缓冲区。很多播放问题，如卡顿、跳转不准、内存增长，都与它有关。

6.1 SampleQueue的工作原理与缓冲区管理

SampleQueue 是一个生产者-消费者模型：

• 生产者 ： MediaSource （通过 Extractor ）不断解析媒体文件，将压缩的音视频数据包（Sample）写入队列。
• 消费者 ： Renderer 根据播放时钟，从队列中取出Sample，送入解码器。

LoadControl 通过监控所有 SampleQueue 的总数据量（或总时长）来决定是让生产者加速生产（多缓冲点）还是减速生产（等一等）。当播放器处于 STATE_BUFFERING 状态时，通常是因为所有 SampleQueue 的数据量低于 bufferForPlaybackMs 阈值，消费者在等生产者。

一个常见的性能问题：内存持续增长 在某些场景下，特别是播放长视频或直播流时，你可能会发现播放器占用的内存（Java Heap）缓慢但持续地增长。这很可能是因为 SampleQueue 中的数据没有被及时释放。

• 原因 ： SampleQueue 为了支持快速seek（跳转），会保留一定量的已播放数据（这就是 backBuffer ）。如果播放过程中用户没有seek操作，这些数据会一直保留直到达到 backBuffer 的容量上限。对于直播流，如果播放位置一直停留在最新点， SampleQueue 可能会不断累积旧数据。
• 排查 ：可以使用Android Profiler监控内存，并触发GC。如果每次GC后内存下降，但很快又涨回，且增长对象是 byte[] ，很可能就是 SampleQueue 缓冲的数据。
• 解决 ：
  1. 调整 LoadControl 的 backBuffer 参数，减少保留的时长，或完全禁用（ setBackBuffer(0, false) ）。但这会影响seek体验。
  2. 对于直播场景，确保使用正确的 MediaSource （如 HlsMediaSource ），它会自动管理滑动窗口，丢弃过期的数据。
  3. 定期检查播放器状态，如果长时间暂停或处于后台，可以考虑释放当前 MediaSource 并重新准备。

6.2 典型问题排查链路

当播放出现问题时，一个系统的排查思路至关重要。

问题一：视频黑屏但有声音

1. 检查Surface ：确保用于渲染视频的 Surface （通常来自 SurfaceView 或 TextureView ）是有效的且已附加到播放器。在 PlayerView 内部这通常是自动处理的，但如果你使用自定义 Surface ，需要在 Surface 生命周期变化时（如Activity的 onResume / onPause ）正确调用 player.setVideoSurface 。
2. 检查解码器 ：监听 onPlayerError ，看是否是视频解码器初始化失败。可能是格式不支持（硬解失败且无软解备选），或解码器资源被占用。
3. 检查轨道选择 ：确认 TrackSelector 确实选择了视频轨道。有时流里可能只有音频轨。
4. 检查DRM ：如果视频受DRM保护，需要确保DRM会话初始化成功。

问题二：播放卡顿，频繁缓冲

1. 网络诊断 ：首先排除网络问题。监听 onPlaybackStateChanged ，看是否频繁在 STATE_BUFFERING 和 STATE_READY 间切换。可以添加网络带宽估计监听（通过 DefaultBandwidthMeter ）来观察实时带宽。
2. 调整缓冲策略 ：适当增加 LoadControl 中的 minBufferMs 和 bufferForPlaybackMs 。
3. 降低视频码率 ：如果是自适应流（DASH/HLS），通过 TrackSelector 限制最高视频分辨率或码率，使其适应当前网络条件。
4. 检查设备性能 ：在低端设备上播放高码率4K视频，解码可能成为瓶颈。观察CPU使用率。考虑强制使用硬解码（如果支持）或降低播放分辨率。
5. 排查SampleQueue阻塞 ：极端情况下，如果 Extractor 解析出错或数据源异常，可能导致 SampleQueue 无法提供数据。查看日志中是否有相关的IO或解析错误。

问题三：Seek（跳转）不准或慢

1. 关键帧（I帧）问题 ：视频Seek只能定位到关键帧的位置。如果关键帧间隔很大（比如10秒一个），那么seek的精度就会很差。这是视频编码本身的特性，无法改变。可以提示用户“正在定位”。
2. 缓存问题 ：如果seek到一个未缓冲的区域，需要重新下载数据。使用 CacheDataSource 可以极大提升二次seek的速度。
3. ProgressiveMediaSource 的局限性 ：对于简单的MP4文件，seek需要从文件头开始解析索引（moov atom）。如果 moov atom在文件末尾（某些流式MP4），就需要下载大量数据才能seek。确保MP4文件是“快速启动”（Fast Start）格式，即 moov atom在文件开头。

6.3 日志与调试技巧

ExoPlayer提供了详细的日志。在调试时，可以通过 ExoPlayer 的 Builder 设置 EventLogger ，它会将内部事件（如状态变化、轨道信息、解码器初始化、缓冲事件等）以日志形式输出。

import androidx.media3.common.util.Log
import androidx.media3.exoplayer.ExoPlayer
import androidx.media3.exoplayer.util.EventLogger

val player = ExoPlayer.Builder(context)
    .build()
player.addAnalyticsListener(EventLogger()) // 添加事件日志监听器

在Logcat中过滤 EventLogger 标签，可以看到非常详细的信息，对于定位问题（如“为什么选择了这条轨道？”、“解码器为什么失败了？”）有极大帮助。

此外，在开发阶段，可以将 RenderersFactory 、 TrackSelector 、 LoadControl 等组件的自定义实例都通过Builder传入，并在关键节点添加日志，这样可以清晰地了解播放器的内部决策流程。记住，ExoPlayer的模块化设计使得每个环节都可以被监控和干预，这是它作为强大调试工具的优势。