鸿蒙NEXT 音视频推送端实践:基于SmartMediaKit实现RTMP推流、轻量级RTSP服务与实时录像
本文探讨了在鸿蒙NEXT生态中构建实时音视频采集与分发能力的工程化解决方案。大牛直播SDK通过模块化设计,将页面编排、能力封装、采集控制和桥接调用有机整合,形成完整的推送端方案。该方案包含页面交互层、统一封装层、采集控制层和桥接层,支持RTMP推流、RTSP服务和实时录像的统一管理。重点解决了摄像头/麦克风采集、预览控制、前后台恢复等实际问题,使鸿蒙设备既能完成RTMP实时上行,又可作为边缘节点进
前言
随着鸿蒙 NEXT 生态持续推进,越来越多行业客户开始关注一个更现实的问题:在国产化终端和鸿蒙业务系统中,如何快速构建稳定的实时音视频采集、发布、分发与留档能力?
对于很多项目来说,真正的难点并不只是“把一路视频推上去”,而是如何围绕业务页面,把摄像头采集、麦克风采集、本地预览、RTMP 推流、轻量级 RTSP 服务、实时录像、前后台恢复这些能力组织成一条完整链路,并最终落进可维护、可扩展的工程体系中。
围绕这些需求,大牛直播SDK(SmartMediaKit)在鸿蒙 NEXT 推送端并不是简单提供若干底层接口,而是结合上层 ETS 的模块化设计,将页面编排、能力封装、采集控制和桥接调用有机组织起来,形成一套更适合行业项目集成的推送端方案。
本文结合大牛直播SDK当前的鸿蒙 NEXT 上层 ETS 示例,重点介绍如何基于页面层、封装层、采集控制层和桥接层,完成 RTMP 推流、轻量级 RTSP 服务与实时录像 的统一接入与编排。
一、 为什么鸿蒙 NEXT 推送端更需要“工程化组织能力”?
在很多实时音视频项目的初期,团队最常见的目标往往是:
-
能看到预览;
-
能采到声音;
-
能把流推到服务器;
-
能录成本地文件。
但只要进入真实项目阶段,就会发现,真正决定交付质量的并不是某个单点功能,而是整套能力在业务工程里的组织方式。例如:
-
页面层如何统一控制推流、RTSP 服务和录像状态;
-
摄像头和麦克风采集如何独立管理;
-
预览 Surface 与 Camera Session 如何协同;
-
页面切换到后台后,如何恢复采集和发布链路;
-
页面侧如何避免直接面向复杂底层实现;
-
同一套采集输入如何同时服务 RTMP 推流、RTSP 分发与本地录像。
这也是大牛直播SDK在鸿蒙 NEXT 推送端持续打磨的重点方向。相比“只把推流做通”,大牛直播SDK更关注如何通过上层设计,让业务开发者更容易把这些能力集成进实际项目。从当前的 ETS 示例可以看到,大牛直播SDK在鸿蒙 NEXT 推送端已经形成了比较清晰的模块化结构,这种结构对于后续行业场景落地非常关键。
二、 大牛直播SDK在鸿蒙 NEXT 上层 ETS 中的整体结构

结合当前示例工程,大牛直播SDK在鸿蒙 NEXT 推送端的上层组织,可以概括为以下几个核心模块:
-
SmartPublisherPage.ets:页面交互与能力编排
-
SmartPublisherWrapper.ets:发布能力统一封装
-
PublisherCameraHelper.ets:摄像头采集控制
-
PublisherAudioCapturer.ets:麦克风采集控制
-
SmartPublisherBridge.ets / SmartPublisherNative.ets:ArkTS 与 Native 的桥接调用
-
SmartPublisherTypes.ets:参数、枚举与类型定义
这套分层方式的核心价值,在于让不同职责有明确边界:
-
页面层负责业务操作与状态展示;
-
wrapper 层负责推流、RTSP、录像等能力的统一收口;
-
camera / audio 模块分别负责各自的采集控制;
-
bridge / native 层负责对接底层能力;
-
types 层保证上层调用结构清晰、参数统一。
这样的组织方式,既适合技术博客展示,也更贴近真实项目的集成方式。
三、 页面层:大牛直播SDK在鸿蒙 NEXT 上通过 ETS 页面完成能力统一编排
在大牛直播SDK的鸿蒙 NEXT 推送端中,页面层并不是简单承载按钮点击逻辑,而是整个业务侧的能力编排入口。通过 SmartPublisherPage.ets,可以统一完成:
-
UI 展示与用户操作;
-
推流开始/停止控制;
-
轻量级 RTSP 服务启停;
-
实时录像控制;
-
本地预览与状态展示;
-
前后台切换与恢复调度。
对于业务系统来说,这意味着不需要在页面层零散拼接多个底层对象,而是可以围绕“大牛直播SDK提供的发布能力”进行更直接的组织。在鸿蒙 NEXT 页面侧,典型的发布控制逻辑可以像下面这样组织:
@State isPublishing: boolean = false
@State isRecording: boolean = false
@State isRtspRunning: boolean = false
@State previewSurfaceId: string = ''
private publisher: SmartPublisherWrapper = new SmartPublisherWrapper()
private async startPublish(): Promise<void> {
if (this.isPublishing) {
return
}
await this.ensureCameraReady()
await this.ensureAudioReady()
let ret = this.publisher.startPublisher()
if (ret == 0) {
this.isPublishing = true
}
}
private stopPublish(): void {
if (!this.isPublishing) {
return
}
this.publisher.stopPublisher()
this.isPublishing = false
}
从页面侧的接入方式可以看到,大牛直播SDK已经将推流能力放进统一的业务编排体系中。对于集成方来说,页面层关注的是“开始发布”“停止发布”“状态如何展示”,而更底层的采集准备、能力调用和状态收口,则由下层模块承接。这使得鸿蒙 NEXT 推送端不再只是“能跑的 demo”,而更像是一套可持续演进的业务工程基础。
HarmonyOS 鸿蒙NEXT RTMP推流模块延迟测试
四、 能力封装层:大牛直播SDK通过 Wrapper 统一承接 RTMP、RTSP 与录像控制
为了让推流、录像和 RTSP 服务在同一套工程中更容易管理,大牛直播SDK在鸿蒙 NEXT 上层设计中引入了 SmartPublisherWrapper.ets 作为统一能力封装层。这一层的意义非常明确:
-
对页面层屏蔽复杂底层调用;
-
统一发布器生命周期管理;
-
收口参数配置;
-
承接 RTMP 推流控制;
-
承接轻量级 RTSP 服务控制;
-
承接实时录像控制;
-
统一状态回调分发。
在大牛直播SDK的鸿蒙 NEXT 推送端中,上层封装的典型调用方式如下:
export class SmartPublisherWrapper {
private isOpened: boolean = false
openPublisher(): boolean {
if (this.isOpened) {
return true
}
let ret = SmartPublisherBridge.smartPublisherOpen()
this.isOpened = (ret == 0)
return this.isOpened
}
startPublisher(): number {
if (!this.isOpened) {
return -1
}
return SmartPublisherBridge.smartPublisherStart()
}
stopPublisher(): void {
if (!this.isOpened) {
return
}
SmartPublisherBridge.smartPublisherStop()
}
startRecorder(): number {
return SmartPublisherBridge.smartPublisherStartRecorder()
}
stopRecorder(): void {
SmartPublisherBridge.smartPublisherStopRecorder()
}
startRtspService(): number {
return SmartPublisherBridge.smartPublisherStartRtspStream()
}
stopRtspService(): void {
SmartPublisherBridge.smartPublisherStopRtspStream()
}
}
通过这种上层封装方式,大牛直播SDK将 RTMP 推流、轻量级 RTSP 服务与实时录像统一纳入同一个能力入口中。这对于业务工程非常重要,因为行业项目里很少只有“单一路推流”,更多时候需要的是:
-
一路 RTMP 上送到平台;
-
一路设备侧 RTSP 服务供局域网终端拉流;
-
一路本地录像文件用于留档与回放。
有了统一 wrapper 层之后,上层页面就不需要分别面向三套不同逻辑,而可以直接围绕大牛直播SDK提供的统一发布链路进行控制和扩展。
五、 摄像头采集控制:大牛直播SDK将 Camera Session 与预览 Surface 组织为独立能力模块

在鸿蒙 NEXT 推送端中,摄像头相关逻辑从来不是“打开摄像头”这么简单。它往往同时涉及:
-
Camera Session 创建与销毁;
-
预览 Surface 绑定;
-
视频采集输入;
-
前后摄切换;
-
页面生命周期变化;
-
采集链路恢复。
围绕这些问题,大牛直播SDK在鸿蒙 NEXT 上层将摄像头采集独立组织为 PublisherCameraHelper.ets,让摄像头控制能力从页面层中抽离出来。这意味着,在业务工程中,页面层不需要直接面对 Camera Session 的完整管理过程,而是可以通过更稳定的采集控制层完成相关接入。
在大牛直播SDK的鸿蒙 NEXT 推送端中,摄像头控制的上层组织方式可以参考如下:
export class PublisherCameraHelper {
private previewSurfaceId: string = ''
private started: boolean = false
setPreviewSurface(surfaceId: string): void {
this.previewSurfaceId = surfaceId
}
async startCamera(): Promise<boolean> {
if (this.started) {
return true
}
if (!this.previewSurfaceId || this.previewSurfaceId.length == 0) {
return false
}
// 这里省略具体 camera session 创建过程
this.started = true
return true
}
async switchCamera(): Promise<void> {
if (!this.started) {
return
}
await this.stopCamera()
await this.startCamera()
}
async stopCamera(): Promise<void> {
if (!this.started) {
return
}
this.started = false
}
isCameraStarted(): boolean {
return this.started
}
}
从这一层的设计可以看到,大牛直播SDK在鸿蒙 NEXT 推送端中,并不是把摄像头能力当作一个孤立控件来处理,而是作为统一发布链路中的输入源来组织。这样做的好处在于,摄像头采集不仅可以服务本地预览,还能更自然地和 RTMP 推流、RTSP 服务、录像等能力协同工作。
对于行业项目来说,这种设计更适合落地在:无纸化会议终端、巡检记录设备、远程协作场景、工业现场采集终端、应急视频采集设备。
六、 麦克风采集控制:大牛直播SDK在鸿蒙 NEXT 上让音频链路独立可管
在实际项目中,音频质量和稳定性往往直接影响系统可用性。因此,在大牛直播SDK的鸿蒙 NEXT 推送端中,麦克风采集并不是附属于视频采集,而是被设计为独立的控制模块 PublisherAudioCapturer.ets。
通过这一层,上层 ETS 可以更清晰地完成:
-
麦克风启动与停止;
-
音频参数组织;
-
PCM 数据输入;
-
音频中断处理;
-
音频数据送入发布链路。
大牛直播SDK在鸿蒙 NEXT 推送端中的上层音频输入组织方式可以参考如下:
export class PublisherAudioCapturer {
private started: boolean = false
async startCapture(): Promise<boolean> {
if (this.started) {
return true
}
// 这里省略 Audio Capturer 初始化和启动细节
this.started = true
return true
}
stopCapture(): void {
if (!this.started) {
return
}
this.started = false
}
onAudioFrame(pcmData: ArrayBuffer, size: number, timestamp: number): void {
if (!this.started) {
return
}
SmartPublisherBridge.smartPublisherOnPCMData(pcmData, size, timestamp)
}
isStarted(): boolean {
return this.started
}
}
从上层结构可以看出,大牛直播SDK已经将麦克风采集纳入统一发布链路的输入体系中。这意味着在鸿蒙 NEXT 项目中,音频不再只是“附带有声音”,而是和视频采集同样重要的组成部分。这种能力对于远程培训、应急指挥、工业协同等场景尤为关键。
七、 RTMP 推流:大牛直播SDK在鸿蒙 NEXT 上构建稳定的实时上行能力
在很多行业项目中,RTMP 依然是当前最成熟、兼容性最好、最便于接入现有平台的一类实时上行方式。对于大牛直播SDK来说,在鸿蒙 NEXT 上支持 RTMP 推流,不只是能够“推一个地址”,而是通过上层 ETS 的统一编排,让 RTMP 推流成为完整发布链路中的一个稳定输出目标。
在大牛直播SDK的鸿蒙 NEXT 推送端中,页面侧可以非常自然地完成 RTMP 推流接入:
private async onStartPublishClick(): Promise<void> {
if (!this.publisher.openPublisher()) {
return
}
await this.ensureCameraReady()
await this.ensureAudioReady()
this.publisher.setRtmpUrl(this.publishUrl)
let ret = this.publisher.startPublisher()
if (ret == 0) {
this.isPublishing = true
}
}
从上层接入流程可以看到,大牛直播SDK已经将采集准备、发布动作和页面状态管理做了较好的分层处理。这使得业务系统在集成 RTMP 推流能力时,可以更专注于业务本身。
HarmonyOS 鸿蒙NEXT无纸化同屏时延测试
八、 轻量级 RTSP 服务:大牛直播SDK让鸿蒙 NEXT 设备同时具备边缘分发能力
除了 RTMP 实时上行能力,大牛直播SDK在鸿蒙 NEXT 推送端还支持设备侧轻量级 RTSP 服务。很多客户希望设备本地就具备分发能力,例如:
-
局域网终端直接拉流;
-
会议现场本地屏幕预览;
-
边缘侧采集设备直接分发;
-
工业现场画面就近查看;
-
临时组网环境中的本地视频共享。
围绕这些场景,大牛直播SDK已经将轻量级 RTSP 服务能力纳入鸿蒙 NEXT 推送端的上层封装。典型的页面侧接入方式如下:
private startRtspService(): void {
this.publisher.setRtspPort(8554)
this.publisher.setRtspStreamName('live/camera')
let ret = this.publisher.startRtspService()
if (ret == 0) {
this.isRtspRunning = true
}
}
private stopRtspService(): void {
this.publisher.stopRtspService()
this.isRtspRunning = false
}
这意味着鸿蒙 NEXT 设备不仅可以完成 RTMP 实时上行,同时也能够在本地网络环境中承担边缘分发节点角色。
HarmonyOS鸿蒙NEXT下RTMP播放器时延测试
九、 实时录像:大牛直播SDK在鸿蒙 NEXT 上将留档能力纳入统一发布体系
在行业项目中,录像往往不仅是功能补充,而是留痕、追溯的重要基础能力。围绕这一需求,大牛直播SDK在鸿蒙 NEXT 推送端已经支持通过上层 ETS 完成:
-
录像目录设置与文件大小控制;
-
开始与停止录像;
-
推流与录像并行;
-
本地文件留档与后续回放管理。
在页面侧,实时录像能力的接入方式相对直接:
private startRecorder(): void {
this.publisher.setRecorderDirectory(this.recordDir)
this.publisher.setRecorderFileMaxSize(200)
let ret = this.publisher.startRecorder()
if (ret == 0) {
this.isRecording = true
}
}
private stopRecorder(): void {
this.publisher.stopRecorder()
this.isRecording = false
}
这种设计实现了“一次采集,多路输出”的工程目标,非常适合巡检过程留档、工业现场操作记录等需求。
十、 前后台恢复:大牛直播SDK在鸿蒙 NEXT 上重视页面生命周期与采集链路恢复
对于鸿蒙 NEXT 推送端来说,真正影响稳定性的往往是页面生命周期变化带来的链路恢复问题。例如:页面切到后台、返回前台、XComponent Surface 重建、音频中断等。在大牛直播SDK的设计中,这些恢复逻辑通过分工组织。
上层页面可以按如下方式承接恢复逻辑:
onPageShow(): void {
this.restoreAfterForeground()
}
private async restoreAfterForeground(): Promise<void> {
if (this.isPublishing || this.isRecording || this.isRtspRunning) {
await this.ensureCameraReady()
await this.ensureAudioReady()
}
}
这种设计保证了整个发布链路在真实工程环境中的可恢复性与可维护性。
十一、 基于这套 ETS 上层设计,大牛直播SDK适合哪些行业使用场景?
-
无纸化会议:适合会议终端、内容共享终端、会场视频接入设备。
-
移动巡检:适合巡检设备、现场记录终端和移动业务系统集成。
-
应急指挥:适合应急现场、临时组网环境和本地协同场景。
-
远程培训与远程协作:音视频采集、录像和局域网分发能力可以统一管理。
-
工业现场记录:支持采集、本地录像、局域网调看和中心平台上送。
十二、 结语:SmartMediaKit在鸿蒙 NEXT 推送端的价值,在于把能力真正组织成工程
在鸿蒙 NEXT 实时音视频项目中,真正有竞争力的,从来不只是“支持哪些功能”,而是能不能把这些功能在业务工程中真正组织好。从当前的上层 ETS 示例可以看到,大牛直播SDK(SmartMediaKit)在鸿蒙 NEXT 推送端已经形成了比较清晰的模块化能力结构:
-
页面层负责业务编排与状态展示;
-
wrapper 层负责统一发布能力收口;
-
camera / audio 层分别负责采集控制;
-
bridge / native 层负责能力桥接;
-
RTMP 推流、轻量级 RTSP 服务与实时录像在同一条发布链路中统一调度。
这种设计带来的价值,是让鸿蒙 NEXT 终端真正具备了实时上行能力、边缘分发能力、本地留档能力。这不仅是一个功能演示,更是为国产化业务系统构建的一套更适合行业落地的实时音视频能力底座。
📎 CSDN官方博客:音视频牛哥-CSDN博客
更多推荐



所有评论(0)