写在前面：本文由一份内部技术调研报告脱敏改写，当时的论证前提是"把热更新与灰度下发作为首要目标"。就个人观点补充一句：如果业务诉求主要是内容、活动、开关这类配置动态化，用服务端下发 + 配置化 UI（甚至沿用现有 H5 / 小程序容器）就能解决，成本远低于引入 RN；RN 真正的价值只在代码级缺陷的快速修复与新功能 / 新页面的小流量灰度这两类场景。此外 RN 的完整落地成本并不低（OTA 通道、组件库、原生桥接、版本升级回归、监控），页面体验在复杂动画与长列表场景仍需额外优化，并不天然等于原生。是否值得引入，取决于你真正的诉求是什么——请先确认这一点，再参考本文。
本文从一个真实的三端（iOS / Android / HarmonyOS NEXT）业务需求出发，系统评估引入 React Native 的可行性、热更新（OTA）的落地方式与安全边界，以及它对测试、发布流程与长期维护的影响。文中涉及的人天与费用均为公开报价或通用参考估算，不代表任何具体团队的实际情况，请以自身评估结果为准。
1. 背景与结论
1.1 现状与诉求
- iOS、Android 两端均为原生开发，Kotlin Multiplatform（KMP） 共享部分逻辑层代码；HarmonyOS NEXT 为明确的第三端。
- KMP 解决"逻辑层复用"，不解决动态化——产物为原生二进制，改动仍需走商店审核。
- 当前第一诉求是线上热更新：线上问题与运营内容不依赖发版节奏即可生效。
1.2 结论
采用 React Native（RN），以"原生主壳 + 统一 RN 容器"的混合架构接入，现有原生工程不推翻、主链路不动。
决定性的只有一条：RN 是当前唯一能同时覆盖 iOS、Android、HarmonyOS NEXT 三端、且具备合规热更新能力的方案。 业务代码以 JS Bundle 形式运行在内置 JS 引擎中，可不重新提交商店审核即更新；Flutter（AOT 产物）与 KMP（二进制产物）都不具备此能力，在"热更新"维度上为 0 分。
热更新指两类能力：① 线上问题快速修复；② 新功能 / 新活动的小流量灰度发布（先放开 1%–5% 用户，看崩溃率与业务数据无异常再全量，异常即回滚）。后者是核心用途。
OTA 通道有"自建"与"采购三方服务"两条路线，取舍不同：
| 路线 | 特点 | 代价 |
|---|---|---|
| 自建 | 主权完整：灰度、密钥、版本矩阵全自主；业务代码不出自有环境 | 一次性约 60–100 人天 + 每年 16–46 人天 升级回归 |
| 采购三方（优先评估腾讯 Shiply） | 开箱即用，接入约 2–5 人天；Shiply / Pushy 均支持三端 | 通道在厂商侧、不支持自定义端到端加密、受供应商生命周期约束；Shiply 需商务开通 |
两条路线可平滑迁移，不被厂商锁死。Shiply 完整方案见第 3.4 节。
关于加密：托管方案（Shiply / Pushy）均不支持自定义端到端加密，但这并非安全缺陷，而是行业通行做法——CodePush、Expo、美团 MRN、携程 CRN 等大厂 OTA 均不做整包端到端加密，签名校验已挡住最致命的"包被替换"威胁，多数业务无需做。若确有强监管硬要求，只有完全自建能确定性满足。
1.3 RN 的缺点（必须一并接受）
| 缺点 | 实际影响 | 我们的应对 |
|---|---|---|
| 性能弱于原生，冷启动与重负载渲染差距可感知 | 二级页面可接受；主链路不可用 RN | 首页/选座/支付保持原生（第 5 章）；具体差值以 PoC 实测为准，不引用第三方估值 |
| RN 运行时升级后，需要对全部 RN 页面做回归（升级动作本身不难，难的是回归范围） | 每次升级带来一轮全量级测试，测试成本周期性上升；三端版本不同步还会放大 | 见第 6 章：升级节奏、回归策略与降本纪律 |
| 鸿蒙侧版本适配滞后上游，三方库存在缺口 | 可能推高工作量 | 落地前做依赖清单盘点 |
| 引入新技术栈与规范，短期效率下降 | 前 1–2 个模块会变慢 | 先做低频低风险模块试点 |
上述缺点客观存在，但在"热更新"这一第一诉求面前是可接受的代价——因为另两个方案在该诉求上是 0 分。
1.4 上线后用什么指标证明做成了（落地与验收指标）
| 指标 | 含义 | 建议口径 |
|---|---|---|
| 双端代码复用率 | RN 业务代码在 iOS/Android 的复用程度 | L2 层 ≥ 70%（首个试点模块实测） |
| 需求交付周期 | 从需求到上线的平均周期 | 较引入前下降（基准值在试点阶段建立） |
| 热更覆盖率 | 线上 JS 层问题中可通过热更修复的比例 | 以试点模块统计 |
| 崩溃率 / ANR 率 | RN 页面 vs 原生同类页面 | 不高于原生同类 |
| Bundle 体积 | 单 Bundle 与增量包大小 | 设预算红线，超限阻断 |
| 首屏耗时 / 帧率 | RN 页面体验 | 不低于 5.2 约定的体验达标线 |
以上指标的基准值在试点阶段用自有页面实测确定，不引用第三方估值。
1.5 为什么最终是 RN（与备选方案对比）
| 方案 | 能否合规热更 | 三端（含鸿蒙） | 主要代价 |
|---|---|---|---|
| React Native | ✅ JS Bundle 解释执行 | ✅ iOS / Android / 鸿蒙（RNOH） | 升级需全量回归；性能弱于原生；新增技术栈 |
| Flutter | 🔶 官方不支持；第三方 Conch 可补丁 Dart 层 | 🔶 鸿蒙仅特定 Flutter 版本支持 | 官方无热更；Dart 人才稀缺；转 Flutter 成本高 |
| KMP / Compose | ❌ 产物为二进制 | 🔶 鸿蒙侧推进中 | 只解决逻辑层复用，不解决 UI 与动态化 |
| 服务端下发 + 配置化 UI | ✅ 内容 / 配置可动态 | 与端无关 | 改不了代码与新交互，做不了新页面 |
| 小程序 / Hybrid 离线包 | ✅ 容器内可动态 | ✅ | WebView 级体验，与主 App 易割裂 |
两点判断：
- 若诉求只是"内容 / 配置动态化"，优先用服务端下发 + 配置化 UI，成本远低于 RN。
- 若需要"代码级缺陷快速修复"或"新功能小流量灰度"且主链路保持原生，RN 是唯一同时满足三端覆盖 + 合规热更 + 低侵入的方案。
RN vs Flutter 动态化（一句话）：RN 运行时本就为动态执行 JS 设计，下发整包 Bundle 即可热更；Flutter 官方不支持热更，第三方（如腾讯 Conch）需改造 Dart 编译器打差分补丁，且鸿蒙仅特定 Flutter 版本支持、依赖第三方、不能自托管。当前技术栈是原生 + KMP，转 Flutter 成本远高于 RN 容器逐页替换，故不选。
2. RN 技术底座与 2026 年版本现状
2.1 它是怎么跑起来的
RN 的新架构由 JSI（JS 与 C++ 直接调用层）、Fabric（新渲染器）、TurboModules（原生能力模块，按需懒加载，TS 契约经 Codegen 生成三端绑定）组成。其中与本项目关系最直接的是 JS 引擎：
| 组成 | 作用 |
|---|---|
| Hermes（V1） | Meta 自研移动端 JS 引擎，构建期把 JS 预编译为字节码，运行时跳过解析；它同时是第 3.3 节安全体系的第一道门 |
与现有工程的关系：RN 不是"另一套 App"，而是可嵌入的视图容器。原生侧提供页面容器（iOS UIViewController / Android Activity·Fragment / 鸿蒙 RNApp），容器内加载 RN 页面；容器之外的启动、首页、支付、选座保持原生，二者通过 TurboModules 互相调用。
2.2 版本现状与升级策略（直接影响项目排期）
RN 官方策略（reactnative.dev/releases）：每 2 个月一个次版本，只维护最近 3 个次版本系列。2026-09 现状：
| 版本 | 发布日期 | 官方支持状态 |
|---|---|---|
| 0.88.x | 2026-10-12（计划） | Future |
| 0.87.x | 2026-08-10 | Active |
| 0.86.x | 2026-06-09 | Active |
| 0.85.x | 2026-04-06 | End of Cycle |
| 0.84.x | 2026-02-09 | Unsupported |
| 0.83.x 及更早 | 2025-12 及更早 | Unsupported |
鸿蒙侧 RNOH 版本线（并非单一"主线 0.84"，而是多线并行 + 季度跟版）：npm latest tag 现指向 0.84.4（2026-10 实测；0.84.1 Release 于 2026-09-15 发布，对齐 RN 0.84.1 + React 19.2.3）；各 0.7x 线以独立 tag 维护（如 0.72-stable=0.72.140、0.82-stable=0.82.30，后者即 2026-05 发布的新架构 + Hermes V1 组合）；0.86 也已合入主干（2026-08-31）。在 RN 官方（Meta）口径下，0.82 / 0.84 已 Unsupported（Active 仅 0.86 / 0.87），安全补丁需自行处理——不过 RNOH 在 2026 路线图已明确按季度跟进 0.82 / 0.84 / 0.86 / 0.88 四个版本，呈"常态化、连续跟版"态势，早期那种"适配慢一截"的滞后风险已明显缓解。
为什么鸿蒙侧会"卡在新旧更替"：RN 官方路线图中没有鸿蒙（只维护 iOS / Android），HarmonyOS NEXT 又去掉了 AOSP 兼容层，RN 要在鸿蒙上跑是一次平台移植（渲染层映射 ArkUI、原生模块用 ArkTS / C-API 重写、构建系统换 Hvigor），由社区（RNOH，华为与 Software Mansion 等合作）共建维护，跟版速度必然滞后于 RN 官方。iOS / Android 无此问题。
为什么"三端 RN 版本不一致"会实实在在产生成本：
| 影响 | 具体表现 |
|---|---|
| 同一份业务代码跑在两套运行时上 | 二者在渲染、手势、动画、API 行为上有差异，可能出现"两端正常、鸿蒙异常"，排查时无法直接归因 |
| 三方库适配状态不同 | 一个库在 iOS/Android 是最新版，鸿蒙可能只有旧版或需 rntpc_* 适配版本，业务代码要写平台分支 |
| 缺陷要分头处理 | 同一 Bug 可能只在一端出现，补丁分别验证；热更也要按端分别出包与灰度 |
| 版本矩阵与灰度更复杂 | 下发服务要维护多套"App 版本 × Bundle 版本 × RN 版本 × 端"的兼容关系，错配风险成倍上升 |
| 升级节奏不同步 | 等于长期维护两套状态，每次升级都要评估两次 |
建议：
- 立项前必须实测确认，不能只看文档：用
npm view @react-native-oh/react-native-harmony versions与peerDependencies核对当前可用的稳定组合。 - 三端统一，且版本上限由鸿蒙侧决定——行业通行做法是 iOS / Android 迁就鸿蒙（携程适配鸿蒙时即把 RN 从 0.70.1 升到 0.72.5 对齐）。
- 目标统一到 0.84.4（当前 npm latest，0.84.1 Release 于 2026-09-15 发布），并持续跟进 0.86；选型时以立项时间点的实测稳定组合为准。
- 不要拆成两版本并行：表面是"让 iOS/Android 用上最新版"，实际是长期维护两套运行时，上表五项成本同时发生，总成本高于"三端统一停在稍旧版本"。
3. 核心：热更新（OTA）
3.1 能带来什么（保守表述）
热更新不是只有"修 Bug"——它的两大能力是"快速修复"与"灰度发布"，后者（最后一行）是本次确定的核心用途：
| 场景 | 现状 | 引入 OTA 后 |
|---|---|---|
| 线上 RN 页面的逻辑缺陷 | 随版本发布，按天/周计 | 修复后即可下发，分钟～小时级 |
| 运营内容（活动、文案、权益）临时变更 | 无法及时处理 | 可定向下发、可回滚 |
| 双端（三端）表现不一致 | 分别排期 | 一次下发同步生效 |
| 新功能 / 新活动的小流量灰度验证 | 只能等发版全量上，风险集中 | 按比例放量、看数据再全量，出问题随时回滚（本次确定的核心用途） |
边界：热更新只能更新 JS 层。原生能力的新增与修改（新 SDK、新权限、原生 UI）仍必须走应用商店，这是硬性约束。
3.2 合规红线（写入开发规范）
| 平台 | 规则要点 |
|---|---|
| Apple | 审核指南 2.5.2 禁止下载会引入或改变 App 功能的代码；但开发者协议豁免条款（旧 §3.3.2，2025 年改版后为 §3.3.1(B)）允许**通过系统内置 WebKit / JavaScriptCore 运行的解释型代码（含 JavaScript）**下发，前提是：①不改变 App 主要用途；②不为其他代码/App 创建商店；③不绕过签名、沙盒等安全机制。2017 年 3 月苹果曾就 JSPatch 类方案群发警告要求移除——被禁原因是它把 Objective-C runtime 能力几乎无保留暴露给 JS，具备"审核后任意改变 App 行为"的能力，而非因为用了 JS |
| Android（国内商店） | 安卓包只在国内商店上架。国内主流商店未见针对 JS Bundle 热更新的明确禁止性条款，但需遵守：①不得借热更新绕过个人信息保护、权限与广告合规（工信部监管范围）；②不得下发或加载原生可执行代码（dex / JAR / .so）。建议按与 iOS 相同的红线执行，避免两端标准不一 |
由此推出的红线：只下发 JS 层；不下发任何原生二进制；不用热更上线审核时未出现的功能或权限；不绕过支付与鉴权；不得通过热更新扩大个人信息收集范围。
隐私合规边界（热更新的另一条红线）
隐私政策与商店隐私清单本质是一份承诺。热更新若改变了这个承诺而未更新、未重新取得同意，即违反《个人信息保护法》的告知—同意与最小必要原则。
- 热更新可以做：修 Bug、优化性能、UI / 文案 / 布局调整；不涉及新数据采集的业务逻辑调整。
- 热更新禁止做（涉及即改走版本发布）：新增隐私政策未声明的个人信息采集；扩大已声明数据的使用目的（如"推荐"改"广告投放"）；新增敏感权限或第三方 SDK；新增数据出境。
- 发布前加一道隐私检查：本次 patch 是否涉及数据采集 / 权限 / SDK / 使用目的变更——涉及则禁止走热更，改走版本发布（更新隐私政策 + 重新取得同意 + 更新商店隐私清单）。
- 建议在隐私政策中主动声明："我们会通过热更新修复问题、优化体验，不会因此扩大对您个人信息的收集范围。"
3.3 安全：加密与验签
- 走自建 OTA：必须自建加密验签体系（AES-256-GCM 加密 + 签名验来源）。
- 走采购托管（Shiply / Pushy）：默认接受厂商内置的 HTTPS + 完整性校验，不自定义端到端加密。需注意：托管不做自定义端到端加密是行业通行做法而非安全缺陷——CodePush、Expo、以及美团 MRN、携程 CRN 等大厂自建 OTA 公开的都是「HTTPS + 签名校验 + CDN 访问控制」模型，无整包端到端加密；签名校验已覆盖最致命的"包被替换"威胁，端到端加密额外防的"代码逆向""代码存第三方"对多数业务并非必需。
3.4 OTA 落地方式：自建 vs 采购
国内真正提供 RN JS Bundle 热更新的有两家
| 服务 | 提供方 | 平台覆盖 | 开放方式 | 核心能力 |
|---|---|---|---|---|
| 腾讯 Shiply（RN 热更新） | 腾讯端服务（TDS） | iOS / Android / 鸿蒙三端（鸿蒙 v0.4.0 / 2025-12-22 适配） | 限制开放，需商务 | 差分、灰度、数据观测、停止任务即回滚 |
| Pushy | React Native 中文网 | iOS / Android / 鸿蒙三端 | 公开自助（¥66/月起） | 增量差分、灰度、崩溃回滚、JS 报错还原；客户端 / CLI 开源 |
另两家经核实不属 RN 热更新，仅列作对照：阿里云 EMAS（Sophix） 仅 Android 原生热修复、不支持新增功能，且 2026-10-01 起停止新接入、2027-09-30 停服；字节火山引擎无公开热更新 SaaS 成品。
若走采购而非自建，优先评估腾讯 Shiply。代价是"限制开放"（需商务对接）、只提供托管形态（无私有化 / 自建）、无法做自定义端到端加密（见 3.3）；且 Shiply 与 Bugly 监控是两个独立产品、独立计费（见第 9 章）。Pushy 默认即 SaaS，不需要自建机房——注册付 ¥66/月起、bundle 上传到 Pushy 服务器、客户端从其 CDN 拉取，开箱即用；所谓"基于开源自建"是把开源服务端部署到自有机器，是可选退路而非前提。
成本对比
| 路线 | 一次性投入 | 长期费用 | 周期 |
|---|---|---|---|
| B 完全自建（从零） | 60–100 人天 | CDN 与存储按量 + 0.2–0.3 人力/年运维 | 6–10 周 |
| C 私有化部署（沿用其 SDK） | 15–30 人天 | CDN 按量 + 0.1–0.2 人力/年运维 | 3–5 周 |
| A 托管（Pushy SaaS）——过渡备选 | 三端接入 2–5 人天 | ¥66/月起（≈ ¥792/年）；专业版 ¥7200/年；VIP1 ¥30000/年、VIP2 ¥60000/年、VIP3 ¥120000/年 | 1–2 周 |
| A 托管（腾讯 Shiply） | 三端接入人天需咨询 | 按"移动端热修复"刊例价（5 万 MAU=7,600 / 10 万=14,600 / 20 万=28,000 元/年；开通需商务、每月赠 1 万 MAU 免费额；不含监控） | 1–2 周 |
Shiply 报价说明：RN 热更新归属"移动端热修复"类目，计费页已公布公开刊例价（5 万 MAU=7,600、10 万=14,600、20 万=28,000 元/年），每月赠 1 万 MAU 免费额；"限制开放"指开通需商务对接，非价格不公开，实际成交可谈优惠。报价不含监控——RN/JS 层崩溃监控须另购 Bugly 专业版。
客户端 26–39 人天说明
口径：26–39 人天为 iOS + Android + 鸿蒙三端合计，单端约 8–13 人天。工作量主体是失败态处理（下载中断、包损坏、验签失败、版本不匹配、更新后启动崩溃、磁盘不足、多进程并发、灰度分组漂移），而非"下载后解密"。
| 工作项 | iOS | Android | 鸿蒙 |
|---|---|---|---|
| 下载器（断点续传、重试、并发控制） | 2 | 2 | 3 |
| 验签（公钥校验、防重放、时间戳） | 1.5 | 1.5 | 2 |
| 解密（AES-GCM，Native 层 + 密钥内存保护） | 2 | 2 | 3 |
| 安全存储与原子替换 | 1.5 | 1.5 | 2 |
| 版本兼容 + 回滚 / 反触发 | 1.5 | 1.5 | 2 |
| 容器改造（加载 Bundle、重载、路由衔接） | 2 | 2 | 2 |
| 共用设计 / 契约 / 日志（三端一次） | — | — | — |
| 合计 | 约 26–39 人天 |
自建到底要做哪些事
| 角色 | 一次性投入 | 长期投入 |
|---|---|---|
| 客户端（三端） | 26–39 人天 | 随 RN 版本升级维护 |
| 服务端（下发 / 版本矩阵 / 灰度引擎 / 发布后台 / 签名 / 统计） | 15–25 人天 | 功能迭代与值班 |
| 运维（CDN / KMS / 监控告警 / 演练） | 5–10 人天 | 0.2–0.3 人力/年 + CDN |
| 安全（威胁建模 / 密钥规范 / 实现评审 / 渗透 / 合规 checklist） | 5–10 人天 | 定期评审与密钥轮换 |
| 测试（热更专项 / 三端一致性 / 回归分级 / 灰度演练） | 5–8 人天 | 每次热更包回归 |
| 产品 / 运营（判断走 OTA / 审批口径 / 放量决策） | 1–2 人天 | 每次发布审批 |
结论：自建为终态，托管作为过渡
自建的核心考量（详见 1.2）：① 端到端加密只有自建确定可行；② 只有自建才不存在业务代码存于第三方；③ 通道不应挂在单一供应商生命周期上（App Center / CodePush 已于 2025-03-31 停服）。
兜底路径：若一期排期不允许 60–100 人天，可先用 Pushy 托管过渡（2–5 人天、约 ¥792/年起），后续迁移到私有化部署（15–30 人天）或完全自建。过渡期间默认接受"无端到端加密、代码存于第三方"，需由团队显式确认。
无论哪条路线，以下两项仍需自己做：密钥与证书管理规范、设备可信校验（iOS App Attest / 华为设备证书 / 安卓自有风控）。
3.5 灰度、回滚与止血
任何 OTA 方案必须具备以下能力，缺一项不允许上线：
- 灰度能力：百分比灰度 / 按设备 ID 稳定分桶 / 按渠道定向（且下发须受 4.2 的版本矩阵约束）；
- 止血能力：服务端一键禁用 + 客户端自动回滚（
markSuccess反触发：更新后首次启动未上报成功，下次启动自动退回上一版本）； - 可观测与值守：采用率、下载成功率、安装成功率、按 Bundle 版本聚合的崩溃率；以及明确的紧急联系人与值班授权。
4. 发布方式与 Bundle 管理
4.1 三种发布形态（澄清"要不要半夜发版"）
| 形态 | 触发场景 | 是否需商店审核 | 是否需要非工作时间操作 |
|---|---|---|---|
| 随版本发布（常规） | 常规迭代、新功能、含原生改动 | 需要 | 否，与现在完全一样 |
| 内置 Bundle 更新 | 每次 App 发版时，包内基线 Bundle 同步更新 | 需要 | 否 |
| 热更新 / 灰度下发 | 线上问题修复、运营内容变更、小流量验证 | 否 | 仅紧急修复时需要；常规热更是工作时间内的后台发布 |
写 RN 不需要半夜发版。 OTA 是"随时可发"，不是"必须半夜发"；需要非工作时间操作的只有一种情况——线上严重问题需立即止血。而且新 Bundle 只对下一次冷启动生效，用户感知与操作时间无关。
紧急下发按此阶梯执行（建议写进值班手册）：确认影响面 → 修复出包 → 内部验证 → 灰度 5% → 观察崩溃率与业务指标 30–60 分钟 → 30% → 100%，异常时服务端一键禁用、客户端下次冷启动自动回退。
4.2 Bundle 版本管理（不只是热更新才用）
常见误解是"Bundle 只有热更新时才变"。实际每次 App 发版时，包内都要内置一份新基线 Bundle，OTA 下发的是基于该基线的补丁，二者纳入同一张版本矩阵。
App v9.5.0（内置 Bundle B9.5.0）
├─ 热更补丁 P1（适用于 v9.5.0）
├─ 热更补丁 P2（适用于 v9.5.0，回滚目标 P1）
└─ …
App v9.6.0（内置 Bundle B9.6.0，包含此前所有补丁的正式化）
└─ 新一轮补丁…规则：
- 每个 App 版本内置一份基线 Bundle，作为该版本兜底（无网络也能跑）；
- 补丁只对其声明的 App 版本范围生效；
- 每次发版时把已验证的补丁固化进新的基线 Bundle，避免补丁链无限增长；
- 版本矩阵
App 版本 × Bundle 版本 × 三端必须显式维护并由服务端强制校验——这是防止"新 Bundle 打在老二进制上"的唯一手段。
4.3 对 Git 与 Jenkins 的影响（可用脚本实现，不必改造 Jenkins 体系）
| 环节 | 影响 |
|---|---|
| 分支管理 | 基本无变化，沿用现有分支模型；RN 代码建议独立仓库（或 Monorepo 独立目录），版本打 tag 与 App 版本关联 |
| Jenkins 打包 | 新增一个构建阶段，可用脚本实现：产出 Bundle（三端各一份）→ Hermes 字节码化 → 加密 + 签名 → 上传；随后执行原有 build |
| 产物管理 | 新增 Bundle 制品与版本矩阵记录，纳入现有制品管理 |
| 灰度发布 | App 包仍走商店；Bundle 走下发通道（可独立于 App 版本） |
Bundle 相关每一步都是命令行可完成的，Jenkins 只需在原有流程前增加一个"执行脚本"步骤，脚本失败即中断构建。
Jenkins 脚本要做的事（事项不少，这是新增工作量来源）
| # | 阶段 | 脚本要做的事 |
|---|---|---|
| 1 | 环境与前置检查 | Node / 依赖版本校验；分支与 App 版本号校验；工作区干净校验；CI 凭据可用性检查 |
| 2 | 安装依赖 | npm / ohpm 依赖安装与缓存复用，失败即中断 |
| 3 | 构建三端 Bundle | iOS、Android 各出一份；鸿蒙走 bundle-harmony；同时产出 assets |
| 4 | Hermes 字节码化 | 调用 hermesc 产出 .hbc 并校验有效性 |
| 5 | Source Map 产出与上传 | 上传 Hermes Source Map 到崩溃平台（供 JS 堆栈还原，漏了无法补救） |
| 6 | 加密与签名 | 从 KMS / CI 凭据取私钥签名，产出加密包与签名文件（私钥不落脚本、不进仓库） |
| 7 | 版本矩阵写入 | 记录 App 版本 × Bundle 版本 × 平台 × 灰度通道 |
| 8 | 上传 CDN / 制品库 | 上传加密包并校验可正常回源下载 |
| 9 | 产物归档 | Bundle 包、Source Map、构建日志归档留存，便于追溯与回滚 |
| 10 | 注入内置基线 Bundle | 把基线 Bundle 拷入原生工程资源目录，供后续 build 打进 App 包 |
| 11 | 失败处理 | 任一步失败即非零退出码、打印明确错误、触发告警 |
| 12 | （可选）触发灰度 | 调用发布接口设置灰度比例，或仅上传待人工放量 |
脚本必须满足四点：① 幂等；② 失败即非零退出码；③ 产物带 App 版本号、Bundle 版本号与校验值；④ 私钥走 CI 凭据 / KMS，不落脚本、不进仓库。
脚本的本质：在原有 build 之前插入一段"产出 Bundle → Hermes 字节码化 → 加密签名 → 上传 CDN → 把基线 Bundle 拷入原生工程资源目录"。每一步都是命令行可完成的标准动作，因此用现有脚本方式即可承接，方案细节待选型确定后补充，不必预先固化实现。
5. 承载范围：哪些页面用 RN
5.1 复用口径（保守，且可度量）
| 层次 | 内容 | 期望复用率 |
|---|---|---|
| L1 逻辑层 | 网络、数据模型、缓存、鉴权、埋点、业务计算 | 90%+ |
| L2 组件 / 页面层 | UI 组件、业务页面、状态管理 | 双端 70%–90% |
| L3 平台适配层 | TurboModules、原生桥接、平台差异分支 | 不复用，这层的大小决定整体上限 |
提醒：真正成本不在"写 RN 页面"而在 L3——把登录、支付、会员卡、取票码、定位、推送、埋点等能力做成三端语义一致的 TurboModule，必须在评估时单独计入；鸿蒙侧还需确认每个三方依赖是否有 RNOH 适配版本。
5.2 由谁来决定（关键机制）
该问题长期争议的根源是信息与责任不对称：技术知道风险边界，产品知道业务优先级，谁单独拍板都会出问题。建议采用"技术出标准、产品做选择、指标兜底、争议升级"：
| 环节 | 负责方 | 产出 |
|---|---|---|
| ① 制定《技术栈准入标准》 | 技术 | 明确"哪些类型必须原生"（首页、选座、支付、强手势/复杂动效、极致体验要求），其余默认 RN |
| ② 具体页面选型 | 产品 / 业务 在标准范围内决定 | 页面级技术栈标注 |
| ③ 设立体验达标线 | 技术 + 产品 共同确认 | 可量化指标：首屏耗时、帧率、崩溃率、与原生同类的差值上限（示例口径：首屏差值 ≤ 30%、帧率不低于原生同类 90%、崩溃率不高于原生同类；具体阈值以 PoC 实测后确定） |
| ④ 上线前验收 | 产品 + 测试 | 对照达标线验收，不达标则回退原生或优化 |
| ⑤ 争议升级 | 技术负责人 + 产品负责人 | 按"达标线是否达标"作为客观裁定依据 |
价值在于把"体验不好"从主观指责变成可验收指标：达标线上线前共同确认，事后争议有客观依据，不必由某一方单独背锅。
按类型划分的承载范围（示例）（供讨论）：
| 技术栈 | 建议模块 |
|---|---|
| 保持原生 | 首页、核心交易链路（如选座 / 下单 / 支付） |
| 优先 RN | 内容资讯、评论/榜单、会员权益与积分、票券与卡包、周边商城、活动运营页 |
| 保持 H5 | 对外投放、需要外链传播的轻量活动页 |
6. RN 版本升级与回归成本（重点：必须写进年度排期）
这是引入 RN 后长期、周期性存在的成本，易被低估，也是测试工作量波动的主要来源。
6.1 为什么必须升——不升的代价
- 官方只维护最近 3 个次版本：落后即进入 Unsupported，Bug 修复与安全补丁不再提供，遇到 RN 自身问题只能自己改源码——成本极高且每次升级都要重复解决。
- 工具链会被倒逼升级：Xcode、Android SDK、Gradle / AGP、Kotlin 要求随 RN 抬高，商店也会提高最低 SDK 门槛。拖得越久越可能被迫一次跨多版本（RN 0.82 移除旧架构即为典型强制切换），风险与工作量成倍放大。
- 三方库逐步不再支持旧版本，出问题无人修复。
- 安全：Unsupported 版本出现 CVE 不会回溯修复。
6.2 为什么升级需要大范围回归——影响面说明
RN 升级替换的是整个运行时（Hermes、Fabric、TurboModules、Codegen），不是升级某个 SDK；所有 RN 页面都跑在同一运行时之上，因此：
理论上所有 RN 页面都在影响范围内，不存在"只影响某一个页面"。
| 风险类型 | 具体表现 |
|---|---|
| 渲染与交互差异 | 布局、字体、行高、圆角阴影、安全区、图片缩放；手势、滚动惯性、返回键/侧滑、焦点与键盘行为 |
| 三方库与桥接接口变更 | 组件属性、回调、默认值变化导致隐性失效；TurboModule / Codegen 契约变化 |
| 动画与性能漂移 | 动画中断、掉帧、Reanimated 兼容；启动耗时、内存、列表帧率变化 |
| 三端不一致 | 同一份代码在 iOS / Android / 鸿蒙表现分化 |
每次 RN 升级都伴随一次"全量 RN 页面"级别的回归测试——这是引入 RN 后的常态化测试成本，必须在项目与年度排期中明确预留。
6.3 建议节奏与单次成本
| 项 | 建议 |
|---|---|
| 升级节奏 | 每 4–6 个月一次（对齐季度排期）；不必跟 RN 每 2 个月的版本，但不要跨 3 个以上版本跳跃 |
| 跨 3+ 版本升级 | 视为专项项目：独立排期、更重的回归与更长的灰度观察 |
| 单次成本（估算） | 升级改造 3–8 人天 + 回归测试 5–15 人天（视 RN 页面数量，首年取下限） |
| 年度占用 | 约 2 次 × (8–23) 人天 ≈ 16–46 人天/年（RN 页面规模扩大后上行） |
每次升级要做的事（工时即由此构成）：
| # | 步骤 | 具体内容 | 人天 |
|---|---|---|---|
| 1 | 升级前评估 | 阅读变更日志与破坏性变更清单；核对三方库兼容版本；确认 RNOH 是否有对应版本 | 1–2 |
| 2 | 升级改造 | 依赖升级、Codegen 契约适配、废弃 API 替换、三端工程配置（Gradle / Pod / CMake）调整 | 2–6 |
| 3 | 自动化冒烟 | 跑核心页 E2E；对比性能基线（启动耗时、内存、帧率） | 1–2 |
| 4 | 人工回归（大头） | L1 全量、L2 冒烟 + 关键路径、L3 冒烟；三端各执行一遍 | 5–15 |
| 5 | 灰度观察 | 随版本灰度发布，观察崩溃率与业务指标后全量 | 1–2（可与发版合并） |
6.4 如何压降回归成本（纪律问题，不是技术问题）
- 禁止改动 RN 源码、禁止深度定制——定制越多升级越痛，这是所有手段里最重要的一条。
- 组件集中化：样式与交互收敛进业务组件库，升级时只改一处。
- 平台差异收敛进适配层，禁止散落业务代码。
- 分级回归：L1 核心页（高频、含权益/券/支付）全量；L2 冒烟 + 关键路径；L3 冒烟。
- 自动化冒烟：核心页建 E2E 脚本，升级后先跑自动化再人工，把人工回归压到 L1。
- 固定升级窗口：每季度预留排期，避免临时插入打乱业务迭代。
7. 对现有团队与流程的影响
7.1 两类同学分别要补什么（现学现用路径）
前提：由现有原生同学与前端 H5 同学共同参与，两类人起点不同。
| 起点 | 已有优势 | 主要短板 | 切入方式 |
|---|---|---|---|
| 原生同学 | 平台能力、原生容器、工程化；TurboModule 桥接是强项 | TypeScript / React 基础 | 从桥接切入：先承担 1–2 个 TurboModule，把原生能力暴露给 RN |
| 前端 H5 同学 | React / TypeScript 是强项 | RN 与浏览器差异（样式只支持 CSS 子集、无 DOM、布局是 Flexbox 子集） | 从页面切入：先重写一个低频二级页面，并补 RN 与 H5 的差异 |
两类人都需掌握：RN 特有概念、原生桥接（TurboModules + Codegen）、构建与调试（Metro / Fast Refresh / DevTools / 三端运行）、性能与包体（长列表 / 动画线程 / Bundle 体积）、热更新与安全（下发 / 验签 / 灰度回滚）。
上手建议：原生从桥接切入、前端从页面切入，每项任务两类同学搭配，互相补位；目标仍是全员掌握基础，每人能独立完成 RN 页面开发并理解桥接原理。
7.2 开发工具与日常编码方式
| 项 | 说明 |
|---|---|
| 编码 | TypeScript + React 函数式组件 + Hooks |
| IDE | VS Code（RN 开发）/ Xcode、Android Studio、DevEco Studio（原生与三端运行） |
| 调试 | Fast Refresh 秒级热重载；React Native DevTools；原生断点在各自 IDE |
| 运行 | iOS/Android 用 RN CLI 起 Metro 连真机/模拟器；鸿蒙用 DevEco Studio + bundle-harmony |
| 三端差异 | 按平台后缀区分代码，差异收敛进统一适配层 |
| 与原生联调 | 原生容器提供入口参数（路由、用户态、埋点上下文）；RN 通过 TurboModule 调用原生能力 |
7.3 对测试的影响
- 三端验证：同一份 RN 代码需在三端分别验证（平台差异、字体、手势、返回键/侧滑需逐端看）。
- 热更新专项（全新测试类型）：用例清单见 3.4 测试角色工作项，涵盖弱网中断降级、版本错配拒绝加载、验签解密失败兜底、更新后崩溃自动回滚、灰度分桶稳定性、禁用开关即时性。
- 回归范围：RN 运行时升级或公共组件改动时分级回归（核心页全量、其余冒烟）；日常单页改动只回归该页。
- 对产品/业务：需求描述需标注技术栈（走 RN 还是原生，影响排期与上线方式）；需适应"先灰度看数据再全量"的节奏；埋点口径必须与原生页面统一，否则数据割裂。
8. 落地前需要先建好的基础能力
8.1 网络、埋点、登录等"框架层"：复用还是自研？
结论：能复用原生通道的一律复用。 在 RN 里重写一套会直接带来数据割裂（埋点口径不一致、登录态不同步）与双份维护成本。
| 能力 | 建议方案 | 理由 |
|---|---|---|
| 埋点 | 复用现有原生埋点 SDK，通过 TurboModule 暴露给 RN | 埋点口径必须与原生页面完全一致，否则数据分析不可用 |
| 登录态 / 鉴权 | 复用原生，RN 只读取 | 涉及安全，不应有两套实现 |
| 网络请求 | 与现有网关强绑定（统一签名、加解密、风控头）的能力走 TurboModule 复用原生通道；简单业务接口可用 RN 侧 HTTP 库 | 涉及统一网关协议与签名的必须复用 |
| 路由 / 跳转 | 统一路由表，RN 与原生互跳走同一套 scheme | 避免两套路由各自维护 |
| 日志 / 配置 / 推送 | 复用原生 | 同上 |
成本：复用方案的成本主要是写 TurboModule 桥接（每个能力约 1–3 人天，含三端）；自研除开发成本外，还要长期维护两套逻辑与两套埋点口径，长期成本更高、风险更大。因此复用更优。
必须新建的只有"RN 侧薄封装层"：定义 TS 契约 → Codegen 生成三端绑定 → 三端各写实现 → RN 侧包装统一 API 与类型 → 统一错误码与超时/重试 → 补埋点与日志。整体约 5–10 人天。
8.2 UI 组件：需要一套，但不要从零写（且必须按设计稿重做视觉）
与页面强绑定的控件（标签页、下拉刷新、空状态、Toast、弹窗、导航栏等）必须在 RN 侧有一套，因为 RN 页面无法直接使用原生 UI 组件。
要区分"能力"与"视觉"：社区库解决的是能力（能否下拉刷新、能否切页、动画是否跑在 UI 线程），不带我们的设计稿视觉；间距、字号、圆角、颜色、动效曲线都必须按App 设计规范重新定义。因此成本上视觉对齐与封装占大头（约 60%–70%），能力接入是小头。
| 场景 | 做法 | 视觉处理 |
|---|---|---|
| 标签页 / 页面切换 | 基于成熟社区方案（如 react-native-tab-view / pager-view） | 按设计稿重做指示器、选中态、滑动阈值 |
| 下拉刷新 / 长列表 | RN 自带 RefreshControl + FlashList（长列表性能必需） | 刷新动画与文案按规范替换 |
| 手势与动画 | Reanimated + Gesture Handler（动画跑 UI 线程） | 动效曲线统一到设计令牌 |
| 复杂自绘（座位图、票面、海报） | Skia | 完全按设计稿绘制 |
| Toast / 弹窗 / 空状态 / 加载 / 导航栏 | 基于基础组件自行封装 | 逐一按设计稿实现 |
统一做法：先建立设计令牌（Design Token）——间距、字号、字重、圆角、颜色、动效曲线集中定义，组件只引用令牌。规范调整时只改令牌；这也是 RN 版本升级时降低回归成本的关键（见 6.4）。
要做的事：梳理设计规范并落成令牌 → 选定底层社区方案 → 按设计稿实现视觉 → 三端核对渲染差异 → 补无障碍与埋点 → 写文档与示例页。
成本：组件库（常用 15–25 个组件）约 15–25 人天，其中视觉实现约 10–17 人天。这部分必须做，否则每页重复造轮子，视觉与质量都无法统一。
另一项必备的工程约束：建立 Bundle 体积预算——每次构建产出体积报告，超限阻断；长列表与动画的实现方式已在表中明确（核心列表页的卡顿基本都出在长列表）。
9. 线上监控
| 监控对象 | 建议方案 |
|---|---|
| 原生层崩溃 / ANR | 沿用现有崩溃监控平台（以 Bugly 为例）（自 2024-05 起支持鸿蒙，三端可统一） |
| RN / JS 层异常 | Bugly 专业版（腾讯端服务 TDS）2025-10 起支持 React Native 监控（错误监控、页面访问、自定义上报）；另有 bugly-rn-sdk（腾讯云可观测平台，当前 beta / 灰度）。选型前需与腾讯侧确认套餐与稳定性 |
| Hermes 字节码堆栈还原 | 必做且须提前确认：字节码下 JS 崩溃只有偏移，需上传 Hermes Source Map 才能还原到源码行。先向厂商确认是否支持，不支持则换方案。这是"上线首日必须打通、事后补不回来"的工程项 |
| Bundle 版本维度 | 崩溃率、ANR、首屏耗时必须能按 Bundle 版本（updateId）+ App 版本 + 端下钻——没有这个维度，热更新就无法安全运行（无法判断某个补丁是否劣化） |
成本（Bugly 专业版，腾讯端服务 TDS）：预付费资源包，两种套餐（刊例价，元/年）——
| 套餐 | 档位 | 价格 |
|---|---|---|
| 事件量套餐（按上报量，无采样率限制） | 6 亿条/年（参考 MAU 20w） | 32,000 |
| 15 亿条/年（参考 MAU 50w） | 80,000 | |
| 30 亿条/年（参考 MAU 100w） | 160,000 | |
| 月活套餐（按 MAU 阶梯，无采样率限制） | 5 万 | 50,000 |
| 10 万 | 80,000 | |
| 20 万 | 130,000 | |
| 50 万 | 240,000 | |
| 100 万 | 350,000 |
有效期 365 天，按天统计、次日结算。RN 监控为专业版功能，免费版 Bugly（bugly.qq.com）的基础崩溃监控免费但不含；选型时按自身 MAU 对照档位即可。bugly-rn-sdk（腾讯云可观测平台）目前为 beta / 灰度，计费与稳定性未公开，暂不作为报价依据，需另行向腾讯确认。
注意 Shiply 与 Bugly 是两个独立产品、两份独立账单：走 Shiply 做热更新通道，仍需另购并接入 Bugly 专业版才能获得 RN/JS 层崩溃监控与按 Bundle 版本统计——Shiply 本身不含崩溃监控。这是监控侧一笔真实的新增成本，应与 OTA 建设成本分开列出，避免被误认为"RN 监控不花钱"。
10. 风险与应对
| # | 风险 | 应对 |
|---|---|---|
| R1 | 鸿蒙侧 RN 版本滞后上游（当前稳定组合 0.84.4，0.86 主干已合入），且 0.82 / 0.84 在 RN 官方口径均已 Unsupported | 立项前实测确认可用版本线；三端统一版本；RNOH 2026 已按季度跟版（0.82/0.84/0.86/0.88），滞后风险缓解，但首季度仍应把"跟进 0.86"列入任务 |
| R2 | 落后即失去补丁支持，且升级需全量 RN 页面回归、测试成本周期性上升 | 每 4–6 个月升一次；不跨 3 个以上版本；禁止改动 RN 源码；核心页自动化冒烟。详见第 6 章 |
| R3 | 三方库鸿蒙适配缺口，可能推高工作量 | 落地前完成依赖清单逐项盘点；优先选已适配版本；为自适配预留预算 |
| R4 | 热更触碰合规红线导致审核被拒 | 3.2 节红线写入规范；发布前合规 checklist |
| R5 | Bundle 与二进制版本不匹配导致大规模崩溃 | 版本矩阵强制校验；灰度 5% 起步；自动回滚；服务端一键禁用 |
| R6 | 密钥/加解密实现不当被提取 | 实现下沉 Native；密钥走 KMS + 白盒；定期轮换（公钥内嵌包内，轮换需配合新二进制） |
| R7 | 热更扩大个人信息收集范围，与隐私政策 / 商店隐私清单不一致（含 RN 页面埋点未申报） | 发布前加隐私检查：涉数据采集 / 权限 / SDK / 使用目的变更一律禁止走热更，改走版本发布；隐私清单覆盖 RN 页面；保留 patch 审计记录。详见 3.2 |
附：参考来源（公开资料）
| # | 来源 | 用于支撑本文的哪部分 |
|---|---|---|
| [1] | React Native 官方《Releases Overview》 | 版本支持策略与 2026 年现状（Active / End of Cycle / Unsupported） |
| [2] | React Native 官方博客（0.84 / 0.87 发布说明） | Hermes V1 默认、新架构、构建工具链要求 |
| [3] | OpenHarmony SIG ohos_react_native（RNOH）及社区解读 | 鸿蒙侧版本线、架构、三方库适配数量 |
| [4] | Pushy 热更新（React Native 中文网）官网与文档 | 三端覆盖、增量差分实测、核心代码开源、¥66/月起定价 |
| [5] | Bugly 专业版新功能发布记录（2025-10 / 2026-03） | RN / JS 层监控的支持情况 |
| [6] | 腾讯云可观测平台 React Native SDK 文档 | bugly-rn-sdk 集成方式与当前灰度状态 |
| [7] | Apple Developer Forums（JSPatch 警告，2017-03） | 热更新合规边界（配合审核指南与开发者协议条款引述） |
| [8] | Meta Engineering《Hermes》 | Hermes 字节码预编译与性能设计目标 |
| [9] | Bugly 专业版《产品计费》 | 专业版报价与两种套餐的计费方式 |
| [10] | 腾讯 Shiply《React Native 热更新》文档 | 三端覆盖与鸿蒙适配时间（v0.4.0 / 2025-12-22）、接入依赖 RNOH、限制开放说明 |