HarmonyOS 7 + AVSession Kit + Audio Kit 技术干货：媒体会话、后台播放与系统播控联动机制【鸿蒙心迹】

NNNbied

27人浏览 · 2026-09-29 00:11:48

NNNbied · 2026-09-29 00:11:48 发布

音频能播放，只能说明播放器本身能工作；真正做成系统级媒体体验，还要让系统媒体中心、耳机、车载、手表等控制入口理解“现在播的是什么、播放到哪里、点击暂停以后该通知谁”。这篇文章从播放器内部状态出发，把 Audio Kit 与 AVSession Kit 的分工和联动链路完整拆开。

一、为什么播放器已经能播了，还需要 AVSession

第一次做音频播放时，很容易觉得播放器逻辑已经完整：创建播放实例、加载资源、播放、暂停、上一首、下一首，再做一个进度条，功能就差不多了。

这种实现放在应用内部确实能用。

但只要用户把应用退到后台，或者希望在系统控制中心、锁屏界面、蓝牙耳机、车载设备上控制播放，问题就出现了。

系统并不知道你的页面上哪一个按钮代表“播放”，也不知道当前歌曲叫什么、播放到哪一秒、下一首是谁。你的播放器状态只存在于自己的业务代码里，系统世界并没有“看见”它。

AVSession Kit 就是把这层信息从应用内部带到系统媒体会话层。

它的核心价值可以理解成两部分：

应用把媒体元数据和播放状态同步给系统；
系统或外设产生的播放控制指令，再通过会话回传给应用。

所以 Audio Kit / AVPlayer 解决“声音怎么真正播出来”，AVSession 解决“系统怎样理解和控制这次播放”。

两者不是替代关系，而是上下两层。

二、先把播放器状态和会话状态分开

这类功能最容易犯的错误，就是直接把播放器对象当成系统会话。

播放器内部通常有自己的状态，比如：

当前资源是否加载；
是否正在播放；
当前 position；
音量；
播放列表；
输出设备。

而 AVSession 维护的是系统播控需要看到的一组信息：

当前媒体元数据；
播放 / 暂停 / 停止状态；
播放位置；
可响应的控制事件；
当前输出设备和会话是否激活。

如果把这两层混在一起，后面最容易出现状态不同步：页面显示播放中，系统控制中心显示暂停；耳机按了暂停，但应用 UI 没变；切下一首以后声音变了，系统封面还停留在上一首。

所以我更推荐把播放层和会话层拆成两个 Service，再用统一的状态更新方法连接。

三、创建 AVSession 时，第一件事不是 setMetadata，而是把生命周期想清楚

AVSession 的典型入口是创建会话并激活。

官方能力里，应用可以创建 AVSession，设置媒体元数据和播放状态，并响应播放、暂停、上一首、下一首等控制事件。工程上真正要注意的是：会话应该和媒体播放生命周期一起管理，而不是页面一进来就永远创建一个。

我会把会话初始化单独封装：

import { avSession } from '@kit.AVSessionKit'

export class MediaSessionService {
  private session: avSession.AVSession | null = null

  async create(context: Context) {
    if (this.session) return

    this.session = await avSession.createAVSession(
      context,
      'music_session',
      'audio'
    )

    await this.session.activate()
    this.registerControllerEvents()
  }

  async destroy() {
    if (!this.session) return
    await this.session.deactivate()
    await this.session.destroy()
    this.session = null
  }
}

这段代码最关键的是 activate / deactivate / destroy 这条生命周期链。

很多联动异常，并不是 setMetadata 写错了，而是会话已经失效、重复创建，或者播放结束以后没有释放。尤其当页面多次进入退出时，如果会话生命周期没有收口，很容易出现控制事件重复响应。

四、系统媒体中心到底靠什么知道“现在播的是哪首歌”

答案就是媒体元数据。

只让系统知道“现在正在播放”是不够的，还要同步标题、作者、专辑、封面等内容。否则控制中心最多只能出现一个没有上下文的播放状态。

切歌时，我通常会把“播放器切换资源”和“会话元数据更新”放到同一个业务动作里：

async syncMetadata(track: Track) {
  if (!this.session) return

  await this.session.setAVMetadata({
    assetId: track.id,
    title: track.title,
    artist: track.artist,
    album: track.album,
    mediaImage: track.coverUri
  })
}

async syncPlaybackState(isPlaying: boolean, position: number) {
  if (!this.session) return

  await this.session.setAVPlaybackState({
    state: isPlaying
      ? avSession.PlaybackState.PLAYBACK_STATE_PLAY
      : avSession.PlaybackState.PLAYBACK_STATE_PAUSE,
    position: {
      elapsedTime: position,
      updateTime: Date.now()
    }
  })
}

不同 API 版本的字段和枚举要以当前 SDK 为准，但工程原则很固定：播放器状态发生变化时，会话状态要跟着变。

页面上的 UI 不应该是第三套独立状态，而应该和播放器、AVSession 共用同一份业务状态源。

五、系统控制事件不是“通知”，而是业务指令

AVSession 真正有价值的地方，在于它不是单向上报。

系统控制中心、耳机、手表、车载等控制端发出“播放、暂停、下一首”时，应用会收到会话事件。此时不能只记一条日志，而要真正驱动播放器。

我会在会话初始化时统一注册这些事件：

private registerControllerEvents() {
  if (!this.session) return

  this.session.on('play', async () => {
    await playerService.play()
    await this.syncPlaybackState(true, playerService.position)
  })

  this.session.on('pause', async () => {
    await playerService.pause()
    await this.syncPlaybackState(false, playerService.position)
  })

  this.session.on('playNext', async () => {
    const track = await playerService.next()
    await this.syncMetadata(track)
    await this.syncPlaybackState(true, 0)
  })

  this.session.on('playPrevious', async () => {
    const track = await playerService.previous()
    await this.syncMetadata(track)
    await this.syncPlaybackState(true, 0)
  })
}

这就是系统播控真正的闭环：

外部控制事件 → AVSession → 播放器业务 → 更新播放结果 → 再同步 AVSession 状态。

中间任何一步断掉，用户都会感觉“系统按钮按了没反应”或者“按了以后 UI 不对”。