尧图精选

react-native-video v7 播放控制:VideoPlayer 实例方法、Feed 预加载与生命周期管理

🕒 发布时间:2026/11/2 9:43:15 📁 来源:尧图网络
音视频移动开发【免费下载链接】react-native-videoA component for react-native项目地址https://gitcode.com/gh_mirrors/re/react-native-video点击查看免费下载导读v7 把播放控制从组件 props 迁到了播放器实例上——useVideoPlayer创建的VideoPlayer对象不再只是挂在VideoView上的配置而是具备play()、pause()、seekTo()、replaceSourceAsync()、preload()等完整控制能力的独立实体。本文以skills/react-native-video/references/v7/playback-control.md为核心结合packages/react-native-video/src/core/VideoPlayer.ts、useVideoPlayer.ts与 e2e 冒烟测试系统讲解 v7 的实例方法、常见操作模式、Feed 短视频流式预加载架构以及播放器的生命周期管理。读完你将掌握如何用实例方法实现播放/暂停/跳转/换源如何在列表 Feed 中用preload()实现未挂载即缓冲以及何时该用 hook、何时必须用 class 并自己负责release()。一、v7 控制模型控制发生在播放器实例上v7 的核心设计变化是控制发生在 player 实例上而不是 props也不是对组件的 ref。也就是说VideoView负责显示画面而VideoPlayer负责播放行为——播放器与视图解耦。useVideoPlayer(source, setup?)在组件内创建VideoPlayer并管理其生命周期source 变化时重建、卸载时自动 release适用于绝大多数组件内播放场景。new VideoPlayer(source)class 形式播放器可以脱离组件生命周期存在但你必须自己调用player.release()。从源码看VideoPlayer.ts 的构造器会把 source 通过createSource()标准化为 hybrid source再经createPlayer()创建原生播放器并基于其eventEmitter初始化事件系统。也就是说JS 层的每个VideoPlayer背后都对应一个原生Nitro hybrid播放器实例。二、方法清单与用法详解核心控制方法方法说明play()开始/恢复播放pause()暂停seekTo(seconds)绝对跳转v6 的seek()对应此方法seekBy(seconds)相对跳转如seekBy(-10)回退 10 秒replaceSourceAsync(source \| null)更换源传null清空源。源本身不可变只能整体替换。返回 Promisepreload()在展示前预缓冲——Feed 场景的关键。返回 Promiseinitialize()仅当initializeOnCreation: false时才需要手动调用release()释放原生资源释放后播放器不可再用。useVideoPlayer会在卸载时替你调用getAvailableTextTracks()/selectTextTrack(t \| null)字幕轨管理详见 tracks-subtitles.mdaddEventListener(event, cb)事件监听返回{ remove() }详见 events.md方法实现的底层细节在 VideoPlayer.ts 中这些方法大多是同步包装原生调用play()/pause()/seekTo()/seekBy()直接透传原生方法并对原生错误做统一解析tryParseNativeVideoError后抛出或触发onError事件VideoPlayer.tspreload()/initialize()/replaceSourceAsync()是异步方法通过wrapPromise()包装原生 Promise出错时同样走错误归一化流程并在成功/失败后调用updateMemorySize()更新 Nitro 的内存统计VideoPlayer.tsreplaceSourceAsync(null)在 VideoPlayer.nitro.ts 中明确注明与release()效果相同——因此不要用先置空源再复用播放器来复用播放器Android 上这会把原生播放器彻底释放掉Feed 场景应当重建播放器。常见操作模式player.isPlaying ? player.pause() : player.play(); // toggle 播放/暂停 player.seekTo(30); // 跳转到 0:30 player.seekBy(15); // 前进 15 秒 player.rate 1.5; // 加速播放0 即暂停 await player.replaceSourceAsync({ uri: nextUrl }); // 换源注意rate 0等价于暂停player.currentTime也可读可写秒作为seekTo之外的另一种跳转方式。e2e 测试对 seek 行为有专门验证e2e/flows/smoke-seek.yaml中先seekTo(5)再回退seekBy通过evt-seek-fwd-landed/evt-seek-back-landed两个派生事件首个onProgress落点 4s 或 2s证明播放器确实移动到了指定位置而不是靠自然播放碰巧通过——这正好印证了seekTo绝对定位与seekBy相对位移的语义。三、初始配置用 setup 回调运行时交互用返回的 playeruseVideoPlayer(source, setup?)的第二个参数setup是只执行一次的配置回调用于设置初始状态loop、volume、muted、autoplay、playInBackground、showNotificationControls、初始seekTo等const player useVideoPlayer( { uri: https://example.com/master.m3u8 }, (player) { player.loop true; player.volume 0.8; }, );不要在组件函数体内直接写player.x ...——组件体每次渲染都会执行而 setup 回调只执行一次。返回的player只用于运行时交互按钮事件、渲染期读取。从 useVideoPlayer.ts 的源码可以看到 setup 的执行时机当initializeOnCreation默认为 true 时hook 会在onLoadStart和onStatusChange两个事件上注册callSetupOnce保证只要播放器开始加载或就绪setup 就一定被调用一次对小体积视频onLoadStart可能早于 JS 事件注册触发所以需要双保险当initializeOnCreation: false时setup 在播放器创建时立即调用。四、预加载下一个视频Feed 场景v7 天生为 Feed 设计——可以提前创建多个播放器并preload()无需先挂载VideoView// 在 setup 回调中预加载加载开始时只执行一次 const next useVideoPlayer({ uri: nextUrl }, (player) player.preload()); // 当用户滑动到时挂载/展示其 VideoView 并调用 next.play()这套预加载 廉价换源正是 v7 相对 v6 在 Feed 场景的核心优势v6 播放器即组件没有一等公民的预取能力只能挂载隐藏/暂停的Video实例来模拟还要紧盯 Android 解码器压力。video-feeds.md 进一步给出了完整 Feed 架构回收列表 全屏吸附 视口门控播放 非对称预加载窗口 缩略图先行。在 iOS 原生实现中preload()的语义可以从 HybridVideoPlayer.swift 的beginPreloadIfNeeded()看到仅当播放器处于idle状态时才开始加载若已在加载/就绪则直接跳过——所以对已加载过的播放器重复调用preload()是安全的幂等操作。Feed 必须使用 hook。用useVideoPlayerpreload()/replaceSourceAsync()预加载可见项及其相邻项这是文档规定的 Feed 模式。只有当播放器必须比组件活得更久时才考虑使用 class——详见 player-model.md 的 hook vs class 一节。五、Feed 性能控制并发播放器数量原生播放器/解码器是稀缺资源Android 尤其紧张通常只能同时解码少数几条 HD 流所以绝不能每个列表项都挂载一个播放器。v7 中播放器与视图解耦你可以不挂载VideoView就preload()——预加载不占视图资源让useVideoPlayer在卸载时自动 release对不再需要的播放器显式调用player.release()给相邻邻居播放器设置更小的bufferConfig降低内存与带宽占用。bufferConfig是 VideoConfig 的字段完整定义见 BufferConfig.tsAndroid 侧有minBufferMs默认 5000、maxBufferMs默认 10000、bufferForPlaybackMs默认 1000、bufferForPlaybackAfterRebufferMs默认 2000、backBufferDurationMs以及直播相关的livePlayback参数iOS 侧有preferredForwardBufferDurationMs、preferredPeakBitRate、preferredMaximumResolution及对应的昂贵网络蜂窝变体。Feed 中给活跃项用正常缓冲、给邻居项调小缓冲是文档推荐的性能实践。六、生命周期管理三条硬规则useVideoPlayer在 source 变化时重建播放器并在卸载时释放它。底层由 useManagedInstance.ts 实现依赖source变化时先cleanup()旧实例再factory()新建卸载时同样走cleanup()它还通过dependenciesEqualFn做深比较避免热刷新Fast Refresh时误销毁实例。如果用new VideoPlayer(...)持有播放器release 责任在你。此时没有 hook 的自动清理兜底。release()之后实例已死——访问其任何属性或方法都会抛错需要时请创建新实例。从源码看release()调用 __destroy()清除所有事件监听 → 调用原生release()失败只console.error绝不让卸载崩溃→ 更新 Nitro 内存统计 →延迟 5 秒才真正置空_player引用以等待 release 前触发的迟到事件处理完毕。而useVideoPlayer的卸载清理正是调用的player.__destroy()useVideoPlayer.ts。另外注意释放后访问播放器会抛出player/released类型的VideoRuntimeErrorYou cant access player after its released见 VideoPlayer.ts这也解释了为什么文档强调release 后必须新建。七、延伸阅读播放器模型hook vs class、属性清单player-model.md事件体系addEventListener与各事件events.md字幕轨选择getAvailableTextTracks/selectTextTracktracks-subtitles.md完整 Feed 架构回收列表、预加载窗口、视口门控、缩略图video-feeds.md源码实现VideoPlayer.ts 与 useVideoPlayer.tse2e 验证smoke-seek.yaml、smoke-mute-volume.yaml小结v7 的播放控制模型可以一句话概括配置交给 setup 回调控制交给 player 实例资源交给生命周期规则。掌握实例方法play/pause/seekTo/seekBy/replaceSourceAsync、Feed 的preload()预加载范式以及hook 自动释放、class 自行负责的生命周期纪律你就能在组件播放、列表流、后台音频等各类场景下正确、高效地使用 react-native-video v7。赞分享音视频移动开发【免费下载链接】react-native-videoA component for react-native项目地址https://gitcode.com/gh_mirrors/re/react-native-video点击查看免费下载相关推荐react-native-video v7 Player 指南VideoPlayer 类的播放控制、配置与生命周期管理react native video v7 Player 指南VideoPlayer 类的播放控制、配置与生命周期管理 本文围绕 react native v音视频移动开发React Native Video v7 VideoPlayer 类完全指南播放控制、缓冲配置与生命周期管理React Native Video v7 VideoPlayer 类完全指南播放控制、缓冲配置与生命周期管理 导读 本文是 react native vid音视频移动开发react-native-video 生命周期管理跨导航与 App 后台的播放控制实战v6 v7react native video 生命周期管理跨导航与 App 后台的播放控制实战v6 v7 本文围绕 react native video 在音视频移动开发上一篇Pixelle-Video终极指南三步实现AI全自动短视频创作下一篇3步快速上手用Ryujinx模拟器在PC畅玩Switch游戏的完整指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
上一篇/下一篇内容由系统自动关联 返回资讯列表 →