提升媒体播放体验：深入探索 Media3 的 PreloadManager - 第二部分

作者：Mayuri Khinvasara Khabya - 开发者关系工程师（LinkedIn 和 X）

欢迎来到我们关于 Media3 媒体预加载的三部分系列的第二部分。本系列旨在指导您在 Android 应用中构建高响应性、低延迟的媒体体验。

第一部分：Media3 预加载简介 涵盖了基础知识。我们探讨了用于简单播放列表的 PreloadConfiguration 与用于动态用户界面的更强大的 DefaultPreloadManager 之间的区别。您学习了如何实现基本的 API 生命周期：使用 add() 添加媒体，使用 getMediaSource() 检索准备好的 MediaSource，使用 setCurrentPlayingIndex() 和 invalidate() 管理优先级，以及使用 remove() 和 release() 释放资源。

第二部分（本文）： 在本博客中，我们探索 DefaultPreloadManager 的高级功能。我们涵盖如何使用 PreloadManagerListener 获取洞察，实现生产就绪的最佳实践（如与 ExoPlayer 共享核心组件），并掌握滑动窗口模式以有效管理内存。

第三部分： 本系列的最后一部分将深入探讨如何将 PreloadManager 与持久性磁盘缓存集成，使您能够通过资源管理减少数据消耗并提供无缝体验。

如果您是 Media3 预加载的新手，我们强烈建议您在继续之前阅读第一部分。对于那些准备超越基础知识的读者，让我们探索如何提升您的媒体播放实现。

监听：使用 PreloadManagerListener 获取分析数据

当您希望在生产环境中启动某个功能时，作为应用开发者，您也希望理解并捕获其背后的分析数据。您如何确定您的预加载策略在真实环境中是有效的？回答这个问题需要关于成功率、失败和性能的数据。PreloadManagerListener 接口是收集这些数据的主要机制。

PreloadManagerListener 提供了两个基本的回调，为预加载过程和状态提供了关键的洞察。

• onCompleted(MediaItem mediaItem)：当预加载请求成功完成时（由您的 TargetPreloadStatusControl 定义），会调用此回调。
• onError(PreloadException error)：此回调对于调试和监控非常有用。当预加载失败时，会调用此回调，并提供相关的异常。

您可以通过单个方法调用注册监听器，如下面的示例代码所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

val preloadManagerListener = object : PreloadManagerListener {
    override fun onCompleted(mediaItem: MediaItem) {
        // 记录成功以进行分析。
        Log.d("PreloadAnalytics", "Preload completed for $mediaItem")
    }

    override fun onError( preloadError: PreloadException) {
        // 记录特定错误以进行调试和监控。
        Log.e("PreloadAnalytics", "Preload error ", preloadError)
    }
}

preloadManager.addListener(preloadManagerListener)

从监听器中提取洞察

这些监听器回调可以连接到您的分析管道。通过将这些事件转发到您的分析引擎，您可以回答关键问题，例如：

• 我们的预加载成功率是多少？（onCompleted 事件与总预加载尝试次数的比率）
• 哪些 CDN 或视频格式显示出最高的错误率？（通过解析来自 onError 的异常）
• 我们的预加载错误率是多少？（onError 事件与总预加载尝试次数的比率）

这些数据可以为您提供关于预加载策略的定量反馈，从而实现 A/B 测试和数据驱动的用户体验改进。这些数据还可以进一步帮助您智能地微调预加载持续时间、您想要预加载的视频数量以及您分配的缓冲区。

超越调试：使用 onError 实现优雅的 UI 回退

失败的预加载强烈表明用户即将遇到缓冲事件。onError 回调允许您做出响应。您不仅可以记录错误，还可以调整 UI。例如，如果下一个视频预加载失败，您的应用程序可以禁用下一次滑动的自动播放，要求用户点击才能开始播放。

此外，通过检查 PreloadException 类型，您可以定义更智能的重试策略。应用程序可以根据错误消息或 HTTP 状态码选择立即从管理器中移除失败的源。相应的项目也需要从 UI 流中移除，以免加载问题影响用户体验。您还可以从 PreloadException（如 HttpDataSourceException）中获取更细粒度的数据以进一步探究错误。阅读更多关于 ExoPlayer 故障排除的信息。

伙伴系统：为什么与 ExoPlayer 共享组件是必要的？

DefaultPreloadManager 和 ExoPlayer 被设计为协同工作。为了确保稳定性和效率，它们必须共享几个核心组件。如果它们使用独立的、不协调的组件运行，可能会影响线程安全以及预加载轨道在播放器上的可用性，因为我们需要确保预加载的轨道应该在正确的播放器上播放。独立的组件还可能竞争有限的资源，如网络带宽和内存，这可能导致性能下降。生命周期的一个重要部分是处理适当的处置，推荐的处置顺序是先释放 PreloadManager，然后是 ExoPlayer。

DefaultPreloadManager.Builder 旨在促进这种共享，并提供 API 来实例化您的 PreloadManager 和链接的播放器实例。让我们看看为什么必须共享 BandwidthMeter、LoadControl、TrackSelector、Looper 等组件。请查看这些组件如何与 ExoPlayer 播放交互的可视化表示。

使用共享的 BandwidthMeter 防止带宽冲突

BandwidthMeter 根据历史传输速率提供可用网络带宽的估计。如果 PreloadManager 和播放器使用不同的实例，它们彼此不了解对方的网络活动，这可能导致故障场景。例如，考虑这样一个场景：用户正在观看视频，他们的网络连接质量下降，而预加载的 MediaSource 同时为未来的视频启动了激进的下载。预加载 MediaSource 的活动将消耗活动播放器所需的带宽，导致当前视频卡顿。播放期间的卡顿是严重的用户体验失败。

通过共享单个 BandwidthMeter，TrackSelector 能够在预加载或播放期间，根据当前网络条件和缓冲区状态选择最高质量的轨道。然后它可以做出智能决策来保护活动播放会话并确保流畅的体验。

1

preloadManagerBuilder.setBandwidthMeter(customBandwidthMeter)

使用 ExoPlayer 的共享 LoadControl、TrackSelector、Renderer 组件确保一致性

• LoadControl： 此组件决定缓冲策略，例如在开始播放前要缓冲多少数据，以及何时开始或停止加载更多数据。共享 LoadControl 可确保播放器和 PreloadManager 的内存消耗由单一、协调的缓冲策略指导，涵盖预加载和主动播放的媒体，防止资源争用。您必须智能地分配缓冲区大小，与您预加载的项目数量及其持续时间相协调，以确保一致性。在争用期间，播放器将优先播放屏幕上显示的当前项目。使用共享的 LoadControl，只要为预加载分配的目标缓冲字节未达到上限，预加载管理器将继续预加载，它不会等待播放加载完成。

注意： 在最新版本的 Media3 (1.8) 中共享 LoadControl 确保其 Allocator 可以与 PreloadManager 和播放器正确共享。使用 LoadControl 有效控制预加载是一个将在即将发布的 Media3 1.9 版本中可用的功能。

1

preloadManagerBuilder.setLoadControl(customLoadControl)

• TrackSelector： 此组件负责选择要加载和播放的轨道（例如，特定分辨率的视频、特定语言的音频）。共享可确保预加载期间选择的轨道与播放器将使用的轨道相同。这避免了一种浪费的情况：预加载了 480p 视频轨道，结果播放器在播放时立即丢弃它并获取 720p 轨道。

预加载管理器不应与播放器共享相同的 TrackSelector 实例。相反，它们应使用不同的 TrackSelector 实例，但属于相同的实现。这就是为什么我们在 DefaultPreloadManager.Builder 中设置 TrackSelectorFactory 而不是 TrackSelector。

1

preloadManagerBuilder.setTrackSelectorFactory(customTrackSelectorFactory)

• Renderer： 此组件负责在不创建完整渲染器的情况下理解播放器的能力。它检查此蓝图以查看最终播放器将支持哪些视频、音频和文本格式。这使其能够智能地选择并仅下载兼容的媒体轨道，并防止浪费带宽在播放器实际上无法播放的内容上。

1

preloadManagerBuilder.setRenderersFactory(customRenderersFactory)

阅读更多关于 Exoplayer 组件的信息。

黄金法则：一个通用的 Playback Looper 来统治它们所有

可以访问 ExoPlayer 实例的线程可以通过在创建播放器时传递 Looper 来显式指定。必须从中访问播放器的线程的 Looper 可以使用 Player.getApplicationLooper 查询。通过在播放器和 PreloadManager 之间维护一个共享的 Looper，可以保证所有这些共享媒体对象上的所有操作都被序列化到单个线程的消息队列中。这可以减少并发错误。

PreloadManager 和播放器之间所有与要加载或预加载的媒体源的交互都需要在同一个播放线程上发生。共享 Looper 对于线程安全是必须的，因此我们必须在 PreloadManager 和播放器之间共享 PlaybackLooper。

PreloadManager 在后台准备一个有状态的 MediaSource 对象。当您的 UI 代码调用 player.setMediaSource(mediaSource) 时，您正在将这个复杂的、有状态的对象从预加载 MediaSource 移交给播放器。在这种情况下，整个 PreloadMediaSource 从管理器移动到播放器。所有这些交互和移交都应发生在同一个 PlaybackLooper 上。

如果 PreloadManager 和 ExoPlayer 在不同的线程上运行，则可能发生竞态条件。PreloadManager 的线程可能正在修改 MediaSource 的内部状态（例如，将新数据写入缓冲区），而恰好此时播放器的线程正试图从中读取数据。这会导致难以调试的不可预测行为、IllegalStateException。

1

preloadManagerBuilder.setPreloadLooper(playbackLooper)

让我们看看您如何在设置本身中在 ExoPlayer 和 DefaultPreloadManager 之间共享所有上述组件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

val preloadManagerBuilder =
DefaultPreloadManager.Builder(context, targetPreloadStatusControl)

// 可选 - 在 ExoPlayer 和 DefaultPreloadManager 之间共享组件
preloadManagerBuilder
     .setBandwidthMeter(customBandwidthMeter)
     .setLoadControl(customLoadControl)
     .setMediaSourceFactory(customMediaSourceFactory)
     .setTrackSelectorFactory(customTrackSelectorFactory)
     .setRenderersFactory(customRenderersFactory)
     .setPreloadLooper(playbackLooper)

val preloadManager = val preloadManagerBuilder.build()

提示： 如果您在 ExoPlayer 中使用默认组件，如 DefaultLoadControl 等，则无需显式地与 DefaultPreloadManager 共享它们。当您通过 DefaultPreloadManager.Builder 的 buildExoPlayer 构建 ExoPlayer 实例时，如果您使用具有默认配置的默认实现，这些组件会自动相互引用。但如果您使用自定义组件或自定义配置，则应通过上述 API 显式通知 DefaultPreloadManager。

生产就绪的预加载：滑动窗口模式

在动态信息流中，用户可以滚动浏览几乎无限量的内容。如果您不断向 DefaultPreloadManager 添加视频而没有相应的移除策略，您将不可避免地导致 OutOfMemoryError。每个预加载的 MediaSource 都持有一个 SampleQueue，它会分配内存缓冲区。随着这些缓冲区的累积，它们可能会耗尽应用程序的堆空间。解决方案是您可能已经熟悉的算法，称为滑动窗口。

滑动窗口模式在内存中维护一小部分逻辑上相邻于用户当前在信息流中位置的可管理项目集。随着用户滚动，这个被管理项目的“窗口”随之滑动，添加进入视图的新项目，并移除现在较远的项目。

实现滑动窗口模式

必须理解 PreloadManager 不提供内置的 setWindowSize() 方法。滑动窗口是一种设计模式，您作为开发人员负责使用原始的 add() 和 remove() 方法来实现。您的应用程序逻辑必须将 UI 事件（例如滚动或页面更改）连接到这些 API 调用。如果您需要此模式的代码参考，我们在 socialite 示例中实现了这个滑动窗口模式，其中还包括一个模仿滑动窗口的 PreloadManagerWrapper。

在您的实现中，当项目不太可能很快出现在用户的观看列表中时，不要忘记添加 preloadManager.remove(mediaItem)。未能移除不再接近用户的项目是预加载实现中内存问题的主要原因。remove() 调用确保资源被释放，帮助您保持应用程序的内存使用受限且稳定。

使用 TargetPreloadStatusControl 微调分类预加载策略

既然我们已经定义了预加载什么（我们窗口中的项目），我们可以为每个项目应用一个定义明确的策略来确定预加载多少。我们已经在第一部分中看到了如何通过 TargetPreloadStatusControl 设置来实现这种粒度。

回顾一下，位置 +/- 1 的项目比位置 +/- 4 的项目有更高的播放概率。您可以分配更多资源（网络、CPU、内存）给用户最有可能接下来观看的项目。这创建了一个基于接近度的“预加载”策略，这是平衡即时播放与高效资源使用的关键。

您可以使用通过 PreloadManagerListener 获取的分析数据（如前面章节讨论的）来决定您的预加载持续时间策略。

结论和后续步骤

您现在已掌握高级知识，可以使用 Media3 的 DefaultPreloadManager 构建快速、稳定且资源高效的媒体信息流。

让我们回顾一下关键要点：

• 使用 PreloadManagerListener 收集分析洞察并实现稳健的错误处理。
• 始终使用单个 DefaultPreloadManager.Builder 来创建您的管理器和播放器实例，以确保共享重要组件。
• 通过主动管理 add() 和 remove() 调用来实现滑动窗口模式，以防止 OutOfMemoryError。
• 使用 TargetPreloadStatusControl 创建智能的、分层的预加载策略，以平衡性能和资源消耗。

第三部分接下来是什么：预加载媒体的缓存

将数据预加载到内存中提供了即时的性能优势，但可能会带来一些权衡。一旦应用程序关闭或预加载的媒体从管理器中移除，数据就消失了。为了实现更持久的优化级别，我们可以将预加载与磁盘缓存结合起来。此功能正在积极开发中，并将在几个月内推出。

您有任何反馈要分享吗？我们渴望听取您的意见。

敬请关注，让您的视频播放更快！🚀