从Android 到 Harmony 的直播APP落地实践（一）：预研与架构

当 2023 年行业开始真正押注 HarmonyOS ，我所在的团队也迎来了从 Android 体系向鸿蒙体系迁移的关键节点。不同于社区中大量"简单 Demo 体验"文章，我们面对的是真实大型直播产品：完整直播业务 + 大量互动场景 + H5 & Flutter 混合技术栈 + 音视频 + 信令 + 低延迟交互。

2024 年初，我正式开始接触鸿蒙开发。起步阶段我先用 ArkTS 编写了一些小型 Demo，从语言特性和开发范式开始熟悉体系。与传统 Android Java 或 iOS Objective-C 的命令式 UI 不同，ArkTS 采用声明式 UI 模型，这一点与 Jetpack Compose、SwiftUI、Flutter 的思路高度一致。

实际开发体验上，声明式 UI 更符合现代前端/移动端架构趋势，使状态驱动视图成为自然范式，也为大型互动业务中多状态切换与复杂 UI 响应打下基础。Android 生态同样沿着这条路线演进------Compose 与基于 Jetpack ViewModel 的 MVVM 架构进一步推动了响应式编程的普及。

在此背景下，我开启了鸿蒙系统下实时互动架构的探索之路：包括 UI 渲染、跨端兼容、实时音视频链路、互动容器、资源调度以及性能稳定性治理等内容。

我的鸿蒙探索路线是从最小可运行业务开始，即先搭建一个基础的直播间 Demo，用它来理解和验证鸿蒙的核心能力。具体包括：

Application / Ability / Page 的角色与职责区别
Library / Module 的边界与工程结构组织方式
页面跳转与数据传递机制（导航、路由、参数）
屏幕方向与旋转处理
XComponent 作为视频渲染容器的使用方式=
状态管理：@State、@Prop、@Provide、@Consume 的作用与适用场景
组件通信与跨页面状态维护
UI 渲染与生命周期理解

通过这个过程，我从 UI、路由、状态、渲染到组件生命周期逐步形成对鸿蒙开发模型的完整认知。我从一个最小直播间 Demo 入手，逐步掌握鸿蒙的页面模型、工程结构、渲染容器、路由机制与状态管理体系，为后续实时互动架构打下基础。

我认为 ArkTS 的学习应该从"运行模型 + 状态体系"入手，而不是直接冲业务。只有理解 Page/Ability、组件状态流、XComponent 与原生能力交互模式，才能真正做复杂实时互动场景

在完成基础 Demo 后，我进入第二阶段：关键链路打通与卡点验证。

这一步的目标，是确保鸿蒙端能够真正承载实时互动的核心音视频链路，而不是停留在 UI 层尝试。

卡点一：直播能力的调通

首先，我选用 XComponent 作为视频渲染容器，并通过 ArkTS 调用团队自研的 RTC 音视频能力（C++/SO）。

流媒体团队在服务器侧搭建了测试环境，为我提供真实的测试流地址。

接下来我重点验证几个关键能力：

ArkTS ↔ Native 能力打通

通过 Native 接口调用模式（类似 Android JNI），完成解码、渲染、状态回调等链路设计
RTC 推拉流能力验证

确保画面能正常渲染、音视频链路稳定可用
横竖屏切换与 UI 自适应
后台/前台切换
生命周期管理

这一阶段的目标很明确：先证明它能跑通、跑稳，再考虑架构抽象与工程体系化 。在实时互动业务里，UI Demo 不算真正的适配，只有把音视频链路、Native 能力、生命周期、系统资源调度全部跑通，才算真正落地第一步。

这一阶段我输出了：

Native 调用层封装（ArkTS ↔ C++）
XComponent 交互与生命周期管理
RTC 播放逻辑与状态处理
横竖屏方案
后台保活与恢复流程

这些能力将会反复复用在后续正式业务工程中。

卡点二：矩阵APP下的架构选择

教育业务并不是单一 App，而是一个App 矩阵：面向不同产品线、业务形态、用户群，每个 App 的功能组合和优先级都不同。

做鸿蒙适配时，我们面临一个关键问题：是为每个 App 单独适配，还是建立一套可复用的鸿蒙架构体系？

如果走"各 App 各自改造"路线：每个 App 都要重复适配 UI、容器、直播、互动、稳定性；代码分叉，后期维护成本成倍增长；一次更新要全线补丁，无法快速演进。

这条路径短期看最快，长期一定失控。我们最终选择了第二条路：统一底座 + 业务插件化 + 变体能力支持

我们的架构策略

建立统一鸿蒙工程结构
抽象"直播、互动、账号、路由、播放器"通用能力为 SDK
将差异业务以 能力模块 / Feature Package 形式按需接入
让每个 App 只关注自己的场景差异，而不是反复重复基础工作

我们不是适配一个 App，而是构建一套支持 App 矩阵的鸿蒙能力层。

这样做带来的好处非常显著：

新 App 上线鸿蒙时 零心智重建
公共能力升级 → 全矩阵同步提升
业务差异通过模块化组合表达，不破坏底层稳定性
技术栈演进有"骨架"，不是碎片化堆积

挑战与价值

坦白说，建立体系比"把一个 App 跑起来"难得多：要提前设计边界与能力抽象；要对未来业务方向有判断；要投入时间构建通用层而不是只冲功能

但因为我们坚持这条路线，后来多 App 并行鸿蒙落地时，我们没有被架构拖住，而是以体系化能力持续加速。

最终效果是：鸿蒙不仅跑起来，而且跑得快、跑得稳、跑得一致

卡点三：直播间架构的搭建

我们 App 的核心能力是直播间。相比普通业务页面，直播间是一个强实时、高耦合、强互动的复杂系统：

布局形态复杂（播放器 + 题目容器 + 工具栏 + 聊天 + 礼物...）
信令、互动题、音视频链路高度联动
时序要求严格（指令、渲染、播放的毫秒级同步）
动态扩展能力要求高（组件不停增删改）

在行业里，Android 和 iOS 都已经形成各自成熟的一套直播间架构模式，包括：

布局系统的组织方式
业务模块拆分策略
信令、互动题、播放器的解耦逻辑
事件与时序同步机制

那么问题来了：

鸿蒙的直播间架构该跟 Android 还是 iOS？还是重造一套？

鸿蒙和其他两端最大的差异是：UI 框架是声明式的（ArkTS） ，这意味着：

不能完全照搬 Android 的 View + MVVM
也不能直接套用 iOS 的 UIKit 体系
但必须复用已有架构中成熟的业务解耦、时序处理、模块协同策略

因此，我们采取了：

UI 层：基于鸿蒙声明式 UI 特性，设计全新直播间 UI 架构

逻辑层：复用 Android & iOS 成熟的模块解耦、事件流机制

跨端层：信令 / 互动容器 / 播放器布局组件都保持统一抽象

开发者友好：保持架构风格靠近 Android（因为团队 Android 主导），但也兼容后续 iOS 工程师接入

最终，我们既保证了：

原生体验（性能 & 响应）
跨端一致性
可扩展、可维护

又规避了两端直接复制粘贴的"架构移植陷阱"。很多人做 Harmony 是"把 Android 搬过去"。我们没有选择移植，而是选择重构 + 跨端统一。这件事难，但价值巨大。

卡点四：团队鸿蒙推广与工程体系建设

跨端技术不是一个人能完成的。即使我个人已经掌握了鸿蒙开发，如果团队跟不上，这件事也无法落地。因此我把"团队鸿蒙推广"当成了一个独立工程来做：

1）降低上手门槛：模板工程与最佳实践输出

为了避免团队成员"不会写、不敢写、写不对"，我提前构建了：

直播间框架模板
常用组件封装（播放器、互动容器、路由、事件总线等）
业务代码组织规范
模块解耦和扩展模式
端内模块联动示例（信令 → UI → 互动题 → 播放器）

一句话：先给路，再给车，再给 demo，让工程师"跟着跑"就能写出合规的鸿蒙代码。

2）工程基建补齐

为了提升效率，我对鸿蒙工程做了底层加强，包括：

JSON → Bean 转换工具
本地资源加载抽象（Text → String、图片预处理）
通用工具库迁移与封装
UI组件库和样式规范统一
调试、日志、埋点方案

把鸿蒙开发从"手搓模式"升级到体系化工程模式。

卡点五：统一抽象与统一路由体系：解决多端心智差异的关键工程"

在跨端项目中，技术难点常常不是"写不出来"，而是不同平台的开发者思维不一致、调用方式不统一、接口语义不一致。

比如：

Android：Activity / Fragment + Intent + Router
iOS：Controller + Navigator
Harmony：Stage/Ability + NavigationStack + ArkUI Component

如果不统一思路，每个端都会出现自己的"叫法"和自己的打开方式，长期会形成多套心智体系 → 维护崩溃。

所以我做的核心事情是：

建立统一抽象（能力一致） + 统一路由体系（调用一致）

1) 为什么要统一抽象？

为了保证：调用方式一致；代码组织一致；功能定义一致；平台差异被屏蔽到内部

业务逻辑写一套思路，不用换脑子。

举例，打开互动题面板：

csharp 复制代码

// Android
Router.open("live/questionPanel", params)

csharp 复制代码

// iOS
Router.open("live/questionPanel", params)

csharp 复制代码

// Harmony(ArkTS)
Router.open("live/questionPanel", params)

开发者不需要关心：

Ability 还是 Activity？
push 还是 present？
route stack 结构差异？

上层统一，底层适配差异。

2) 抽象层设计：能力中心，而不是平台中心

我把端能力划分为统一能力模块，比如：

能力域	说明
Navigation	打开页面 / 关闭页面 / 弹窗
Media	播放器控制、状态监听
WebBridge	WebView → Native
Interaction	互动题模块能力
User	用户信息、鉴权、埋点

统一 API：

scss 复制代码

interface Navigation {
  open(route: string, params?: object)
  close()
  popToRoot()
}

底层按平台适配，各平台实现自己的adapter：

javascript 复制代码

// harmony-navigation.ts
open(route, params) {
  // Ability → navigation.push
}

// android-navigation.kt
open(route, params) {
  // startActivity or Fragment navigate
}

// ios-navigation.swift
open(route, params) {
  // UINavigationController push
}

3) 路由命名与分类体系

我制定了统一的路由规范：

category	route example	说明
live-room	live/main	直播主场景
live-interaction	live/questionPanel	互动题、工具条
common	common/web	H5页、弹窗

统一命名 → 统一心智 → 统一排查

4) 一致性带来的收益

收益	说明
统一心智	Android/iOS/Harmony 写法一致
降低学习成本	iOS 同学写 ArkTS 不懵
可复用设计模式	统一架构 / 事件流 / 埋点体系
工程规范稳定	不会出现三端三种叫法、三种逻辑
长线可维护	后面增加端（如 PC / 小程序）也能复用

架构的价值不是封装 API，而是统一团队思维模型。统一抽象 + 统一路由，让跨端不是「每端自己野生生长」，而是「一套体系，多端生长」。

这也是为什么我们最终能把 Harmony 接入推进下去：不仅仅是写通了，更让团队能写、敢写、写得对。

本篇为鸿蒙适配的第一篇，后面的篇章中我除了会细化上面的卡点介绍，还会介绍一些其它有趣的事