1. 内容整体设计与思路拆解
1.1 为什么要在存量原生应用里引入React Native
最近一年多，我一直在维护一个已经上线三年多的Android原生应用，日活大概几十万规模。业务方的需求越来越离谱，从“下周上线一个新活动页”发展到“今天下午能不能先出个Demo看看效果”，原生开发的节奏越来越跟不上。
把React Native嵌进现有原生应用，说白了就是看中它的动态下发能力。传统原生应用发版要过应用市场审核，一套流程走下来最快也得两三天，遇到紧急需求只能干着急。而React Native的JS Bundle可以走自己的下发通道，打完包直接推到用户手机上，用户冷启动时拉最新代码，完全绕开应用市场审核，这个优势在强运营场景下是致命的。
但注意，我这边说的是“混合开发”，不是“替换”。选择这条路的原因很现实：核心业务链路（登录、支付、首页信息流）是原生代码，跑了很多年，稳定性经过充分验证，没必要冒着风险重写。而运营活动页、营销专题、低频工具类页面，用React Native开发再合适不过，既能快速迭代，又不会影响核心链路质量。两个技术栈并行，各干各擅长的活，这是混合开发最根本的价值逻辑。
1.2 混合开发的技术路线选型
React Native集成方式本质上就两条路：官方推荐的bare workflow（纯RN工程再嵌入原生），以及从原生工程反向集成RN。前者适合新项目从零开始，后者才是存量应用混合开发的正确姿势。
这两条路的技术难点完全不在一个量级。新建一个RN工程跑起来，官方脚手架一把梭，基本上不用关心底层细节。但把RN塞进一个已经存在的原生项目，你需要处理依赖冲突、Gradle配置、生命周期对接、资源命名空间隔离、内存管理等等一堆破事。我这篇博文踩的坑，全部集中在第二种方式——原生为主、RN为辅的混合架构。
说句实在话，如果原生项目还停留在老旧的Gradle 3.x、Android Plugin 2.x时代，建议先别急着集成RN。RN新版本对构建工具链要求比较高，升级Gradle本身就是一个大工程，和RN集成的工作量叠加，排查问题时会非常痛苦。我司的工程当时已经用上了Gradle 7+，集成过程还算顺利，如果你的项目构建工具链比较老，建议先把基础环境升级到主流版本再动手。
1.3 版本选型背后的考量
React Native的版本选型是个容易让人纠结的事情。新版本功能多、性能好，但第三方库的兼容性往往滞后，社区生态跟不上，遇到问题连个参考资料都难找。老版本稳定、踩坑的人多、解决方案丰富，但性能和功能迭代确实跟不上。
我的建议是选择当前最新的稳定大版本，然后在实际集成时锁定小版本号。以我集成时的经验，React Native 0.7x系列在混合开发场景下已经比较成熟，各方面坑基本被社区填平了。集成时务必把react和react-native版本写到package.json的具体版本上，不要用通配符，否则哪天不小心执行npm install升级了依赖，整个项目可能直接崩掉。
还有一点容易被忽略：React Native对Node.js版本有要求。集成前先检查Node版本，太老或太新都可能导致npm install失败或者Metro报错。我刚开始就在这上面浪费了半天时间，后来统一用nvm管理Node版本，再没出过幺蛾子。
2. 核心细节解析与实操要点
2.1 原生工程改造的完整步骤
从零开始集成React Native到现有Android原生工程，我梳理了大致六步，每步都有容易踩坑的细节。
第一步：在原生工程根目录初始化Node环境
npm init -y这条命令会在工程根目录生成一个默认的package.json。注意不要直接在已有package.json上硬改，更不要跳过初始化直接install，Node模块依赖树非常敏感，缺了package.json后面排查问题会很麻烦。
第二步：安装react和react-native依赖
npm install react@版本号 react-native@版本号 --save这里有个细节：react和react-native版本必须严格对应。RN官方文档里有版本映射表，装之前先去查一下，别拿一个RN 0.7x配一个React 18.3，虽然大概率能跑，但有些底层API行为会很诡异。
第三步：修改Android工程的Gradle配置
在android/build.gradle的buildscript和allprojects里添加RN的Maven仓库地址：
allprojects { repositories { maven { url "$rootDir/../node_modules/react-native/android" } maven { url "https://www.jitpack.io" } mavenCentral() google() } }注意仓库顺序。RN的Maven仓库要放在google()前面，否则某些依赖版本解析时可能会拉到不兼容的包。
第四步：在android/app/build.gradle里声明RN依赖
dependencies { implementation "com.facebook.react:react-native:+" }这里的+号表示从本地Maven仓库找版本，但在正式项目里我强烈建议写死版本号：
implementation "com.facebook.react:react-native:0.72.4"写死版本号的好处是构建可复现。团队里多个人开发，或者CI机器上构建，如果依赖是动态版本，今天能编过明天可能就编不过，这种问题排查起来非常痛苦。
第五步：配置AndroidManifest权限
<uses-permission android:name="android.permission.INTERNET" />如果Debug模式下还需要访问开发服务器：
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />INTERNET权限是硬性的，没有它JS Bundle都拉不下来。其他权限按需添加，Debug下可以授予悬浮窗权限方便看红屏报错。
第六步：创建React Native的入口Activity
这一步是混合开发的核心。你需要有一个承载RN页面的原生Activity，这个Activity本身是空壳，核心逻辑全在JS侧。
public class ReactNativeActivity extends ReactActivity { @Override protected String getMainComponentName() { return "MyReactNativeApp"; } }getMainComponentName返回的名字，必须和JS侧AppRegistry.registerComponent注册的名字保持一致，大小写敏感，错了页面直接白屏。
2.2 原生模块对接与生命周期绑定
RN页面跑在原生Activity中，生命周期对齐是个容易忽略但极其重要的细节。
ReactActivity内部已经帮我们处理了大部分生命周期转发，但如果你是自己手动创建的ReactRootView，就需要手动同步生命周期：
public class RnContainerActivity extends AppCompatActivity { private ReactRootView mReactRootView; private ReactInstanceManager mReactInstanceManager; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); mReactInstanceManager = ReactInstanceManager.builder() .setApplication(getApplication()) .setCurrentActivity(this) .setBundleAssetName("index.android.bundle") .setJSMainModulePath("index") .addPackage(new MainReactPackage()) .setUseDeveloperSupport(BuildConfig.DEBUG) .setInitialLifecycleState(LifecycleState.RESUMED) .build(); mReactRootView = new ReactRootView(this); mReactRootView.startReactApplication(mReactInstanceManager, "MyReactNativeApp", null); setContentView(mReactRootView); } @Override protected void onPause() { super.onPause(); if (mReactInstanceManager != null) { mReactInstanceManager.onHostPause(); } } @Override protected void onResume() { super.onResume(); if (mReactInstanceManager != null) { mReactInstanceManager.onHostResume(this); } } @Override protected void onDestroy() { super.onDestroy(); if (mReactInstanceManager != null) { mReactInstanceManager.onHostDestroy(); } if (mReactRootView != null) { mReactRootView.unmountReactApplication(); } } }这里有一个容易犯的错误：onDestroy里只调用了onHostDestroy，没有调用unmountReactApplication。这样会导致JS侧组件不卸载，内存泄漏是小事，严重时页面状态残留，下次进入时会出现诡异的白屏或UI错乱。
2.3 JS侧入口与原生侧的桥接配置
JS侧入口文件index.js是整个RN页面运行的起点：
import { AppRegistry } from 'react-native'; import App from './App'; import { name as appName } from './app.json'; AppRegistry.registerComponent(appName, () => App);app.json里的name字段和原生Activity里getMainComponentName返回的字符串必须一致：
{ "name": "MyReactNativeApp", "displayName": "我的RN页面" }这里有个细节很多人不知道：app.json里的name不仅被AppRegistry用，还影响Metro打包时的模块命名。如果你的JS入口文件叫index.js，但打包时找不到对应的模块，检查一下入口路径是否配置正确。
2.4 资源与命名的隔离策略
混合开发里RN和原生代码共处一个App，资源冲突是个高频问题。最容易踩的坑是strings.xml和colors.xml等资源文件里的同名项互相覆盖。
我见过一个真实事故：原生工程里有一个app_name字符串，RN侧某个第三方库的资源文件里也有app_name，编译时资源合并直接冲突，整个项目编不过。解决思路是构建产物检查：
./gradlew :app:processDebugResources --info | grep "app_name"排查出冲突后，要么改掉RN侧库的资源名，要么在原生资源里用tools:override覆盖。常规做法是尽量保证双方资源名前缀不同，原生工程用app_开头，RN侧的库用rnn_或react_开头，从源头规避冲突。
还有一个容易被忽略的点：图片资源。RN里引用的图片，如果打包进bundle，会占包体积；如果走原生资源，需要手动放到res目录下。混合开发里我建议RN侧的图片资源尽量用线上URL，或者打包进bundle，尽量不要引用原生资源，否则后续JS脱离原生独立发布时会因为找不到资源而白屏。
3. 实操过程与核心环节实现
3.1 环境准备与版本对齐检查清单
集成RN之前，先把环境检查一遍，省得做到一半卡住。我列一个实用清单，照着查就行：
| 检查项 | 推荐配置 | 备注 |
|---|---|---|
| Node.js | 18.x或20.x LTS | 用nvm管理，避免版本混乱 |
| JDK | JDK 11+（Android Gradle Plugin 7.x要求） | 老项目还在用JDK 8的话先升级 |
| Android SDK | API 33+ | 编译SDK版本建议不低于RN要求的最低版本 |
| Gradle | 7.x+ | 与Android Gradle Plugin版本配套 |
| NDK | 按RN官方要求 | 部分第三方库需要NDK编译 |
| yarn | 可选 | 比npm快，且锁文件更严谨 |
有一点提醒一下：如果原生项目之前没用过Kotlin，集成RN时尽量别混入Kotlin代码，除非你愿意处理Kotlin和Java之间的互操作问题。RN的Android源码是Java为主，Kotlin能跑但不必要，混用反而增加排查成本。
3.2 依赖安装与Gradle构建现场实录
我实际执行安装依赖时，遇到过不少网络和构建问题。国内网络环境下从npm拉包比较慢，用镜像源是常规操作：
npm config set registry https://registry.npmmirror.com但这里有一个坑：npm镜像源只影响JS侧的node_modules下载，不影响Gradle从Maven仓库拉取Android依赖。如果Gradle下载react-native的AAR包时速度很慢或超时，需要在~/.gradle/gradle.properties里配置代理：
systemProp.http.proxyHost=127.0.0.1 systemProp.http.proxyPort=1080 systemProp.https.proxyHost=127.0.0.1 systemProp.https.proxyPort=1080如果实在拉不下来，可以考虑用阿里云Maven镜像：
maven { url "https://maven.aliyun.com/repository/public" } maven { url "https://maven.aliyun.com/repository/google" }构建过程中最常见的报错是Could not find com.facebook.react:react-native:x.x.x，这个报错八成是Maven仓库顺序问题或仓库地址配错。检查一下allprojects里有没有包含本地node_modules/react-native/android这个路径。
./gradlew :app:assembleDebug我第一次构建时卡了将近二十分钟，主要时间耗在下载React Native的AAR包和相关的transitive依赖上。构建通过后，APK体积大约增加了8-10MB（Debug包），Release包的增量会小一些，因为RN的bundle压缩率高。
3.3 离线Bundle打包与集成策略
混合开发最终要交付的形态有两种：Debug模式走Metro开发服务器，Release模式用离线Bundle。
Debug模式的原理是：App启动时通过网络从本地Metro服务器拉取JS Bundle，这样改JS代码后只需要刷新页面，不需要重新编译原生工程。适合开发调试阶段使用。
Release模式则是把JS Bundle打包成文件，放进Assets目录或通过网络下发到本地，App启动时直接从本地加载，不依赖开发服务器，这是线上体验的关键。
打包离线Bundle的命令：
npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle --assets-dest android/app/src/main/res/注意--assets-dest指定的目录，打包时会把图片资源拷贝到res目录下。执行一次这个命令后，一定要检查assets目录下是否生成了index.android.bundle文件，如果Android Studio里看不到，可能需要在app/build.gradle里配置sourceSets：
sourceSets { main { assets.srcDirs += "$projectDir/src/main/assets" } }这里有个优化建议：打包出来的bundle文件可能超过1MB甚至几MB，可以考虑开启bundle压缩。RN 0.7x版本支持在生产模式下自动压缩bundle，能显著减少体积，但会增加运行时解压的开销，实际测试下来对启动速度的影响在可接受范围内。
3.4 启动白屏问题定位与解决实录
搜“react native 启动白屏”能搜出一堆帖子，说明这不是小众问题。我在集成过程中也踩过这个坑，总结下来白屏原因无非几类，我按出现频率排序：
第一类：JS Bundle文件缺失或路径错误
这个是最常见的。Debug模式下，App找不到Metro开发服务器就会白屏；Release模式下，Assets目录里没有index.android.bundle就会白屏。
排查方法很简单：先确认开发服务器有没有启动，能不能在浏览器里访问到bundle地址。Release模式下用adb检查：
adb shell ls /data/app/包名-xxx/lib/arm64/ | grep bundle或者直接看logcat：
adb logcat *:E如果看到Unable to load script或EReactNative: Unable to load script from assets index.android.bundle，就是bundle文件缺失或路径不对。
第二类：组件名不匹配
getMainComponentName返回的字符串和AppRegistry.registerComponent注册的name不一致，白屏且没有明显报错。这个最好排查，人肉对比一下两个字符串就行。
第三类：原生Activity继承错了
如果你用的不是ReactActivity，而是普通Activity，然后手动初始化ReactRootView，需要注意ReactInstanceManager的生命周期对接。如果onResume时没有正确调用onHostResume，渲染会停在那里，表现为白屏或界面假死。
第四类：JS侧的运行时异常
JS代码抛异常也会导致白屏，但通常会有红屏或者logcat里有Error日志。如果开了setUseDeveloperSupport(true)，连上Metro，在浏览器里打开Debugger，能看到具体的JS报错堆栈。
我之前排查过一个印象很深的问题：某台测试机始终白屏，但同机型其他设备正常。后来发现是那台设备的系统时间不对，导致bundle下载时TLS证书校验失败。这类问题在Debug模式下尤为隐蔽，因为Metro服务器是http协议，不会触发证书校验，但一旦切到Release模式走https，时间不对就会整段挂掉。
3.5 白屏问题的全面修复方案
如果你已经定位到白屏原因是bundle加载慢或资源加载慢，而不是代码错误，可以尝试以下优化方案，按优先级排序：
方案一：配置SplashScreen启动图
RN页面启动白屏，视觉上很难看，用户会质疑应用卡死了。给RN页面的容器Activity配置一个原生SplashScreen，让页面在JS加载完成前一直显示启动图，体验会好很多。
实现方式很简单：在ReactNativeActivity的onCreate里先setContentView为SplashScreen布局，等ReactRootView加载完成后再切换内容。
方案二：预加载ReactInstanceManager
ReactInstanceManager的初始化很重，它要创建ReactContext、加载JS Bundle、初始化Bridge，这个过程可能耗时几百毫秒甚至更久。我们可以提前初始化它，比如在Application的onCreate里做：
public class MainApplication extends Application implements ReactApplication { private final ReactInstanceManager mReactInstanceManager = ReactInstanceManager.builder() .setApplication(this) .setBundleAssetName("index.android.bundle") .setJSMainModulePath("index") .addPackage(new MainReactPackage()) .setUseDeveloperSupport(BuildConfig.DEBUG) .setInitialLifecycleState(LifecycleState.RESUMED) .build(); @Override public ReactInstanceManager getReactInstanceManager() { return mReactInstanceManager; } }这样在应用启动时就预热了RN环境，等用户真正进入RN页面时，加载速度会快很多。
方案三：优化bundle体积
bundle体积大是启动慢的直接原因。可以通过以下方式瘦身：
- 用Hermes引擎替代JavaScriptCore。Hermes是Facebook专门为RN设计的JS引擎，bundle体积能缩小30%左右，启动时间能减少约20%。RN 0.7x版本开启Hermes很简单：
def enableHermes = true按需引入第三方库。很多开发者为了图省事，把整个库import进来，实际上只用了一两个函数。比如如果你只用lodash的某个方法，建议单独引入，而不是
import _ from "lodash"。移除console.log等开发日志。在生产模式下自动去除console语句，也能省一点体积。
方案四：网络下发bundle并缓存
如果你已经搭建了bundle下发通道，可以在App启动后静默下载最新的JS Bundle到本地，下次启动时优先加载本地新bundle。这种方案的核心在于缓存策略要设计好，别一个bundle版本崩了，用户永远加载不到修复版本。
我司的做法是：本地保留两份bundle，一份是上一次成功加载的版本（回退兜底），一份是当前正在使用的版本。启动时先加载当前版本，同时后台拉取新版本，拉取成功并校验通过后，把新版本置为当前版本。
3.6 Debug与Release模式的双轨配置
混合开发最耗时间的其实是Debug模式和Release模式行为不一致的问题。Debug下走Metro，Release下走本地bundle，很多问题只在特定模式下出现。
我建议在原生代码里明确区分两种模式：
private boolean isDevMode() { return BuildConfig.DEBUG; } private void setupReactInstanceManager() { ReactInstanceManagerBuilder builder = ReactInstanceManager.builder() .setApplication(getApplication()) .setJSMainModulePath("index"); if (isDevMode()) { builder.setUseDeveloperSupport(true); // Debug模式下可以不指定bundleAssetName，走Metro } else { builder.setUseDeveloperSupport(false); builder.setBundleAssetName("index.android.bundle"); } }Debug模式下还有一个额外问题：Metro服务器的端口默认是8081，如果多个项目同时开发，端口会冲突。可以通过启动命令指定端口：
npx react-native start --port 8088这个细节看似不起眼，但团队协作时真的能避免很多早上到公司发现Metro端口被占、白屏一片的惨剧。
4. 常见问题与排查技巧实录
4.1 高频报错对照速查表
我在集成和日常维护RN容器过程中，积累了一些高频问题，整理成表格分享出来：
| 现象 | 可能原因 | 排查/解法 |
|---|---|---|
| 启动白屏，无报错 | bundle文件缺失/组件名不匹配 | 检查assets目录是否生成了index.android.bundle，检查注册名 |
| 红屏报“Unable to load script” | Debug模式下Metro服务器未启动或端口不对 | 先启动Metro，确认端口一致；Release下检查bundle打包路径 |
| 构建报“Could not find react-native” | Maven仓库路径不对或未添加 | 检查allprojects的maven地址是否指向node_modules/react-native/android |
| APK体积暴增几十MB且原生页面变卡 | RN容器初始化占用内存过多 | 检查是否重复创建ReactInstanceManager，确保全局单例 |
| 原生页面和RN页面切换时ANR | 生命周期没同步 | 检查onHostPause/onHostResume/onHostDestroy是否完整调用 |
| 部分Android 7.0以下设备崩溃 | JS引擎和系统WebView兼容性问题 | 升级RN版本或调整JS引擎配置 |
| JS侧报“Unable to resolve module” | npm依赖缺失或路径大小写错误 | 先npm install，检查import路径大小写 |
| 运行时报“getCurrentActivity is null” | 原生Activity与RN实例关联丢失 | 确保setCurrentActivity正确调用，Activity切换时重新绑定 |
| Release模式白屏但Debug正常 | 未打包bundle进Assets | 执行react-native bundle命令，并把生成的bundle提交到版本管理 |
| 内存持续上涨 | ReactRootView未卸载 | onDestroy里必须执行unmountReactApplication |
4.2 原生侧拦截RN特定Intent的坑
RN页面可能需要跳转到原生页面，或者RN页面里需要打开某个深链。如果你的原生工程里写了全局的Intent过滤器，要小心别把RN内部的跳转拦截掉。我遇到过一种情况：原生工程里有一个BroadcastReceiver监听全局的网络状态变化，RN内部某些网络请求会触发额外的广播，结果导致RN页面无端重启。排查了很长时间，最后发现是广播频率过高，RN容器收到onHostPause又立刻onHostResume，界面闪烁。
这类问题没有通用解法，只能根据具体场景在原生侧做过滤。排查思路是：在RN页面出现异常跳转或重启时，先看logcat里的Activity生命周期日志，确认是不是有外部因素干扰。
4.3 内存泄漏排查实录
RN页面退出后，内存是不是被正确释放了，这是混合开发必须关注的问题。用Android Studio自带的Profiler就可以排查：
- 进入RN页面，执行一系列操作
- 退出RN页面，强制GC
- 观察Java Heap是否回落到进入前的水平
如果发现内存没有回落，重点检查两类对象：ReactRootView是否被Activity持有未释放，ReactInstanceManager是否被全局单例引用不释放。
这里有个常见的误区：ReactInstanceManager是全局单例，正常情况不需要销毁，它在Application生命周期内持续存活。但ReactRootView不一样，它是页面级的，每次进入RN页面创建，退出时销毁。如果忘记unmountReactApplication，ReactRootView会被Activity间接持有，Activity无法回收，整个页面的内存都泄漏了。
4.4 双引擎并存的资源冲突
如果你的原生工程里同时集成了其他跨端框架（比如Flutter或者小程序SDK），就可能出现引擎资源冲突。我见过一个项目同时集成RN和Flutter，两个引擎都对系统的某些资源做了hook，结果在特定Android版本上出现画面闪烁或者触摸事件不响应。
这种问题的根治办法是在架构设计阶段就想清楚路由策略：RN容器负责哪些页面，Flutter引擎负责哪些页面，两者互不交叉。如果无法避免交叉，至少要保证UI渲染链路是独立的，不要在RN的Activity里套Flutter的View，反向也一样。
4.5 我多年踩坑总结的三个经验法则
第一条经验：混合开发的核心不是写代码，是控制边界。RN能做的事很多，但不是所有事都适合在RN里做。高频的、对性能敏感的操作（列表滚动、复杂的动画）尽量用原生组件，然后通过NativeComponent暴露给RN侧使用。低频的、强运营的页面才适合用RN做。
第二条经验：离线Bundle的版本管理必须和原生版本解耦。我见过一个项目，把JS Bundle和APK绑在一起发版，结果动态化的意义完全丧失，RN和原生页面都成了“一次性”版本。正确的做法是：APK里的bundle只是兜底版本，线上运行时从服务器拉最新bundle，本地缓存并做版本校验，这样才能发挥RN动态下发的真正价值。
第三条经验：Debug和Release的差异测试越早做越好。不要等到上线前才切Release模式验证，那个时间点发现问题，修改和验证的周期都很长。最好的习惯是本地开发时也经常打一个Release包，确保bundle打包、加载、运行的整套流程一直处于可用状态。
5. 上线前必做的性能体检清单
5.1 启动耗时与页面渲染性能
RN页面上线前，我强烈建议做一次完整的启动耗时测试。方法很简单：用adb记录Activity启动时间，或者用Android Studio的Profiler录制启动过程。
adb shell am start -W -n 包名/ReactNativeActivity线上真实场景，RN页面的秒开率目标是2秒内完成首帧渲染。如果耗时超过3秒，用户流失率会明显增加。
影响启动耗时的主要因素按占比排序：
| 因素 | 影响程度 | 优化手段 |
|---|---|---|
| JS Bundle加载与解析 | 大 | Hermes引擎、bundle压缩、按需加载 |
| ReactContext初始化 | 中 | Application预初始化、懒加载拆包 |
| 首屏组件渲染 | 中 | 减少首屏组件层级、避免复杂布局 |
| 网络请求（如果首屏依赖） | 大 | 数据预拉取、缓存策略 |
| 图片解码（如果首屏有大量图片） | 中 | 图片压缩、WebP格式、渐进加载 |
5.2 内存与稳定性压测
线上最怕的就是RN页面崩溃或内存暴涨。压测方式没有捷径，就是真实场景模拟：反复进出RN页面100次，检查是否有内存泄漏；在低端机上同时运行RN页面和其他重负载页面，观察是否OOM。
低端机测试尤其重要。RN的运行开销比原生大不少，在2G内存的老设备上，RN页面渲染稍微复杂点就可能卡到怀疑人生。建议在性能压测时覆盖一下低端机型，别只看旗舰机的表现。
5.3 灰度发布与动态回退机制
RN页面最大的优势是动态发布，但动态发布也是一把双刃剑。如果一个bad bundle推到了全量用户手机上，后果不堪设想。所以灰度发布机制是混合开发的上线标配。
我建议的灰度策略是：先推到内部测试包验证，再推5%的用户进行小流量观察，关注崩溃率、卡顿上报、页面停留时长等关键指标，稳定后再逐步放量。同时，客户端要留一手“逃逸舱口”：当监测到严重崩溃或白屏时，自动回退到上一个稳定bundle版本，并隐藏RN页面的入口，引导用户走原生兜底页面。
这套机制听起来复杂，但真正线上跑过一两次之后，你就会发现它比什么都重要。
6. 最后再分享一点个人体会
React Native混合开发这条路，技术本身不算难，难的是工程化体系建设和团队协作模式的调整。原生开发和RN开发是两个不同的技术栈，团队里要有清晰的职责分工：原生工程师负责容器稳定性、桥接封装、性能优化；RN工程师负责业务页面开发、组件沉淀和JS Bundle的发布管理。两边如果各干各的，没有统一的技术规范和联调机制，项目迟早会出乱子。
我实际维护RN容器以来，最大的感受是：混合开发没有银弹，RN解决了很多问题，也引入了很多新问题。关键是想清楚自己为什么要用RN，以及愿意为这个选择付出多少维护成本。如果你所在的业务场景确实需要快速迭代、动态下发，RN值得一试；如果只是为了追新，我建议还是先把手头上的原生业务做好再说。
写这篇总结的时候，我又回想起当初第一次在真机上看到RN页面从原生应用里跳转出来那一刻的兴奋感。混合开发这条路，走下来虽然坑不少，但每一步都值得。如果你正在或即将把RN集成进现有的原生应用，希望文章里这些实操细节和踩坑记录能帮你少走一些弯路。
