1. 从静态菜谱到动态教学智慧屏缺的正好是“播放能力”厨房里最怕的不是锅没热而是屏幕上写着“切丝、焯水、爆香”手却不知道从哪里开始。做“灵犀厨房”这个智慧屏项目的时候这个问题一直卡着我。直到我在HarmonyOS 6.1里用AVPlayer把教学视频嵌进菜谱页整个产品才算真正“活”过来。1.1 厨房大屏的尴尬图片轮播讲不清“怎么做”“灵犀厨房”是跑在智慧屏上的全场景应用核心场景是做饭时看着屏幕学做菜。早期版本用的是图片轮播一张切好的土豆丝图配上一句“切成均匀细丝”。听起来没毛病但真正进厨房测试时用户反复问的是同一句话——“这一步到底是怎么切的切多细”静态图片能展示结果但展示不了过程。尤其像颠勺、揉面、给鱼改刀、观察油温这类动作文字和图片的还原度非常有限。我当时认识到菜谱页必须有一个能播视频的模块而且这个模块不能是打开系统播放器那种割裂体验必须直接嵌在菜谱页里跟步骤列表、食材清单、计时器融为一体。HarmonyOS 6.1的AVPlayer正好承担这个角色。它是系统媒体框架里负责音视频播放的核心组件支持本地资源、网络流、HLS等常见直播点播场景而且能通过surface直接渲染到ArkUI的XComponent上。也就是说视频不是“弹窗出去播”而是长在页面里这才能做后续的多媒体交互。1.2 AVPlayer在灵犀厨房里的定位与技术选型在动手写代码之前我先理清了一个问题智慧屏上的教学视频到底需要播放器具备哪些能力第一是“嵌入页面”不是“跳转播放”。视频画面必须作为页面的一部分下方还能保留步骤文字、调料用量。第二是“可控”用户可能要暂停下来看手部动作要拖动进度条回看某一步甚至要0.5倍速慢放。第三是“生命周期安全”离开菜谱页、切换菜品、熄屏待机时播放器不能残留、不能继续出声。基于这三点AVPlayer是比Video组件更偏底层的选择。Video组件用起来简单但定制能力、状态控制粒度和生命周期管理都不够细。AVPlayer则把播放器状态完全暴露给我们相当于把“做完一道菜”的流程拆成了备菜、下锅、出锅、洗锅几个明确阶段我们可以在每个阶段插入自己的逻辑。如果你只想快速验证“大屏能不能播视频”直接堆一个Video组件确实更快。但如果你做的是正式项目后面还要接推荐位自动播放、商品讲解、多设备续播那直接上AVPlayer反而省事。2. AVPlayer播放链路从视频源到屏幕的一整套状态机AVPlayer最需要理解的不是play、pause这两个方法而是它的状态机。任何一个播放器中间环节出错都会卡在某个状态UI却没反应这是新手最容易踩的坑。2.1 播放器不是“一放了之”AVPlayer的状态迁移AVPlayer有八种常用状态idle、initialized、prepared、playing、paused、completed、stopped、released再加上一个出错时的error。可以这么记idle是播放器刚创建还没分配资源initialized是已经设置了播放源但还没准备好prepared是加载好元数据随时能播playing是真正开始输出画面paused是暂停在某个时间点completed是播完了stopped是主动停止但还能重置released是彻底释放资源。我见过不少人直接调play()结果没声音没画面就是因为跳过了准备流程。播放器的正常路径必须是创建播放器 - 设置视频源 - 绑定surfaceId -prepare()- 进入prepared后再play()。StateChange事件就是这张状态机的实时上报。我在项目里一定会先挂监听再走后续流程避免错过状态变化import media from ohos.multimedia.media; this.avPlayer.on(stateChange, (state: media.AVPlayerState) { console.info(灵犀厨房 AVPlayer state: ${state}); if (state prepared) { // 进入准备完成状态此时可以获取时长也可以发起播放 this.isPrepared true; } });不同状态之间的流转是有条件的不能胡思乱想地乱跳。比如在playing状态直接release()会报错必须先把播放器停到安全状态。这跟炒菜一个道理锅还烧着就想直接关煤气端走容易出事。2.2 视频画面的承载XComponent和surface的关系AVPlayer本身不负责画界面它只负责把解码后的画面输出到一个surfaceId上。在HarmonyOS 6.1里ArkUI侧提供了一个XComponent类型设为surface时它会生成一个原生surface我们把它的ID交给AVPlayer视频画面就渲染上去了。XComponent的写法很固定State surfaceId: string ; private xComponentController: XComponentController new XComponentController(); build() { XComponent({ id: recipeVideoSurface, type: surface, controller: this.xComponentController }) .width(100%) .height(320) .onLoad(() { this.surfaceId this.xComponentController.getXComponentSurfaceId(); this.initPlayer(); }) }有一个细节容易被忽略surface的创建是异步的onLoad回调才是安全获取surfaceId的时机。如果你在aboutToAppear里急着初始化播放器大概率拿到的是空字符串视频就一直黑屏。surface和播放器是一对一关系。切换视频时如果旧播放器还占着surface新播放器要么渲染不出来要么画面花屏。正确做法是先把旧播放器释放干净再把新的surfaceId交给新播放器。这个顺序问题我在后面“实测中遇到的坑”里会展开讲。3. 把教学视频嵌进智慧屏ArkTS代码级实现光说不练没意思。这一节给出“灵犀厨房”里实际可用的代码骨架从创建播放器到释放完整串一遍。3.1 初始化播放器与绑定画面初始化这一步要做的事很多创建AVPlayer、绑定错误监听、绑定状态监听、设置surfaceId。我会把它包成一个独立的initPlayer方法方便页面加载时调用。import media from ohos.multimedia.media; const TAG LingxiKitchen; export class RecipeVideoPlayer { private avPlayer: media.AVPlayer | null null; private surfaceId: string ; private isPrepared: boolean false; private loadToken: number 0; async initPlayer(surfaceId: string) { this.surfaceId surfaceId; this.loadToken; const currentToken this.loadToken; // 每次都先清掉旧播放器避免状态混乱 await this.releasePlayer(); try { this.avPlayer await media.createAVPlayer(); this.avPlayer.on(stateChange, (state: media.AVPlayerState) { if (currentToken ! this.loadToken) { return; // 收到的是旧播放器的状态直接忽略 } console.info(${TAG} state - ${state}); if (state prepared) { this.isPrepared true; } }); this.avPlayer.on(error, (err) { console.error(${TAG} error - ${JSON.stringify(err)}); }); this.avPlayer.surfaceId this.surfaceId; } catch (e) { console.error(${TAG} initPlayer failed: ${JSON.stringify(e)}); } } }看到我用了loadToken这个不是多余的。真实场景里用户可能快速切换菜谱第一次加载还没完成第二次加载又开始了如果不对播放器实例做区分旧播放器的回调会跑到新逻辑里出现“视频刚准备完就被释放”的怪现象。3.2 设置播放源、准备与自动播放播放源可以来自本地resource也可以来自网络地址。在智慧屏场景中我建议教学视频优先走本地打包或者放在自己的内容服务器上用HLS切片这样拖动进度条体验更好。async loadVideo(videoUrl: string) { if (!this.avPlayer) { console.error(${TAG} player not initialized); return; } try { this.isPrepared false; this.avPlayer.url videoUrl; await this.avPlayer.prepare(); // 等待 stateChange 进入 prepared 之后再执行播放 if (this.isPrepared) { this.avPlayer.play(); } } catch (e) { console.error(${TAG} loadVideo error: ${JSON.stringify(e)}); } }这里有一个时序点prepare()返回之后播放器不一定已经进入prepared状态因为状态切换是异步上报的。所以我更推荐在stateChange里收到prepared再调play()而不是在await prepare()之后直接调。如果视频源本身有问题直接调play()会得到一个无处安放的错误回调排查起来很麻烦。3.3 播放控制与状态监听播放、暂停、跳转这三个能力是多媒体交互的地基。在“灵犀厨房”里视频下面是步骤区用户点击步骤会触发跳转点击画面会暂停再次点击继续。play() { if (this.avPlayer this.isPrepared) { this.avPlayer.play(); } } pause() { if (this.avPlayer this.isPrepared) { this.avPlayer.pause(); } } async seekTo(timeMs: number) { if (this.avPlayer this.isPrepared) { await this.avPlayer.seek(timeMs); } } release() { this.loadToken; this.releasePlayer(); }播放进度这块我会在prepared状态时读取duration得到总时长然后监听timeUpdate事件更新当前进度。UI层只需要维护两个State变量就能驱动进度条和剩余时间this.avPlayer.on(timeUpdate, (time: number) { this.currentTime time; });3.4 离开页面时的释放逻辑很多播放器问题都是“只记得播不记得关”引起的。智慧屏常驻场景下如果用户离开菜谱页后播放器还在后台跑轻则白耗内存重则跟下一个页面的播放器抢音频焦点。我在页面的aboutToDisappear里做了统一释放aboutToDisappear() { this.videoPlayer.release(); }release()不是stop()。stop()还能让播放器回到stopped状态之后可以重新preparerelease()是彻底销毁播放器释放底层解码器和surface资源。离开页面退役的播放器就应该直接release()而不是留着“方便下次复用”。4. 多媒体交互体验播放器与UI联动的几个关键点做智慧屏和做手机App最大的不同是用户距离远、操作方式少、观看时间长。视频模块不能只是“能播”还得跟整个页面有交互感。4.1 进度条、时间文案与手势控制智慧屏通常用遥控器操作实体按键只有上下左右和确认所以交互要尽量简单。我把进度条设计成一种“轻量滑块”默认只显示一条细线和时间文案用户按确认键后进入“拖动调节”模式再用方向键微调。控件层用ArkUI的Slider就能实现Slider({ value: this.currentTime, min: 0, max: this.duration, style: SliderStyle.OutSet }) .onChange((value: number, mode: SliderChangeMode) { if (mode SliderChangeMode.Moving) { this.videoPlayer.pause(); } else if (mode SliderChangeMode.End) { this.videoPlayer.seekTo(Math.floor(value)); this.videoPlayer.play(); } })拖动过程中先暂停松手后再定位播放这个交互细节很重要。如果不暂停画面和进度条会互相打架用户根本看不清拖到了哪一秒。时间文案我习惯用两个文本拼在进度条两端左边是当前时间右边是总时长。格式统一为“分:秒”超过一小时再显示小时别让“5:67”这种数据露出来。4.2 音频焦点与智慧屏场景下的声音处理智慧屏往往摆在一室一厅的核心位置声音一响会影响全家。所以播放教学视频时我不建议默认满音量。AVPlayer可以通过setVolume控制播放音量// 初始音量给到 0.7留出余量 this.avPlayer.setVolume(0.7);如果页面里同时有其他声音模块比如语音助手、计时器提醒一定要做好音频焦点协商。我的经验是视频播放时其他提示音要降低音量或者抢到焦点时自动暂停视频视频被系统打断后要能恢复播放而不是一直僵在那里。这里不需要复杂逻辑只需要在on(error)和音频打断回调里把UI状态复位。4.3 封面、加载蒙层与错误重试的交互设计视频加载是需要时间的尤其第一次拉流。如果用户看到一片黑会觉得设备卡死了。我在XComponent上面套了一层Stack先显示菜谱封面图等播放器进入prepared或者playing后再淡出封面。错误处理也必须做。智慧屏的网络环境有时候不稳定error回调触发后不能只打日志得给用户一个明确的“加载失败重试”按钮同时把底层播放器reset回可复用状态async handleError() { if (this.avPlayer) { await this.avPlayer.reset(); this.isPrepared false; } // 通知UI显示错误重试区域 this.videoState VideoState.ERROR; }这样处理之后用户按一下重试就可以重新走loadVideo流程而不是被迫退出页面重新进。5. 实测中遇到的坑格式、网络缓冲、生命周期以下这些问题都是我在这套智慧屏项目里真正踩过的每一次排查都花了不少时间。既然做“实战”记录这些坑得原原本本写出来。5.1 视频源格式与封装别让播放器卡在“黑屏”我在早期测试时拿了一个MKV格式的视频文件在电脑上播放毫无问题塞到智慧屏应用里直接黑屏。查了日志才知道当前AVPlayer的解码支持是有范围的不能拿“电脑能播”当作“播放器能播”。我的经验是优先使用下面这个组合场景推荐封装推荐编码音频编码本地教学视频MP4H.264AAC网络点播长视频HLS (m3u8)H.264AAC临时短视频MP4 / fast startH.264AAC尽量不要碰MKV、FLV、WMV这类封装也不要直接用高码率HEVC除非你明确知道目标设备的硬解能力。MP4里的moov原子最好前置否则播放器需要先下载一大段索引才能开始播放拖进度条时还会卡顿。这个问题本质上不是AVPlayer的bug而是多媒体处理里的“源格式”问题。做内容管理后台时我会把上传视频统一转码成H.264AAC的MP4再根据网络情况生成720P和1080P两档清晰度。5.2 切换菜谱时的播放器状态冲突“灵犀厨房”的菜谱列表和详情页是联动的用户看完红烧肉返回列表又点开糖醋排骨这时详情页可能重新创建也可能被系统复用。如果播放器没有跟页面生命周期同步就会出现两个播放器实例同时存在的情况。我更推荐把播放器实例放在“详情页控制器”里而不是系统单例里。每个详情页持有一个RecipeVideoPlayer页面销毁时统一释放。页面还没销毁但视频源变化时也要走完整的“释放旧播放器 - 创建新播放器”流程不能只改URL。这个坑的症状很隐蔽第二次进入菜谱页时视频偶尔有画面没声音偶尔有声音没画面。原因就是surface被多个播放器轮番绑定状态串了。用了loadToken加上严格释放顺序后这个问题没再出现过。5.3 低端智慧屏的surface释放时序低端设备上surface的创建和销毁速度比高端设备慢不少。如果页面退出动画还没结束我就把XComponent销毁了同时调用播放器release()有概率导致底层surface指针失效应用闪退。解决办法是把播放器释放时机放到onPageHide里并且不要立刻销毁XComponent如果必须销毁就等一帧再释放播放器。代码上可以用setTimeout缓一下虽然听起来不太“优雅”但在某些硬件上非常管用onPageHide() { // 先停止播放等页面动画结束后再彻底释放 this.videoPlayer.pause(); setTimeout(() { this.videoPlayer.release(); }, 500); }另外如果XComponent被用在if/else分支里条件切换时务必要在分支离开前释放播放器。ArkUI的组件销毁是异步的不能假设XComponent还在页面上。6. 从厨房到全场景一种可复用的多媒体嵌入打法视频嵌入这件事做完之后我突然发现这套东西的可复制性极强。本质上它就是一个“页面内嵌视频播放器”的标准方案适用于各种大屏场景。6.1 同样的模板用在智慧销售屏与导览屏只要把视频地址换成商品讲解视频把步骤列表换成商品参数把封面换成商品主图这套AVPlayer方案就变成了一个智慧销售大屏模板。线下门店的导购屏、电梯广告屏、展会互动屏本质上都是同一套逻辑一个页面、一张封面、一个播放器、一组控制按钮、一套错误重试机制。我在项目文档里把“灵犀厨房”的视频模块做成了独立组件UI通过参数注入视频源通过数据驱动。换成其他项目时只需要改数据协议和视觉样式播放链路完全不用动。这就是多媒体交互设计的价值方案不是为某一个菜品定制的而是为一类屏幕定制的。6.2 后续扩展方向断点续播、多端协同与内容推荐HarmonyOS 6.1的“全场景”不只是说说。我在“灵犀厨房”里已经留了几个扩展点第一个是断点续播把播放时间和视频URL写入本地数据库用户下次打开同一个菜谱直接接着上次进度播。第二个是多端协同手机端浏览菜谱时一键把视频地址和播放位置无缝流转到大屏上大屏自动续播。第三个是内容推荐视频播完后根据当前菜品关联推荐下一个教学视频让用户连续学下去。这些方向都不需要推翻现有代码播放器层依然是AVPlayer变化的是上层的数据编排和状态同步。最后再分享一个我实际做完的体会智慧屏上的视频功能难点从来不在“怎么调起一个播放器”而在于能不能把播放器的生命周期、页面生命周期和用户操作节奏对齐。AVPlayer给你的不是一串API而是一整套关于“什么时候该播、什么时候该停、什么时候该释放”的思路。想明白这一点你手里的智慧屏才算真正“活”起来了。