苦等多年！Compose 终于迎来原生 Media3 播放器

本文首发于公众号"Android技术圈HPro"

前两天，Google 正式发布了 Media3 1.10。

对开发者来说最炸的莫不过Compose终于有自己的播放器了！

Compose 播放器来了

过去一提 Compose 播放器，很多团队的真实状态其实都差不多。

要么继续用 PlayerView，外面包一层 AndroidView()；要么自己把内容层、控制层、进度条、手势和倍速按钮一块一块拼出来。

问题不是做不到，而是很费。

尤其是当你既想保留 Compose 的声明式写法，又想让界面更接近 Material 3 风格时，工作量很容易失控。

这次 Media3 1.10 在 media3-ui-compose-material3 上继续扩模块，并新增了一个可直接上手的 Player Composable。

官方给它的定位很明确：把内容显示和可定制的播放控制组合起来，先给你一套开箱可用的现代播放器骨架。

同时，这版还补了几个很关键的小部件：

• ProgressSlider，支持拖拽和点击 seek
• PlaybackSpeedControl，做倍速管理
• PlaybackSpeedToggleButton，提供 Material 3 风格的倍速切换按钮

这件事真正有价值的地方，不是"少写几个控件"。

而是团队终于可以先拿到一套官方 Compose 播放器底座，再决定哪些地方自己定制，而不是从零开始手搓一整套媒体交互层。

如果你只是想先把依赖拉起来，最小升级可以先这样配：

bash 复制代码

implementation("androidx.media3:media3-exoplayer:1.10.0")
implementation("androidx.media3:media3-ui-compose:1.10.0")
implementation("androidx.media3:media3-ui-compose-material3:1.10.0")

如果你们现在还停留在 PlayerView + Compose 包壳 的过渡方案，这版已经值得单独拉一个分支试一轮。

你们更想要官方接下来先补字幕、轨道选择，还是更细粒度的播放器插槽？我觉得这会直接决定 Media3 Compose 这条线成熟得有多快。

性能提升

很多版本发布喜欢讲新能力，但业务里真正要命的，往往不是"有没有新 API"，而是"这个资源到底播不播得出来""出错了能不能兜住""高负载时还能不能稳一点"。

Media3 1.10 在播放层补的，很多就是这种更贴近实战的问题。

先看格式支持。

这次 ExoPlayer 新增了对 MP4 容器中 Dolby Vision Profile 10 和 VVC track 提取的支持，decoder_mpegh 扩展加入了 MPEG-H UI manager，IAMF 扩展也更顺滑地支持双耳输出，并且能借助 Android Spatializer 更好匹配扬声器布局。

这几项放在一起看，信号很清楚：

ExoPlayer 不是只在补"能不能播"，而是在继续往更复杂、更高规格的媒体场景靠。

除此之外，这版还做了几件非常工程化的改进：

• 广告播放链路继续提升可靠性
• HLS interstitial 更好支持 X-PLAYOUT-LIMIT 和 X-SNAP
• HLS 遇到加载错误时，如果有不同 location 的冗余流，可以做 location fallback
• MediaSessionService 现在继承 LifecycleService，服务生命周期管理会自然很多

还有一个我很在意的小实验能力：官方开始支持用更高效的方式调度核心播放循环。

如果你们有多实例播放、长列表视频预览、后台音频或直播场景，这个方向值得马上盯住。

试验开关也很直接：

bash 复制代码

val player = ExoPlayer.Builder(context)
    .experimentalSetDynamicSchedulingEnabled(true)
    .build()

它现在还是实验能力，但方向已经很明确了。

Media3 今年一个重点，不只是让播放器"能跑起来"，而是让播放器"跑得更有效率"。

如果你们团队最近正好在排查掉帧、发热、功耗或者复杂 HLS 兼容问题，这段更新比表面上看更值钱。

倍速导出这件事，终于更稳了

做媒体编辑的人都知道，倍速从来不只是把数值改成 1.25x 或 1.5x 那么简单。

一旦进入导出链路，帧率、输出体积、处理性能很快就会互相牵制。

很多时候你以为自己只是做了一个"调速度"的功能，最后踩到的却是导出体积异常、处理时间拉长，或者成片表现不稳定。

这次 Transformer 的改动不花哨，但非常实用。

EditedMediaItem.Builder.setFrameRate() 现在可以用来设置视频的最大输出帧率，在和 setSpeed() 配合时尤其有价值。

一个很实用的写法大概就是这样：

bash 复制代码

val editedItem = EditedMediaItem.Builder(mediaItem)
    .setSpeed(1.5f)
    .setFrameRate(30)
    .build()

如果你们在做短视频剪辑、模板导出、运动视频快放，或者任何"用户会频繁改速度"的编辑场景，这个点建议直接转给负责导出链路的同学。

因为它解决的不是 API 好不好看，而是倍速导出最容易出事的那个位置，终于有了更明确的控制杆。

写在最后

要不要升级？我的建议很简单：

• 正在做 Compose 播放器，建议尽快开分支验证
• 业务里有复杂格式、HLS、广告、空间音频，建议安排升级评估
• 正在做导出或剪辑链路，至少把 Transformer 的帧率控制测一轮
• 如果当前项目改动窗口很小，可以先观察，但没必要忽略这版

你们团队现在最痛的是播放器 UI、格式兼容，还是视频导出？

#Android #Media3 #ExoPlayer #Compose #音视频开发