摘要

HarmonyOS NEXT 的快速发展，正在推动移动应用、行业终端和智能设备的软件生态发生新的变化。对于实时音视频SDK厂商而言，支持鸿蒙NEXT不应只是简单移植一个播放器或推流模块，而应围绕采集、编码、传输、播放、录像、局域网分发和行业平台接入，建立完整、可组合的原生音视频能力。

大牛直播SDK（SmartMediaKit）全面支持 HarmonyOS NEXT，既是对国产化终端生态发展的响应，也是其跨平台实时音视频技术体系的自然延伸。本文将从平台变化、行业需求、技术架构和产品规划等角度，分析为什么 SmartMediaKit 需要在鸿蒙NEXT平台上完成从RTMP推流、RTSP/RTMP低延迟播放，到轻量级RTSP服务、GB28181接入、录像与快照的完整布局。

关键词： HarmonyOS NEXT、鸿蒙NEXT、SmartMediaKit、大牛直播SDK、RTSP播放器、RTMP推流、GB28181、轻量级RTSP服务、超低延迟直播

---

一、HarmonyOS NEXT带来的不只是一个新平台

移动操作系统长期由Android和iOS主导，实时音视频SDK厂商的跨平台支持，也主要围绕Windows、Linux、Android、iOS和macOS展开。

HarmonyOS NEXT的出现，使这一格局开始发生变化。

从华为对HarmonyOS的定位来看，鸿蒙并不只是面向手机的操作系统，而是强调统一操作系统、弹性部署、硬件能力互助和一次开发多端部署，覆盖手机、平板、智慧屏、车机以及不同类型的智能终端。HarmonyOS NEXT进一步延续了这种跨端设计思路，强调一个系统、一致生态和全场景体验。

这意味着，对实时音视频SDK厂商而言，HarmonyOS NEXT并不是简单增加了一个手机操作系统，而是增加了一套可能进入以下设备形态的新平台：

• 移动执法终端；
• 工业巡检终端；
• 车载智能终端；
• 平板调度终端；
• 智慧屏和会议终端；
• 智能安全帽；
• 无人机地面控制设备；
• 机器人控制终端；
• 国产化行业手持设备。

这些设备恰恰是实时音视频技术的重要使用场景。

因此，大牛直播SDK全面支持HarmonyOS NEXT，并不是为了追逐一个短期热点，而是因为HarmonyOS NEXT与SmartMediaKit长期服务的行业方向具有较高重合度。

---

二、为什么不能只把Android版本“移植一下”

从表面上看，HarmonyOS NEXT同样运行在手机和平板等设备上，似乎把现有Android SDK重新编译、封装一下，就可以完成平台支持。

但在实际工程中，事情并没有这么简单。

ArkTS是HarmonyOS应用开发的默认语言，它在TypeScript语法体系基础上进行了扩展，并强化了开发期静态检查和分析。HarmonyOS应用的页面框架、权限机制、生命周期、线程调度、Native接口、图形渲染和应用打包方式，都需要按照鸿蒙原生开发体系重新适配。

对于普通业务应用，平台适配可能主要集中在UI和数据逻辑。

但实时音视频系统还涉及：

• 音视频设备采集；
• 硬件和软件编解码；
• 网络协议栈；
• 音视频时间戳；
• 多线程数据处理；
• Native内存管理；
• Surface渲染；
• 前后台生命周期；
• 网络变化和异常恢复；
• 长时间运行稳定性。

其中任何一个环节处理不当，都可能带来花屏、黑屏、音画不同步、延迟升高、内存增长、线程阻塞或者应用崩溃。

所以，SmartMediaKit对HarmonyOS NEXT的支持，不能停留在“接口能够调用”或者“Demo能够运行”的阶段，而需要建立一套真正符合鸿蒙原生开发体系的音视频架构。

---

三、为什么必须是“全面支持”，而不是只做一个播放器

很多团队在进入新平台时，通常会先选择需求最明显的模块，例如只实现RTSP播放器，或者只实现RTMP推流。

这种方式可以快速完成某个具体项目，但很难形成长期的平台能力。

对于行业客户来说，一个完整的实时音视频应用往往不是单一功能，而是一条完整链路。

例如移动执法场景可能同时需要：

现场音视频采集
        ↓
H.264/H.265编码
        ↓
GB28181接入指挥平台
        ↓
RTMP辅助直播回传
        ↓
局域网RTSP实时分发
        ↓
本地录像与关键画面快照

远程巡检场景可能需要：

摄像头或屏幕采集
        ↓
RTMP远程推送
        ↓
平台侧低延迟播放
        ↓
现场局域网RTSP预览
        ↓
过程录像与异常截图

安防监控客户端则可能需要：

IPC / NVR / 边缘网关
        ↓
RTSP实时拉流
        ↓
低延迟解码与Surface渲染
        ↓
录像、截图和状态回调

如果SDK只提供其中一个模块，业务开发者仍然需要自行寻找并组合其他开源库或第三方SDK，最终形成多套接口、多种线程模型和多个生命周期管理体系。

这会显著增加集成复杂度。

因此，SmartMediaKit在HarmonyOS NEXT上的目标不是提供一个孤立的播放器，而是建立完整的实时音视频能力矩阵。目前方案已经覆盖RTMP推流、轻量级RTSP服务、GB28181设备接入、RTSP/RTMP播放、录像和快照等核心模块。

---

四、SmartMediaKit在鸿蒙NEXT上的能力布局

1. RTMP直播推流

鸿蒙NEXT终端可以采集屏幕、麦克风和系统音，将音视频数据编码后，通过RTMP协议推送到直播服务器。

SmartMediaKit鸿蒙NEXT推流模块支持H.264/H.265编码、软硬编码、Surface模式、系统音与麦克风混音，并可与本地录像和轻量级RTSP服务同时运行。

这类能力可以用于：

• 无纸化会议同屏；
• 移动执法现场回传；
• 工业设备状态上云；
• 远程巡检；
• 电子教室；
• 应急现场视频回传；
• 智能终端屏幕直播。

对于行业应用来说，RTMP的价值并不只是“做直播”，而是以较低的接入成本，把鸿蒙终端画面接入已有流媒体服务器和业务平台。

---

2. RTSP和RTMP低延迟播放

鸿蒙NEXT终端既可能是视频采集端，也可能是实时视频观看端。

在安防监控、机器人视觉、工业巡检和远程控制场景中，终端需要直接拉取IPC、NVR、编码器、无人机或者边缘网关输出的RTSP流。

SmartMediaKit鸿蒙NEXT RTSP播放器支持TCP、UDP及自动切换模式，并提供RTSP鉴权、缓冲控制、播放状态、下载速度、分辨率回调，以及播放端录像和快照能力。RTMP播放器则面向直播观看、远程同屏和业务平台视频预览等场景，支持低延迟播放、快速启动和缓冲控制。

这里的关键并不只是“能播放”，而是需要在首屏速度、播放流畅性、网络抖动容错和端到端延迟之间取得平衡。

对于普通娱乐视频，数秒缓冲可能不会明显影响体验；但对于移动执法、机器人控制、工业设备操作和应急指挥，延迟直接影响操作判断和协作效率。

---

3. 轻量级RTSP服务

轻量级RTSP服务是SmartMediaKit鸿蒙NEXT方案中比较有差异化的一项能力。

传统方案通常需要单独部署RTSP服务器。SmartMediaKit则可以直接在鸿蒙NEXT终端内部启动RTSP Server，将当前采集和编码后的音视频流，在局域网或者专网环境中实时分发。

终端可以直接生成类似以下形式的播放地址：

rtsp://设备IP:端口/流名称

PC客户端、会议大屏、另一台移动终端或者行业控制系统，可以直接连接该地址进行低延迟播放。

更重要的是，RTMP推流、轻量级RTSP服务和本地录像可以复用同一套采集编码链路，避免为了不同输出重复采集、重复编码，从而减少资源消耗。

这种架构适用于：

• 局域网无线投屏；
• 电子教室；
• 无纸化会议；
• 现场巡检；
• 专网视频分发；
• 车载终端；
• 设备调试与监看；
• 移动式视频采集设备。

这也是SmartMediaKit全面支持鸿蒙NEXT的重要原因之一：鸿蒙设备不仅可以作为客户端，也可以成为一个轻量化的视频服务节点。

---

4. GB28181国标设备接入

对于安防、执法、应急、车载、智慧工地和工业巡检等项目，只有RTMP或者RTSP往往还不够。

大量行业平台已经基于GB/T 28181建立视频接入体系。新的鸿蒙NEXT终端如果希望进入这些行业，就必须具备与现有国标平台对接的能力。

SmartMediaKit鸿蒙NEXT GB28181模块采用信令与媒体传输分离的设计：

SIP信令层
├── 设备注册
├── 心跳保活
├── 目录上报
├── 会话协商
└── 平台控制事件

媒体传输层
├── 音视频采集
├── H.264/H.265编码
├── PS封装
└── RTP发送

终端可以主动注册到GB28181平台，保持在线和心跳状态；当平台发起实时点播时，再按需打开采集、编码和媒体传输链路。方案还可支持位置上报、语音广播以及UDP、TCP等媒体传输方式。

这意味着HarmonyOS NEXT设备不再只是一个普通移动应用终端，而可以作为国标视频系统中的前端设备接入现有指挥平台和监管平台。

对于SmartMediaKit来说，支持GB28181也是“全面支持鸿蒙NEXT”和“简单支持移动直播”之间的重要区别。

---

5. 录像与快照

实时视频解决方案不能只解决“看得见”，还要解决“留得住”。

移动执法、工业巡检、远程会诊、安防监控和应急指挥等场景，通常需要对过程进行录像留档，并在关键事件发生时保存快照。

SmartMediaKit鸿蒙NEXT录像能力可以与推流端和播放端组合使用，支持MP4文件保存、录像目录和文件大小配置、音视频录像开关，以及录像开始、文件完成等事件回调；快照模块则可以在采集或者播放过程中保存关键画面。

当推流、播放、录像、截图和协议接入采用同一套SDK内核时，业务侧可以使用统一的生命周期和事件模型，降低多个组件拼接带来的维护成本。

---

五、ArkTS＋NAPI＋Native C/C++：为什么采用分层架构

SmartMediaKit鸿蒙NEXT方案采用：

业务应用层
        ↓
ArkTS接口与业务封装层
        ↓
NAPI桥接层
        ↓
Native C/C++音视频内核
        ↓
系统采集、编解码、网络和渲染能力

在这套架构中：

ArkTS业务层负责页面交互、权限申请、参数配置、状态展示和业务流程编排。

NAPI桥接层负责ArkTS和Native C/C++之间的接口调用、数据转换、对象生命周期以及异步事件回调。

Native SDK内核层负责音视频采集、编码、解码、网络协议、媒体封装、录像、快照和异常恢复等底层能力。

这种设计的意义主要体现在三个方面。

第一，复用成熟的跨平台内核

实时音视频系统最有价值的部分，通常不是UI代码，而是长期积累的协议兼容、时间戳处理、音画同步、缓冲控制、异常恢复和设备适配能力。

通过Native C/C++内核，SmartMediaKit可以在鸿蒙NEXT平台上继续复用已有的流媒体协议和音视频处理能力，同时针对鸿蒙系统接口完成独立适配。

第二，保持鸿蒙原生开发体验

业务开发者仍然通过ArkTS完成页面和业务逻辑，不需要直接管理复杂的C/C++对象、线程和媒体缓冲区。

这使SDK既可以保留Native音视频内核的性能和可控性，又能够融入HarmonyOS原生应用工程。

第三，降低跨平台接口差异

对于同时维护Android、iOS、Windows、Linux、macOS和鸿蒙NEXT版本的行业客户而言，真正重要的不是各平台代码完全相同，而是能力模型尽量一致。

例如不同平台都保持相似的：

• 初始化和反初始化流程；
• Open、Start、Stop、Close生命周期；
• 推流和播放状态回调；
• 录像文件事件；
• 快照接口；
• 音视频参数配置；
• 异常事件处理。

业务团队由此可以建立相对统一的跨平台产品逻辑。

---

六、视频渲染为什么是鸿蒙适配的重点

实时播放器与普通业务组件不同，需要持续将解码后的视频帧输出到显示Surface。

HarmonyOS的XComponent可以为图形渲染和媒体数据写入提供Surface，Native侧可以通过其持有的NativeWindow完成自定义画面渲染，适合较复杂的媒体显示场景。

对于SmartMediaKit播放器而言，渲染适配不仅包括“把画面显示出来”，还需要处理：

• Surface创建与销毁；
• 页面切换；
• 应用前后台切换；
• 横竖屏变化；
• 显示区域尺寸变化；
• 解码线程与渲染线程同步；
• 多播放器实例；
• 硬解码Surface模式；
• 资源释放顺序。

其中，Surface生命周期与播放器生命周期不完全一致。如果页面已经退出，而Native解码线程仍然向旧Surface输出数据，就可能出现崩溃或者黑屏。

因此，鸿蒙NEXT播放器的技术质量，很大程度上取决于Native对象、XComponent Surface、解码器和ArkTS页面生命周期之间能否建立清晰、可靠的状态管理。

这也是为什么成熟的播放器SDK不能只做一层简单接口封装。

---

七、全面支持鸿蒙NEXT，是跨平台战略的自然延伸

SmartMediaKit自2015年开始持续迭代，长期围绕跨平台低延迟实时音视频能力建设，已经覆盖Windows、Linux、Android、iOS、macOS和Unity3D等平台。

在这样的产品体系下，HarmonyOS NEXT不是一个独立、割裂的新产品，而是跨平台能力矩阵中的重要组成部分。

全面支持鸿蒙NEXT，可以让行业客户在进行平台迁移或者新增鸿蒙终端时，继续使用相对一致的音视频链路：

业务能力	Android	iOS	Windows/Linux	HarmonyOS NEXT
RTMP推流	支持	支持	支持	支持
RTSP播放	支持	支持	支持	支持
RTMP播放	支持	支持	支持	支持
本地录像	支持	支持	支持	支持
快照	支持	支持	支持	支持
轻量级RTSP服务	支持	支持	支持	支持
GB28181接入	支持	支持	支持	支持

这里的价值并不是为了追求平台数量，而是降低行业客户进行国产化适配和多终端部署时的技术风险。

假设一个项目同时包含：

• Windows指挥中心；
• Linux边缘网关；
• Android手持终端；
• HarmonyOS NEXT移动终端；
• iOS管理客户端。

如果各平台分别使用不同播放器、推流库、录像组件和GB28181组件，整个项目的测试、维护和问题定位成本会快速上升。

而统一的SDK技术体系，可以在协议行为、接口模型、错误回调和性能调优方面保持较高一致性。

---

八、HarmonyOS NEXT为什么尤其适合行业实时视频场景

HarmonyOS强调多设备协同、统一操作系统和跨端部署，这与实时视频天然具有较强结合空间。

未来的行业视频应用，不一定只是“一个手机App播放一路视频”，而可能形成以下协同关系：

鸿蒙移动终端
├── 采集现场视频
├── 本地录像
├── GB28181上报
└── RTMP远程推送

鸿蒙平板
├── 查看多路RTSP视频
├── 接收现场回传
└── 执行业务调度

智慧屏或会议大屏
├── 接收局域网RTSP流
└── 展示会议或巡检画面

PC指挥平台
├── 汇聚多终端视频
├── 录像归档
└── 远程控制与协同

对于SmartMediaKit而言，音视频能力可以成为这些设备之间的实时数据通道。

协议可能是RTSP、RTMP或者GB28181，设备形态可能是手机、平板、车机或者行业终端，但底层都需要解决采集、编码、传输、播放、录像和状态管理问题。

因此，全面支持鸿蒙NEXT，本质上是在为未来的多终端实时视频协同提前建设基础设施。

---

九、全面支持并不意味着简单复制其他平台功能

不同操作系统在硬件编解码、权限管理、生命周期和图形渲染方面都存在差异。

SmartMediaKit在鸿蒙NEXT上的目标，应该是保持核心能力一致，而不是机械复制其他平台的代码实现。

在后续演进中，需要持续关注：

硬件编解码适配

不同设备对H.264、H.265编码参数、分辨率、帧率和Surface输入模式的支持可能存在差异，需要建立设备能力探测和异常降级机制。

多实例与长时间运行

安防监控和工业应用可能同时播放多路视频，或者持续运行数小时甚至数天，因此需要持续验证CPU、内存、线程、句柄和硬件解码器资源释放。

弱网与网络切换

移动终端可能在Wi-Fi、移动网络和专网之间切换。播放器和推流端需要处理断网、重连、IP变化和服务器异常。

前后台生命周期

音视频采集、播放和网络传输与页面生命周期密切相关，需要明确进入后台、锁屏、页面销毁和应用恢复时的资源处理策略。

权限和数据安全

HarmonyOS NEXT强化了权限最小化、应用行为透明和数据访问控制。实时音视频应用需要对麦克风、媒体文件、网络和相关数据权限进行合理申请和管理。

音视频数据扩展

行业客户可能需要YUV/RGB数据回调、编码前后数据回调、SEI扩展信息、AI分析结果叠加和外部音视频数据输入。这些能力也需要逐步纳入鸿蒙NEXT版本。

因此，“全面支持”不是一次开发完成后就结束，而是建立一条持续维护、持续测试和持续演进的平台产品线。

---

十、SmartMediaKit支持鸿蒙NEXT的真正价值

从产品角度看，全面支持HarmonyOS NEXT至少带来四层价值。

1. 为鸿蒙开发者补齐专业音视频能力

业务开发者不必从零开始研究RTSP、RTMP、RTP、PS封装、GB28181信令、音视频同步和硬件编解码，可以把更多精力放在业务流程和用户体验上。

2. 降低现有行业应用迁移成本

已有Android、Windows或者Linux产品的客户，在增加鸿蒙NEXT终端时，可以延续已有音视频架构和协议体系，而不必重新组合多套开源组件。

3. 打通鸿蒙终端与现有视频系统

通过RTSP、RTMP和GB28181等成熟协议，鸿蒙NEXT终端可以连接已有IPC、NVR、流媒体服务器、国标平台和指挥调度系统。

4. 扩大SmartMediaKit跨平台技术边界

鸿蒙NEXT的加入，使SmartMediaKit进一步覆盖桌面端、移动端、国产化终端、边缘设备和Unity3D应用，为行业客户提供更完整的跨平台实时视频底座。

---

十一、为什么现在必须做，而不是以后再做

新平台发展早期，应用数量可能还不够多，设备覆盖也需要时间。对SDK厂商而言，很容易产生“等客户明确提出需求后再适配”的想法。

但音视频SDK与普通工具类SDK不同。

一个成熟平台版本需要经历：

• 系统接口调研；
• Native架构适配；
• 编解码器验证；
• Surface渲染验证；
• 音频链路验证；
• 网络协议测试；
• 多线程稳定性测试；
• 多机型兼容测试；
• Demo工程和文档建设；
• 客户项目实战验证。

这些工作无法在客户项目临近交付时仓促完成。

如果等到行业客户已经批量采购鸿蒙终端、项目进入实施阶段后才开始适配，SDK质量和项目交付都会面临较大风险。

因此，SmartMediaKit选择提前建立完整的HarmonyOS NEXT产品能力，是一种基础设施式投入。

它不一定立即带来大量项目，但可以在客户真正需要鸿蒙终端时，提供经过验证的技术方案，而不是临时拼接的功能模块。

---

十二、结语

大牛直播SDK全面支持HarmonyOS NEXT，并不是简单增加一个平台图标，也不是把Android版本重新包装一次。

它真正要完成的是：

在HarmonyOS NEXT平台上重新建立一套覆盖采集、编码、传输、播放、录像、局域网分发和行业平台接入的实时音视频能力底座。

围绕这一目标，SmartMediaKit已经逐步形成：

• RTMP直播推流；
• RTSP低延迟播放；
• RTMP低延迟播放；
• 轻量级RTSP服务；
• GB28181国标设备接入；
• 推流端和播放端录像；
• 实时快照；
• ArkTS、NAPI与Native C/C++分层集成。

HarmonyOS NEXT的发展，为国产化智能终端带来了新的技术路径；而实时音视频则是移动执法、工业巡检、应急指挥、智慧会议、机器人、车载终端和安防监控等行业应用的重要基础能力。

对于SmartMediaKit而言，全面支持鸿蒙NEXT不是一次单独的平台移植，而是其跨平台、低延迟、行业化实时视频技术路线的自然延伸。

未来，当越来越多的鸿蒙设备进入行业现场，真正有价值的并不是“能否在鸿蒙上播放一个视频”，而是能否让鸿蒙终端稳定接入现有视频系统，完成采集、传输、观看、录像、取证和协同。

这正是SmartMediaKit布局HarmonyOS NEXT的核心意义。

---

📎 CSDN官方博客：音视频牛哥-CSDN博客