音视频移动开发【免费下载链接】ExoPlayerAn extensible media player for Android项目地址https://gitcode.com/gh_mirrors/exop/ExoPlayer点击查看免费下载本文围绕 ExoPlayer 的事件体系展开系统讲解如何通过Player.Listener监听播放状态变化、播放错误、播放列表切换与 seek 操作如何利用AnalyticsListener/EventLogger采集分析日志以及如何借助PlayerMessage在指定播放位置触发自定义事件。读完本文你将掌握 ExoPlayer 事件驱动编程的完整脉络并能在 demos/main 示例与 library/core 源码的佐证下把事件机制落地到自己的播放器应用中。提示本仓库docs/下的文档标注为可能过时建议同时参考开发者官网的最新 ExoPlayer 文档本文以当前仓库源码Player接口位于 library/common/src/main/java/com/google/android/exoplayer2/Player.java为准进行说明。Player.Listener注册与基本用法播放过程中产生的状态变化、错误等事件都会上报给已注册的Player.Listener实例。注册监听器只需一行代码// Add a listener to receive events from the player. player.addListener(listener);Player.Listener接口中的所有方法都是空实现default method因此你只需要覆写自己关心的回调即可。这一点可以从源码得到直接印证在 Player.java 中interface Listener内的onEvents、onPlaybackStateChanged、onIsPlayingChanged、onPlayerError等方法全部以default void形式声明接口还自带了完整的 Javadoc 说明每个方法何时被调用。Player.Listener的完整方法清单覆盖了播放器的方方面面包括但不限于onPlaybackStateChanged/onPlayWhenReadyChanged/onIsPlayingChanged播放状态与播放意愿onTimelineChanged/onMediaItemTransition/onTracksChanged播放列表与轨道变化onPositionDiscontinuity位置跳变seek、自动切换等onPlayerError播放失败onMediaMetadataChanged/onPlaylistMetadataChanged元数据变化onIsLoadingChanged数据加载状态onAvailableCommandsChanged/onTrackSelectionParametersChanged等能力与参数变化监听器可以选择分别实现单个事件回调也可以实现统一的onEvents回调在一次或多次事件同时发生时被调用。两种方式的取舍见下文「Individual callbacks vs onEvents」一节。在 demos/main/src/main/java/com/google/android/exoplayer2/demo/PlayerActivity.java 中可以看到官方 Demo 的典型用法player.addListener(new PlayerEventListener())注册播放器监听同时player.addAnalyticsListener(new EventLogger())注册日志监听。播放状态变化四种状态与 playWhenReady通过实现onPlaybackStateChanged(State int state)可以接收播放器状态变化。播放器共有四种播放状态常量定义见 Player.java状态值含义Player.STATE_IDLE1初始状态、播放器停止时的状态以及播放失败后的状态此状态下播放器只占用有限资源Player.STATE_BUFFERING2播放器无法从当前位置立即播放通常是因为需要加载更多数据Player.STATE_READY3播放器可以从当前位置立即播放Player.STATE_ENDED4播放器已播完所有媒体除了这四种状态播放器还有一个playWhenReady标志用于表示用户的播放意愿用户想播 vs 暂停。该标志的变化通过onPlayWhenReadyChanged(playWhenReady, PlayWhenReadyChangeReason int reason)接收其中reason说明变化原因如用户操作、音频焦点丢失、应用切到后台等。一个重要的判断是播放器真正在播放位置前进、媒体呈现在用户面前需要同时满足三个条件状态为Player.STATE_READYplayWhenReady为true播放未被抑制Player.getPlaybackSuppressionReason返回的原因不为抑制。与其手动逐一检查不如直接调用Player.isPlaying()并通过实现onIsPlayingChanged(boolean isPlaying)接收这一综合状态的变化Override public void onIsPlayingChanged(boolean isPlaying) { if (isPlaying) { // Active playback. } else { // Not playing because playback is paused, ended, suppressed, or the player // is buffering, stopped or failed. Check player.getPlayWhenReady, // player.getPlaybackState, player.getPlaybackSuppressionReason and // player.getPlaybackError for details. } }onIsPlayingChanged是 UI 层最常用的回调之一例如用它来控制播放/暂停按钮的图标、进度条的走动等可以避免在多个状态回调里重复拼装判断逻辑。播放错误处理onPlayerError 与 PlaybackException导致播放失败的错误通过onPlayerError(PlaybackException error)上报。当失败发生时该方法会在播放状态转为Player.STATE_IDLE之前立即被调用。失败的或已停止的播放可以通过重新调用ExoPlayer.prepare进行重试。需要注意某些Player实现会传入PlaybackException的子类以提供更多失败信息。例如ExoPlayer传入的是ExoPlaybackException源码见 library/core/src/main/java/com/google/android/exoplayer2/ExoPlaybackException.java它带有 ExoPlayer 特有的字段type错误来源类型取值为TYPE_SOURCE(0)、TYPE_RENDERER(1)、TYPE_UNEXPECTED(2) 或TYPE_REMOTErendererIndex/rendererName当type为TYPE_RENDERER时指明出错的渲染器索引与名称errorCode与getErrorCodeName()错误码及其可读名称以及出错时渲染器正在使用的Format、FormatSupport级别等信息。下面的示例展示了如何检测「HTTP 网络问题导致播放失败」Override public void onPlayerError(PlaybackException error) { Throwable cause error.getCause(); if (cause instanceof HttpDataSourceException) { // An HTTP error occurred. HttpDataSourceException httpError (HttpDataSourceException) cause; // Its possible to find out more about the error both by casting and by // querying the cause. if (httpError instanceof HttpDataSource.InvalidResponseCodeException) { // Cast to InvalidResponseCodeException and retrieve the response code, // message and headers. } else { // Try calling httpError.getCause() to retrieve the underlying cause, // although note that it may be null. } } }其中HttpDataSourceException及其子类HttpDataSource.InvalidResponseCodeException位于 library/datasource 模块后者可进一步取出 HTTP 响应码response code、响应消息与响应头用于向用户展示友好错误信息或触发重试策略。播放列表切换onMediaItemTransition每当播放器在播放列表中切换到新的媒体条目时onMediaItemTransition(MediaItem mediaItem, MediaItemTransitionReason int reason)会被调用。reason用于说明切换原因在 Player.java 中定义了四类取值MEDIA_ITEM_TRANSITION_REASON_AUTO自动切换如列表播完一项后自然进入下一项MEDIA_ITEM_TRANSITION_REASON_SEEK通过 seek 跳转例如调用player.next()/player.seekTo后发生的切换MEDIA_ITEM_TRANSITION_REASON_REPEAT同一条目因重复模式而再次播放MEDIA_ITEM_TRANSITION_REASON_PLAYLIST_CHANGED播放列表发生变化例如当前播放条目被移除。该回调也是埋点统计「当前播的是什么内容」的理想位置可配合MediaItem上的 tag 或 mediaId 上报给后端。Seek 操作位置不连续回调序列调用Player.seekTo系列方法会引发一连串的监听回调onPositionDiscontinuity且reason DISCONTINUITY_REASON_SEEK——这是调用Player.seekTo的直接结果onPlaybackStateChanged——与 seek 相关的任何即时状态变化注意可能不存在这样的变化。onPositionDiscontinuity的 reason 完整取值还包括DISCONTINUITY_REASON_AUTO_TRANSITION(0)、DISCONTINUITY_REASON_SEEK_ADJUSTMENT(2)、DISCONTINUITY_REASON_SKIP(3)、DISCONTINUITY_REASON_REMOVE(4)、DISCONTINUITY_REASON_INTERNAL(5)见 Player.java分别对应自动切换、seek 微调、跳播、条目被移除与内部原因。如果使用AnalyticsListener在onPositionDiscontinuity之前还会多出一个onSeekStarted事件用于记录 seek 开始前的播放位置。Individual callbacks vs onEvents两种监听风格如何取舍监听器可以在「分别实现单个回调」如onIsPlayingChanged与「实现统一的onEvents(Player player, Events events)」之间选择。onEvents回调能拿到Player对象并指明本次一起发生的事件集合Events。它总是在对应的单个事件回调之后被调用因为播放器会在一个 Looper 消息循环迭代内先触发完所有单个回调再统一触发onEvents。Override public void onEvents(Player player, Events events) { if (events.contains(Player.EVENT_PLAYBACK_STATE_CHANGED) || events.contains(Player.EVENT_PLAY_WHEN_READY_CHANGED)) { uiModule.updateUi(player); } }Player.Events定义于 Player.java的contains(int event)用来判断某个事件是否发生size()/get(int)可遍历全部事件。Player中定义了 30 多个EVENT_*常量Player.java例如EVENT_TIMELINE_CHANGED(0)、EVENT_MEDIA_ITEM_TRANSITION(1)、EVENT_PLAYBACK_STATE_CHANGED(4)、EVENT_PLAY_WHEN_READY_CHANGED(5)、EVENT_IS_PLAYING_CHANGED(7)、EVENT_PLAYER_ERROR(10)、EVENT_POSITION_DISCONTINUITY(11)、EVENT_RENDERED_FIRST_FRAME(26)、EVENT_CUES(27)、EVENT_METADATA(28) 等。适合优先使用单个回调的场景监听器关心变化的原因例如onPlayWhenReadyChanged的 reason、onMediaItemTransition的 reason监听器只根据回调参数中的新值行动或触发不依赖回调参数的其他逻辑监听器希望方法名能清晰可读地表达触发源监听器需要向分析系统上报所有单个事件与状态变化。适合优先使用onEvents的场合监听器要对多个事件触发同一逻辑例如同时依据onPlaybackStateChanged和onPlayWhenReadyChanged更新 UI监听器需要拿到Player对象再触发后续动作例如在媒体条目切换后调用 seek监听器要把多个独立回调上报的状态值组合使用或与Player的 getter 方法配合——例如在onTimelineChanged提供的Timeline之上调用Player.getCurrentWindowIndex()只有在onEvents回调内才是安全的监听器关心事件是否在逻辑上一同发生例如因为媒体条目切换而进入STATE_BUFFERING。部分场景下还需将两种风格结合例如用onMediaItemTransition记录条目切换原因但等所有状态就绪后再在onEvents里统一采取行动。使用 AnalyticsListener 与 EventLogger 做日志分析使用ExoPlayer时可以通过addAnalyticsListener注册AnalyticsListener接口位于 library/core/src/main/java/com/google/android/exoplayer2/analytics/AnalyticsListener.java。它提供比Player.Listener更细粒度的事件适合分析与日志用途详见仓库中的 analytics.md其中还介绍了PlaybackStatsListener在设备端完成事件解释、状态跟踪、聚合与汇总指标计算的能力以及EventTime携带的realtimeMs、windowIndex、eventPlaybackPositionMs等元数据字段。EventLogger是库直接提供的用于日志输出的AnalyticsListener实现源码位于 library/core/src/main/java/com/google/android/exoplayer2/util/EventLogger.java。只需一行即可为ExoPlayer开启实用的附加日志player.addAnalyticsListener(new EventLogger());添加后播放器会在 Logcat 中输出包括媒体条目加载、轨道选择、渲染器状态、seek、错误等在内的详细事件日志是调试播放问题的利器。官方 Demo 在 PlayerActivity.java 中同样使用这一行代码开启日志。更多调试技巧见仓库的 debug-logging.md。在指定播放位置触发事件PlayerMessage部分场景需要在特定播放位置触发自定义事件ExoPlayer 通过PlayerMessage支持这一能力。PlayerMessage的实现位于 library/core/src/main/java/com/google/android/exoplayer2/PlayerMessage.java其核心 API 如下ExoPlayer.createMessage(PlayerMessage.Target)创建消息PlayerMessage.setPosition(long positionMs)或setPosition(int mediaItemIndex, long positionMs)设置执行位置毫秒可精确到具体媒体条目PlayerMessage.setLooper(Looper)默认在播放线程执行可自定义执行线程PlayerMessage.setDeleteAfterDelivery(boolean)控制消息是在每次遇到该播放位置都执行seek、重复模式可能导致多次命中还是仅第一次执行PlayerMessage.setType(int)/setPayload(Object)携带消息类型与自定义数据PlayerMessage.send()调度消息。示例在媒体条目 0 的 120 秒处、在主线程上执行一次自定义逻辑player .createMessage( (messageType, payload) - { // Do something at the specified playback position. }) .setLooper(Looper.getMainLooper()) .setPosition(/* mediaItemIndex */ 0, /* positionMs */ 120_000) .setPayload(customPayloadData) .setDeleteAfterDelivery(false) .send();典型应用包括在视频特定时间点弹出提示、插入广告位标记、记录「已观看到第 N 分钟」的埋点、切换字幕语言等。注意若setDeleteAfterDelivery(false)配合 seek 与重复播放消息可能被多次触发业务上要自行做幂等处理。小结ExoPlayer 的事件体系分层清晰Player.Listener面向播放器状态与用户可见的播放行为AnalyticsListener含EventLogger、PlaybackStatsListener面向细粒度日志与数据分析PlayerMessage面向「时间点触发」的精确调度需求。实际开发中建议 UI 层优先使用onIsPlayingChanged与onEvents组合驱动界面更新业务层用onPlayerError做错误兜底与重试分析层用AnalyticsListener采集数据再按需用PlayerMessage实现定点事件即可覆盖绝大多数播放器应用场景。相关实现细节可继续阅读 Player.java监听接口与事件常量、PlayerMessage.java定点消息、EventLogger.java日志实现以及 demos/main 的官方示例。赞分享音视频移动开发【免费下载链接】ExoPlayerAn extensible media player for Android项目地址https://gitcode.com/gh_mirrors/exop/ExoPlayer点击查看免费下载相关推荐SeaTunnel 事件监听器Event Listener完全指南事件 API、Zeta HTTP 上报与自定义事件处理器实战SeaTunnel 事件监听器Event Listener完全指南事件 API、Zeta HTTP 上报与自定义事件处理器实战 SeaTunnel 提供了数据集成ETL大数据批处理流处理变更数据捕获QuickRecorder麦克风录制音频设置最佳实践QuickRecorder麦克风录制音频设置最佳实践 引言解决麦克风录制的痛点 你是否曾经历过这样的场景精心录制的教程视频因麦克风杂音毁于一旦远程会议中前端UI组件KuboardSpray API接口详解自动化集成与二次开发指南KuboardSpray API接口详解自动化集成与二次开发指南 KuboardSpray 是一款强大的图形化工具专为离线安装、维护和升级高可用 Kuber上一篇Nucleus迁移指南从AsyncTask和Loader平滑过渡到MVP架构的终极解决方案下一篇Docker部署LX Music Sync Server简单高效的容器化方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考