本文首发于公众号“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 播放器底座，再决定哪些地方自己定制，而不是从零开始手搓一整套媒体交互层。
如果你只是想先把依赖拉起来，最小升级可以先这样配：
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，服务生命周期管理会自然很多
还有一个我很在意的小实验能力：官方开始支持用更高效的方式调度核心播放循环。
如果你们有多实例播放、长列表视频预览、后台音频或直播场景，这个方向值得马上盯住。
试验开关也很直接：
val player = ExoPlayer.Builder(context)
.experimentalSetDynamicSchedulingEnabled(true)
.build()
它现在还是实验能力，但方向已经很明确了。
Media3 今年一个重点，不只是让播放器“能跑起来”，而是让播放器“跑得更有效率”。
如果你们团队最近正好在排查掉帧、发热、功耗或者复杂 HLS 兼容问题，这段更新比表面上看更值钱。
倍速导出这件事，终于更稳了
做媒体编辑的人都知道，倍速从来不只是把数值改成 1.25x 或 1.5x 那么简单。
一旦进入导出链路，帧率、输出体积、处理性能很快就会互相牵制。
很多时候你以为自己只是做了一个“调速度”的功能，最后踩到的却是导出体积异常、处理时间拉长，或者成片表现不稳定。
这次 Transformer 的改动不花哨，但非常实用。
EditedMediaItem.Builder.setFrameRate() 现在可以用来设置视频的最大输出帧率，在和 setSpeed() 配合时尤其有价值。
一个很实用的写法大概就是这样：
val editedItem = EditedMediaItem.Builder(mediaItem)
.setSpeed(1.5f)
.setFrameRate(30)
.build()
如果你们在做短视频剪辑、模板导出、运动视频快放，或者任何“用户会频繁改速度”的编辑场景，这个点建议直接转给负责导出链路的同学。
因为它解决的不是 API 好不好看，而是倍速导出最容易出事的那个位置，终于有了更明确的控制杆。
写在最后
要不要升级？我的建议很简单：
-
• 正在做 Compose 播放器，建议尽快开分支验证
-
• 业务里有复杂格式、HLS、广告、空间音频，建议安排升级评估
-
• 正在做导出或剪辑链路，至少把
Transformer的帧率控制测一轮 -
• 如果当前项目改动窗口很小，可以先观察，但没必要忽略这版
你们团队现在最痛的是播放器 UI、格式兼容，还是视频导出？
