复杂直播业务做 RN 跨端，我们最后保留了哪些 Native 边界

本文复盘一次直播 App 中 RN 跨端架构的落地过程。

这次实践不是简单讨论「RN、Flutter、KMP 哪个更好」，而是从直播业务的实际约束出发，回答几个更具体的问题：

Android / iOS 双端独立开发在高频业务迭代里会遇到什么瓶颈；
为什么先用鸿蒙新平台验证 RN + Native Hybrid 架构；
RN 适合承接哪些业务能力，哪些能力必须继续留在 Native；
从单端试点到三端复用，中间需要补哪些工程机制；
热更新进入日常迭代后，为什么不能只看发布效率，还要补治理能力。

最终沉淀下来的判断是：

跨端的目标不是把所有代码写成一份，而是在核心体验和稳定性可控的前提下，把适合复用的业务能力从单端实现推进到多端协作。

1. 背景：双端独立开发的成本，会从代码扩散到协作

在移动端业务早期，Android 和 iOS 独立开发是最自然的方式。

每个端有自己的语言、工程结构、组件体系和发布节奏。对相对稳定的业务来说，这种模式可控，也符合平台习惯。

但直播业务有一个特点：变化频繁，而且状态复杂。

一个直播间页面背后可能同时涉及：

播放器和推流链路；
长连、弹幕、礼物、互动玩法；
用户资料、主播资料、关系链；
活动入口、运营配置、Web / RN 容器；
进房、切房、退出、重进等复杂状态流转。

当一类业务长期在 Android、iOS、鸿蒙之间重复实现时，成本就不只是「多写一份代码」。

它会扩散到需求理解、交互一致性、测试回归、问题排查和后续维护。

环节	双端独立开发的典型成本
需求理解	Android / iOS 分别理解细节，边界容易产生差异
技术实现	两端分别设计实现方式，重复建设明显
体验一致性	同一状态在不同端可能表现不同
测试回归	正常路径和异常路径都要覆盖两套实现
线上排查	同一个问题可能要分别定位和修复
后续迭代	需求每改一轮，多端都要同步调整

如果只是偶发需求，这些成本可以靠流程消化。

但如果是互动玩法、活动页面、资料卡、运营配置这类长期高频变化的业务，多端独立实现就会逐渐变成系统性负担。

所以这次跨端实践要解决的第一件事，不是「让 RN 替代 Native」。

而是把适合复用的业务能力从单端分散实现，推进到统一的跨端业务层。

2. 技术选型：不是比较谁最好，而是看谁更适合当前边界

常见跨端路线基本绕不开 KMP、Flutter 和 RN。

这三条路线没有绝对优劣，关键是和业务边界是否匹配。

KMP：更适合共享逻辑，但不直接解决 UI 复用

KMP 的优势在于共享业务逻辑。

如果目标是把一部分核心计算、协议处理、数据转换逻辑抽出来复用，它很合适。

但这次要解决的问题不只是逻辑复用。

我们更希望一批业务页面、互动模块、配置化场景可以在多端之间复用，并且更快进入日常迭代。

如果 UI 和业务页面最终仍然主要靠各端独立实现，KMP 能解决一部分问题，但不是最直接的那部分。

Flutter：渲染一致性强，但和既有直播链路融合成本高

Flutter 的自绘体系带来很强的渲染一致性。

但直播 App 里有大量 Native 能力，例如播放器、推流、长连、系统权限、端上性能优化和已有业务 SDK。

引入新的渲染体系，不只是多一个页面技术栈，还意味着要重新评估它与既有 Native 底座的融合成本。

对于直播业务来说，这个接入风险不低。

RN：更适合承接业务页面和高频迭代模块

RN 最匹配当时需求的地方在于：

可以承接业务页面和交互逻辑复用；
团队已有前端和 RN 相关经验；
能和 Native 保持 Hybrid 分工；
不要求把播放器、推流、长连等核心链路搬进跨端层；
更容易接入现有研发流程和业务迭代节奏。

这次选型的关键判断不是「以后都用 RN」。

而是先确定一条边界：

RN 负责适合复用、适合快速迭代、风险可控的业务能力；Native 继续负责音视频底座、强性能链路、系统能力和关键稳定性兜底。

这个边界比技术选型本身更重要。

3. 为什么先从鸿蒙试点

跨端架构确定后，下一个问题是从哪里开始验证。

直接在 Android / iOS 成熟主端上大规模改造，风险比较高。

这些端已经承载大量历史业务、线上用户、组件依赖和发布节奏。尤其是直播间核心链路，不能为了验证跨端而影响主端稳定性。

鸿蒙提供了一个更合适的验证窗口。

它是新平台，需要重新梳理工程结构、页面容器、模块边界、端能力和发布流程。

既然这些能力本来就要从 0 到 1 建设，就可以顺便把 RN + Native Hybrid 架构的边界跑清楚。

这不是把鸿蒙当实验田。

更准确地说，是利用新平台建设期验证一套未来可迁移的端上架构。

试点阶段有几个关键原则：

原则	说明
Native 仍然是主框架	应用入口、生命周期、权限、系统能力、音视频链路继续由 Native 承接
RN 作为业务容器进入	适合复用的页面和模块放到 RN 层运行
端能力必须契约化	RN 调用 Native 不能临时打洞，要有稳定接口和异常返回
先验证链路，再扩大范围	不只跑 Demo，要进入真实业务模块验证加载、交互、异常和发布流程

鸿蒙试点的价值，是先在新平台上把架构边界跑通，再把验证过的能力反向带回 Android 和 iOS。

4. 架构设计：Hybrid 不是套容器，核心是能力边界

很多 Hybrid 架构一开始看起来都很简单：

Native 启一个容器，RN 页面跑在里面，RN 通过桥接调用 Native 能力。

但直播业务里，真正难的是边界和契约。

可以把整体架构拆成三层。

4.1 Native 基础层

Native 层负责应用最底层、最稳定、最靠近系统的能力：

应用入口和生命周期；
账号态、权限、基础路由；
网络安全、端能力封装；
播放器、推流、长连、音视频底座；
核心业务 SDK；
性能和稳定性兜底。

这些能力不适合因为跨端而被弱化。

直播 App 的核心体验仍然依赖 Native 底座。

4.2 RN 业务层

RN 层负责更适合复用和快速迭代的业务能力：

活动页面；
用户列表；
资料卡；
配置化页面；
部分互动模块；
主播相关轻量业务页面。

这些场景通常具备几个特点：

UI 和交互变化频繁；
多端表现需要尽量一致；
和核心音视频链路耦合较弱；
可以通过明确接口调用端能力；
出问题时可以降级或回退。

4.3 能力桥接层

桥接层是最容易被低估的一层。

它表面上只是让 RN 调用 Native，但实际上决定了跨端架构能不能长期维护。

如果桥接层没有统一契约，很容易变成临时打洞：

text 复制代码

页面 A 需要一个字段 -> 临时加一个方法
页面 B 要兼容另一个端 -> 再加一个分支
页面 C 需要状态同步 -> 继续补特殊逻辑

短期能跑，长期会乱。

更稳的做法是把端能力包装成稳定模块：

text 复制代码

RN 业务页面
  -> 统一能力接口
    -> Android / iOS / 鸿蒙适配层
      -> 各端 Native 实现

能力接口需要提前定义：

参数结构；
返回结构；
错误码；
异常兜底；
版本兼容；
端能力是否支持；
是否允许降级。

直播业务里的状态很多，房间状态、用户状态、主播状态、礼物状态、活动状态、网络状态、播放器状态都会互相影响。

如果 RN 和 Native 之间没有稳定契约，线上问题会很快变成两边互相猜。

所以 Hybrid 能长期跑下去，不是因为 RN 能调 Native，而是因为 RN 和 Native 之间有稳定、可演进的协作边界。

5. 落地路径：从单端验证到三端复用

这次实践不是一步到位，而是分阶段扩大验证范围。

阶段	目标	重点验证内容
阶段一	鸿蒙 RN 架构 0 到 1	RN 容器、页面加载、Native 能力调用、调试和构建流程
阶段二	Android / iOS 接入 RN	三端工程差异、端能力适配、统一接口和降级兜底
阶段三	引入热更新能力	版本管理、发布验证、异常兜底、线上监控
阶段四	进入复杂直播业务	实时状态、业务权限、端能力调用、直播链路联动

阶段一：先跑通 0 到 1

在鸿蒙端先验证 RN 基础能力：

RN 容器启动；
页面加载；
Native 能力调用；
基础网络请求；
状态同步；
调试流程；
构建发布；
异常定位。

这个阶段重点不是覆盖多少业务，而是把基础链路跑稳。

只有基础能力稳定，后面谈三端复用才有意义。

阶段二：成熟主端接入同一套 RN 能力

鸿蒙侧验证过一批业务模块后，再把同一套 RN 能力接入 Android 和 iOS。

这个阶段的难点不只是代码能不能跑起来。

真正要处理的是三端工程差异：

工程依赖不同；
Native 能力实现不同；
系统能力支持程度不同；
版本节奏不同；
线上兜底方式不同。

所以同一份 RN 代码不能默认三端能力完全一致。

有些能力可以抽成统一接口，有些能力需要端侧适配，有些能力暂时不支持就要明确降级。

阶段三：热更新进入日常迭代

热更新对 RN 业务层很有价值。

适合 RN 承接的业务，可以更快触达用户，不必所有变化都等完整客户端版本发布。

但热更新不是单纯的效率按钮。

它会引入新的治理问题：

版本如何管理；
更新如何验证；
异常如何兜底；
线上如何监控；
责任边界如何划分；
出现问题如何回退。

尤其是直播业务，不能只看页面有没有更新成功，还要关注更新后是否影响进房、互动、弱网恢复、端能力调用和异常处理。

所以热更新真正要建设的不是发布能力，而是发布治理能力。

阶段四：用复杂业务验证边界

跨端架构只跑简单页面，说明不了太多问题。

后续 RN 需要进入更多真实业务场景，例如资料卡、用户列表、活动页面、主播相关页面、部分互动模块。

这类场景不是纯展示页面，它们通常包含：

实时状态；
业务权限；
用户交互；
端能力调用；
版本兼容；
和直播间状态的联动。

只有这些业务跑通，团队才算真正验证 RN 在直播业务里的适用边界。

6. RN 和 Native 的边界清单

这次实践里，一个很重要的结论是：

RN 不是万能层。

它提升了业务复用和迭代效率，但不能替代 Native 底座。

可以用下面这张表判断一个模块更适合放在哪里。

类型	更适合 RN	更适合 Native
活动页面	是	否
资料卡、用户列表	是	视端能力依赖而定
配置化页面	是	否
轻量互动模块	是	复杂实时互动需谨慎
播放器、推流	否	是
长连、低延迟链路	否	是
系统权限、端能力	通过接口调用	是
强性能动画	谨慎	是
关键稳定性兜底	否	是

一个简单判断方法是：

text 复制代码

如果这个模块更关注业务展示、状态组织和多端一致性，可以优先考虑 RN。

如果这个模块更关注性能、实时性、系统能力、音视频链路和稳定性兜底，应优先留在 Native。

跨端架构最怕的不是 RN 用得少。

最怕的是为了追求统一，把不适合跨端的重链路也强行塞进去。

短期看起来代码统一了，长期会把问题定位、性能风险和稳定性风险都变复杂。

7. 可复用的方法：先分域，再分层，再治理

从这次实践里，可以抽出一套比较通用的方法。

7.1 先按业务域判断是否适合跨端

不要一上来就按页面拆。

先按业务域看它是否满足几个条件：

多端实现重复度高；
迭代频率高；
UI 和交互一致性要求高；
与核心 Native 链路耦合较弱；
出问题时可以降级或回退。

满足越多，越适合进入 RN 层。

7.2 再按能力分层

一个业务模块进入 RN，不代表全部逻辑都进 RN。

需要继续拆：

业务 UI 放 RN；
端能力放 Native；
状态同步走统一接口；
异常兜底由端侧和 RN 共同约定；
复杂性能链路保留 Native 实现。

这一步决定了后续维护成本。

7.3 把桥接能力契约化

桥接层不能靠口头约定。

至少要明确：

方法名和语义；
入参和出参；
错误码；
是否支持异步；
是否需要权限；
是否支持三端；
不支持时如何降级；
版本差异如何处理。

这部分文档和约束越早建立，后期跨端复杂度越可控。

7.4 热更新必须配治理机制

热更新的价值是缩短部分业务迭代链路。

但它不能绕过质量体系。

至少要配套：

发布前验证；
线上监控；
异常告警；
降级策略；
回退机制；
版本兼容检查。

对直播业务来说，热更新之后不只验证页面打开，还要验证是否影响核心直播状态。

8. 踩坑和风险点

这类架构推进中，比较容易踩到几个坑。

坑 1：把跨端理解成所有业务都用一套代码

这是最常见的误区。

跨端的价值不是覆盖所有模块，而是覆盖适合复用的模块。

如果一个模块强依赖音视频链路、系统能力和强实时状态，强行 RN 化未必划算。

坑 2：桥接层临时堆能力

很多跨端工程前期跑得很快，后期变慢，原因往往不是 RN 本身，而是桥接层缺少治理。

临时接口多了以后，三端能力不一致、字段不一致、异常不一致，问题定位成本会明显上升。

坑 3：热更新只追求快

热更新会让业务迭代变快，但也会让发布责任边界变复杂。

如果没有验证、监控、回退和降级机制，它可能把客户端版本发布里的风险转移到另一套体系里。

坑 4：只关注代码复用，不关注团队能力变化

跨端架构落地后，团队协作方式也会变化。

Android / iOS / 鸿蒙同学需要理解 RN 的页面组织、状态管理和调用链路。

RN 同学也要理解 Native 生命周期、性能边界、端能力差异和线上排查方式。

如果团队能力没有跟上，跨端会变成少数人维护的新黑盒。

9. 阶段结果和后续计划

从目前已确认素材看，这次实践已经完成了几个阶段性动作：

在鸿蒙端完成 RN + Native Hybrid 架构从 0 到 1 的验证；
将验证过的 RN 业务能力逐步反哺 Android / iOS；
让部分适合跨端的业务页面进入三端复用；
将热更新能力纳入日常迭代链路；
让需求评审从默认按端拆分，逐渐变成先判断 RN / Native 边界。

目前暂不写具体效果数字。

原因是部分结果数据仍需确认公开口径。等数据可公开后，可以补到这里，形成更完整的结果闭环。

后续这套架构还需要继续补几类能力：

更清晰的端能力文档；
RN 模块的质量准出标准；
热更新后的监控和回退体系；
三端差异能力的显式管理；
复杂直播业务中的性能和稳定性验证。

10. 总结

直播 App 做跨端，最关键的问题不是「要不要用 RN」。

更关键的是判断：

哪些业务适合跨端；
哪些能力必须留在 Native；
RN 和 Native 之间的契约怎么设计；
热更新如何被治理；
团队如何从单端开发转向多端协作。

这次从鸿蒙试点开始推进 RN + Native Hybrid，不是为了证明 RN 能解决所有问题。

它证明的是另一件事：

当业务边界、端能力边界和发布治理都被提前设计好，跨端才有机会从一次技术尝试，变成多端研发的长期协作机制。

对复杂直播业务来说，好的跨端架构不是把所有东西统一。

而是知道哪些应该统一，哪些必须保留差异。

这也是这次实践里最值得复用的经验。

花椒技术交流群

还在孤军研究 AI 工程化、AI 编程、Agent 落地，没人同行交流、没人拆解实战？

这里汇聚一线技术从业者，专注代码评审、企业内部 AI 助手真实实战落地。

想紧跟 AI 前沿动态、交流工程落地经验、少走踩坑弯路，欢迎直接加入「花椒技术交流群」。

群内专属福利拉满：每日精选研发向 AI 行业日报、文章独家延伸资料、文中未展开的技术细节，全部同步共享。

如果群过期关注公众号 花椒技术 ，私信回复「交流群」获取最新入群二维码。