一、从“能投屏”到“可集成、可交付、可国产化”的实时同屏能力
在传统音视频系统中，屏幕共享往往被理解为一个偏应用层的功能：把手机、平板或电脑画面投到大屏、会议终端或远端播放器即可。但在政企、政府办公、国产化无纸化会议、移动执法、应急指挥、智慧教育等场景下，屏幕同屏远不只是“看得见”这么简单。
真正可落地的行业级同屏系统，至少要解决几个关键问题：
- 低延迟：会议批注、远程指挥、移动演示等场景不能接受明显卡顿；
- 稳定性：横竖屏切换、后台运行、弱网波动、分辨率变化都不能轻易中断；
- 国产化适配：终端、系统、协议、服务端、播放器链路要尽量可控；
- 工程可集成：不能只停留在 Demo，要能被业务系统、会议系统、执法系统、指挥系统集成；
- 私有化部署友好：很多政企场景更倾向局域网、专网或自建服务器，而不是完全依赖公有云服务。
随着 HarmonyOS NEXT 生态进入原生应用阶段，鸿蒙在政企、政务、医疗、教育等领域的应用正在加速落地。数字中国建设峰会网站转载的《人民日报》文章提到，鸿蒙正在政务、医疗、教育等领域规模化深入应用，且截至 2025 年 9 月，已有超过 30 款国家级政务应用和近 400 款地方政务民生应用完成鸿蒙原生适配并上架。
这意味着，面向鸿蒙 NEXT 的实时音视频能力，已经不再只是移动端应用开发中的一个功能点，而是国产化终端生态、政企移动办公和行业专网系统中的基础能力之一。
在这个背景下，基于大牛直播SDK（SmartMediaKit）在鸿蒙 NEXT 下实现 RTMP 屏幕推送，就具备了非常明确的工程价值：它不是做一个“演示型录屏”，而是在鸿蒙 NEXT 终端上构建一套可用于国产化无纸化会议、政企办公同屏、远程指挥回传、教育培训演示的低延迟推流内核。
二、为什么鸿蒙 NEXT 下的无纸化同屏需要 RTMP 推流？
很多人一提到屏幕共享，第一反应可能是投屏协议或会议系统内置共享能力。但在政企和行业场景里，RTMP 仍然有非常现实的价值。
RTMP 的优势不在于“最新”，而在于它的链路清晰、部署成熟、服务器生态完善、播放器接入简单，并且非常适合“终端采集 → 服务器汇聚 → 多端播放/分发”的系统结构。
典型链路如下：
鸿蒙 NEXT 终端 ↓ 屏幕采集 / 系统音 / 麦克风大牛直播SDK RTMP 推送模块 ↓自建 RTMP 服务器 / 内网流媒体网关 / 行业平台 ↓Windows 播放器 / 大屏终端 / 录制系统 / 指挥中心 / 会议系统
对于国产化无纸化会议，这条链路非常自然：
- 主席屏、旁听终端、录制服务器或 Windows 播放器实时拉流；
- 必要时可叠加录像、轻量级 RTSP 服务、低延迟播放器等模块。
大牛直播SDK 的 RTMP 推送模块本身就是其核心推送模块，该模块始于 2015 年，覆盖 Windows、Linux、Android、iOS 等平台，支持摄像头、屏幕、麦克风、扬声器以及编码前/编码后数据对接；配合 SmartPlayer 播放器，可实现 100~200ms 量级的端到端低延迟体验。
这也是 SmartMediaKit 适配鸿蒙 NEXT 的意义所在：把已经在 Android、iOS、Windows、Linux 等平台沉淀多年的 RTMP 推流工程能力，迁移到鸿蒙 NEXT 原生环境中，让鸿蒙终端具备可交付、可集成、可私有化部署的低延迟同屏能力。
三、鸿蒙 NEXT RTMP 同屏推流的整体架构设计
结合当前鸿蒙 NEXT 屏幕推送 Demo 的 ETS 代码结构，可以将整个 RTMP 同屏推流模块拆成以下几层：
SmartScreenPublisherPage │ ▼PublisherScreenEngineV2 │ ├── SmartPublisherScreenWrapper │ │ │ ▼ │ SmartPublisherNative │ │ │ ▼ │ libSmartPublisher.so │ └── ArktsScreenCaptureAdapterImpl │ ▼ ScreenCaptureSourceNative │ ▼ OH_AVScreenCapture / 系统屏幕采集能力
这套结构的关键点在于：页面不直接操作底层 SDK，采集不直接关心 RTMP，推送模块不直接绑定 UI 状态。
这种分层非常适合行业 SDK 工程化交付：
SmartScreenPublisherPagePublisherScreenEngineV2：负责业务编排，包括准备采集、启动推流、停止推流、分辨率热切、后台任务；ArktsScreenCaptureAdapterImpl：负责屏幕采集适配，包括 Buffer 模式、Surface 模式、横竖屏热更新；SmartPublisherScreenWrapper：负责 SmartPublisher SDK 的高层封装；SmartPublisherNative：负责 ArkTS 到 native libSmartPublisher.so 的接口映射；ScreenCaptureSourceNative：负责屏幕采集 native source 的创建、启动、停止、resize、回调。
这种分层带来的好处是：后续如果要把 RTMP 推送、轻量级 RTSP 服务、本地录像、系统音采集、麦克风采集、横竖屏切换、后台保活等能力组合起来，不需要把所有逻辑堆在页面里，而是通过 Engine 做统一编排。
四、页面层：面向行业场景的参数控制，而不是简单 Demo
在 SmartScreenPublisherPage.ets 中，页面层已经不是一个简单的“开始/停止”按钮，而是围绕屏幕同屏推流场景做了较完整的配置入口。
例如编码器选择：
private readonly encoderSelectOptions: SelectOption[] = [ new PageSelectOption('软编 H.264'), new PageSelectOption('硬编 H.264'), new PageSelectOption('硬编 H.265'), new PageSelectOption('硬编 H.264（Surface）'), new PageSelectOption('硬编 H.265（Surface）'),]
音频选择：
private readonly audioSelectOptions: SelectOption[] = [ new PageSelectOption('静音'), new PageSelectOption('仅麦克风'), new PageSelectOption('仅系统音'), new PageSelectOption('系统音 + 麦克风'),]
分辨率选择：
private readonly resolutionSelectOptions: SelectOption[] = [ new PageSelectOption('原始分辨率'), new PageSelectOption('标准分辨率'), new PageSelectOption('普通分辨率'),]
这些选项不是为了“功能堆砌”，而是对应行业场景中的真实需求。
比如：
- 无纸化会议中，通常希望采集系统音，用于同步播放会议材料中的音视频内容；
- 远程培训中，可能需要系统音 + 麦克风，既保留课件声音，也保留讲解声音；
- 移动执法或现场巡检中，可能更关注低码率、稳定性、弱网可用性；
- 政企会议中，可能更倾向H.264 硬编码 Surface 模式，减少 CPU 拷贝，提升长时间运行稳定性；
- 内部测试和兼容性验证阶段，则可以保留软编、硬编 Buffer、硬编 Surface 多种路径，方便定位问题。
这也是行业 SDK Demo 和普通演示 Demo 的区别：普通 Demo 是“跑起来”，行业 Demo 是“把后续可能遇到的问题提前留出工程开关”。
五、Engine 层：把采集、推流、录像、RTSP 服务统一编排
PublisherScreenEngineV2 是这套架构里最关键的一层，它把“屏幕采集”和“大牛直播SDK推送”解耦，同时又负责把它们组织成一个稳定的工作流。
启动 RTMP 推流的核心逻辑可以抽象为：
async startPublish(config: ScreenPublishConfig): Promise { const next: ScreenPublishConfig = this.cloneConfig(config) next.enableRecorder = false const preparedOk = await this.prepare(next) if (!preparedOk) { return false } const effective = this.lastConfig ? this.cloneConfig(this.lastConfig) : next effective.enableRecorder = false const ok = this.publisher.startPublish(effective) this.callbacks.onLog?.(`engine: publisher.startPublish ret=${ok}`) this.callbacks.onConfigUpdated?.(this.cloneConfig(effective)) return ok}
这个设计有一个非常重要的思想：推流之前先 prepare 采集管线，而不是每次启动 RTMP 都重新初始化所有资源。
在行业场景中，这一点很关键。因为同一套屏幕采集数据，未来可能同时服务于：
如果每启动一个输出就重开一次采集，会带来权限弹窗、资源重建、编码器重启、画面闪断、音频中断等问题。Engine 层统一管理采集生命周期，可以让 RTMP、录像、RTSP 服务成为同一个 Publisher 实例上的不同输出，而不是互相割裂的多个流程。
六、Buffer 模式与 Surface 模式：鸿蒙 NEXT 下屏幕推送的两条技术路线
在鸿蒙 NEXT 下做屏幕采集推流，核心路径大体可以分为两种：
1. Buffer 模式
Buffer 模式下，屏幕采集模块把视频帧以 RGBA/RGBX 等格式回调到上层，然后由 SmartPublisher SDK 进行编码前数据接入。
在 Engine 中可以看到类似逻辑：
this.capturer.setVideoFrameCallback((frame: ScreenVideoFrame) => { if (!this.isPrepared() || !this.publisher.isMediaInputActive()) { return } if (this.lastConfig !== null && this.useSurfaceInput(this.lastConfig)) { return } if (this.shouldDropFrameDuringTransition(frame)) { return } this.publisher.postScreenVideoRGBA( frame.buffer, frame.rowStride, frame.width, frame.height )})
这条路径的优势是灵活：可以在编码前做图像处理、叠加、裁剪、旋转、缩放、水印或 AI 分析。对于一些需要自定义画面处理的行业场景，Buffer 模式很有价值。
2. Surface 模式
Surface 模式则更偏向性能优先。屏幕采集模块不再把每一帧通过 ArkTS Buffer 回调出来，而是直接写入底层编码器 Surface，减少内存拷贝和格式转换。
当前代码中，Surface 模式的准备逻辑非常清晰：
const surfaceId: string = this.publisher.prepareEncoderInputSurface( next.width, next.height, next.fps )this.capturer.setEncoderSurfaceId(surfaceId)
随后采集侧通过：
ret = session.source.startWithSurface(this.encoderSurfaceId)
把屏幕采集输出直接接到编码器输入 Surface。
这条路径适合长时间、低功耗、低延迟的同屏推流场景，例如：
Surface 模式的工程重点不在“能不能推起来”，而在于横竖屏切换、分辨率变化、编码器 Surface 重建、关键帧请求、权限复用等细节处理。
七、音频采集：系统音、麦克风与混音能力
无纸化会议和远程演示场景里，屏幕画面只是第一步，音频同样重要。
当前设计中支持四种音频模式：
export enum ScreenAudioOutputType { NONE = 0, MIC = 1, SYSTEM = 2, SYSTEM_AND_MIC = 3,}
也就是说，可以根据业务需要选择：
华为官方文档中，AudioCapturer 被定位为用于录制 PCM 音频数据的音频采集器，适合有音频开发经验的开发者实现更灵活的录制功能。
在当前 Engine 中，音频进入 SmartPublisher SDK 前，会先做 10ms 分帧：
this.innerFramer.push(chunk.buffer, ( frame: ArrayBuffer, sr: number, ch: number, pcs: number) => { this.publisher.postSystemAudioPCM(frame, sr, ch, pcs)})
麦克风音频则根据是否混音走不同路径：
if (route === ScreenAudioOutputType.SYSTEM_AND_MIC) { return this.nativePublisher.onMixPCMData( 1, pcm10ms, 0, pcm10ms.byteLength, sampleRate, channels, perChannelSamples ) === DANIULIVE_RETURN_OK}return this.nativePublisher.onPCMData( pcm10ms, pcm10ms.byteLength, sampleRate, channels, perChannelSamples) === DANIULIVE_RETURN_OK
10ms 分帧的好处是：音频进入编码器和推流模块时更加稳定，也更符合实时音频处理的常见节奏。对于低延迟 RTMP 推送来说，音频分帧越规整，后续编码、打包、同步处理越可控。
八、SmartPublisherScreenWrapper：把 RTMP 推流能力封装成可复用模块
SmartPublisherScreenWrapper 是大牛直播SDK 在鸿蒙 NEXT 屏幕推送场景下的核心封装层。它负责把上层传入的 ScreenPublishConfig 转换成底层 SmartPublisher SDK 的一系列参数设置。
例如：
const retSetUrl: number = this.nativePublisher.setURL(resolved.pushUrl)const retRtmpType: number = this.nativePublisher.setRtmpPublishingType(resolved.rtmpPublishingType)const retGop: number = this.nativePublisher.setGopInterval(resolved.gop)const retFps: number = this.nativePublisher.setFps(resolved.fps)
编码器配置则根据软编、硬编 H.264、硬编 H.265、Surface 输入模式进行区分：
if (!useSurface) { switch (config.videoEncoderType) { case PublisherVideoEncoderType.HW_H264: ok = this.nativePublisher.enableVideoHWEncoder( config.videoHwKbps ) === DANIULIVE_RETURN_OK && ok break case PublisherVideoEncoderType.HW_H265: ok = this.nativePublisher.enableVideoHevcHWEncoder( config.videoHwKbps ) === DANIULIVE_RETURN_OK && ok break case PublisherVideoEncoderType.SOFT_H264: default: ok = this.nativePublisher.setSwVideoBitRate( config.videoSwAvgKbps, config.videoSwMaxKbps ) === DANIULIVE_RETURN_OK && ok break } return ok}
Surface 模式则单独处理：
ok = this.nativePublisher.setOHOSEncoderInputMode(1) === DANIULIVE_RETURN_OK && okswitch (config.videoEncoderType) { case PublisherVideoEncoderType.HW_H265: ok = this.nativePublisher.enableVideoHevcHWEncoder( config.videoHwKbps ) === DANIULIVE_RETURN_OK && ok break case PublisherVideoEncoderType.HW_H264: default: ok = this.nativePublisher.enableVideoHWEncoder( config.videoHwKbps ) === DANIULIVE_RETURN_OK && ok break}
这种清晰隔离非常重要。因为在鸿蒙 NEXT 的实际工程中，Buffer 模式和 Surface 模式面对的问题完全不同。如果强行复用同一套逻辑，往往会引入很难排查的编码异常、花屏、绿条、方向错乱或无视频问题。
九、RTMP 推流模块的行业价值：不是替代会议系统，而是成为音视频底座
大牛直播SDK 的价值，并不是要替代所有会议系统、办公系统或指挥系统，而是提供底层音视频能力。
在国产化无纸化同屏场景中，一个完整系统往往包括：
鸿蒙 NEXT 终端 ├── 屏幕采集 ├── 系统音采集 ├── 麦克风采集 ├── RTMP 推流 ├── 本地录像 └── 轻量级 RTSP 服务会议/指挥/办公平台 ├── 流媒体服务器 ├── 播放端 ├── 录制归档 ├── 权限控制 ├── 会议管理 └── 业务系统集成
SmartMediaKit 更适合承担其中的音视频内核角色：
大牛直播SDK 的 RTMP 推送模块支持 SDK 接口化调用、状态 Event 回调、断网自动重连、网络状态监听等工程化需求，并且推送、录像、内置轻量级 RTSP 服务等模块可以解耦组合。
这正是行业客户最需要的能力：不是一个封闭播放器，也不是一个固定 App，而是一套可以被集成进会议系统、政务系统、执法系统、教育系统的实时音视频 SDK。
十、国产化无纸化会议中的典型应用方式
在国产化无纸化会议场景中，鸿蒙 NEXT 终端可以作为会议材料展示端、移动批注端或主持人控制端。通过 SmartMediaKit RTMP 同屏推送模块，可以把终端画面低延迟推送到会议服务器。
典型流程如下：
1. 会议终端打开无纸化会议 App2. 用户选择“开始同屏”3. App 调用鸿蒙屏幕采集能力4. 大牛直播SDK 接收屏幕帧和音频帧5. SDK 编码并推送 RTMP 流6. 会议大屏或 Windows 播放端实时拉流7. 如需留档，可同步启动本地录像或服务端录像
这种方案的特点是：
- 播放端可以是 Windows、Linux、Android、鸿蒙或大屏终端；
- 可根据场景选择 RTMP、RTSP、录像等组合能力；
对于很多政府、央国企、教育、医疗等用户来说，他们真正关心的不是“用了什么热门协议”，而是系统能否稳定运行、能否私有部署、能否和现有业务系统打通、能否长期维护。
RTMP 在这里的价值就在于：成熟、简单、稳定、可控。
十一、为什么这套设计适合鸿蒙 NEXT 生态长期演进？
HarmonyOS NEXT 不是 Android 兼容层上的简单迁移，而是面向原生鸿蒙生态重新构建应用能力。华为在 HDC 2024 中介绍，HarmonyOS NEXT 基于 OpenHarmony 打造，强调全场景、鸿蒙原生智能、原生安全等体验；同时，HarmonyOS NEXT 从操作系统内核、文件系统、编程语言、编译器/运行时、编程框架、设计系统、开发环境等多个层面进行了更新。
对于实时音视频 SDK 来说，这意味着不能简单照搬 Android 的 MediaProjection + MediaCodec 逻辑，而是要重新适配鸿蒙 NEXT 的采集、权限、Surface、音频、后台任务、NAPI/native 接口等机制。
当前这套 SmartMediaKit 鸿蒙 NEXT RTMP 屏幕推送模块，比较有价值的地方在于：
- 保留 Android 端成熟经验例如 SetUrl 与 Start 分离、采集管线和输出模块分离、同一 Publisher 复用、事件回调机制等。
- 适配鸿蒙 NEXT 原生机制通过 ArkTS + NAPI + native so 的方式，把鸿蒙屏幕采集、音频采集、Surface 输入、后台任务等能力接入到 SDK。
- 兼顾 Buffer 和 Surface 两种路线Buffer 路线适合调试、叠加、处理；Surface 路线适合低延迟、低拷贝、长时间推流。
- 重视横竖屏和分辨率热切不以“调用了接口”为准，而以“真实帧稳定”为准，降低播放端异常概率。
- 面向行业组合能力设计RTMP 推流不是孤立功能，后续可以自然扩展到录像、轻量级 RTSP 服务、快照、低延迟播放、服务端转发等模块。
十二、结语：鸿蒙 NEXT 下的 RTMP 同屏推流，是国产化音视频底座的一块关键拼图
国产化无纸化会议、政企移动办公、应急指挥、远程培训、移动执法等场景，对鸿蒙 NEXT 终端提出了越来越明确的音视频能力要求。
这些场景需要的不只是一个“能录屏”的 API，也不是一个只能在 Demo 中跑通的推流按钮，而是一套真正可集成、可维护、可调优、可私有化部署的实时音视频 SDK 能力。
大牛直播SDK（SmartMediaKit）在鸿蒙 NEXT 下的 RTMP 屏幕推送模块，正是围绕这个方向展开：上层通过 ArkTS 进行页面控制和业务编排，中间通过 Engine 管理采集、推流、音频、分辨率热切和后台任务，底层通过 SmartPublisher SDK 完成编码、打包和 RTMP 推送。
对于国产化无纸化同屏来说，它的价值不只是“把屏幕推到服务器”，而是让鸿蒙 NEXT 终端真正具备行业级低延迟同屏能力：
屏幕可采集音频可同步编码可选择分辨率可切换推流可私有化播放可低延迟系统可集成能力可交付
当鸿蒙 NEXT 逐步进入政企、政府、教育、医疗、能源、交通等行业场景时，类似 SmartMediaKit 这样的底层音视频 SDK，将不再只是应用开发中的辅助模块，而会成为国产化实时音视频系统建设中的基础组件。
10个月宝宝每天需要喝多少奶粉？
