配了三年 React Native，每次 App Store 审核都要等一周——今天 0.85 把整个桥彻底拆了，等审核这件事变了

上周 React Native 0.85 正式发布，这个版本干掉了最后一段旧 Bridge 代码。从 0.73 实验性引入 Bridgeless Mode，到 0.82 禁用旧架构开关，再到 0.85 把 Bridge 从代码库里彻底移除——这件事走了三年，今天终于落地了。

这件事对跨端团队的影响，比大多数人意识到的要大。

旧 Bridge 到底卡在哪

Bridge 是 React Native 最初设计里 JS 和原生层之间的异步消息队列。每次调用原生 API（摄像头、存储、震动），都要经过 JSON 序列化 → 发到桥接线程 → 反序列化 → 执行 → 序列化返回。一来一回，跨线程，还异步。

对简单应用这点开销无所谓。但做复杂 UI——带手势的列表、带实时数据的图表、频繁更新的列表——每秒几百次 Bridge 往返，每次都带序列化开销，帧率就是这样掉的。

Facebook 自己做过测算：旧架构下 JS 到原生一次调用的典型延迟在 5ms 左右，如果是频繁交互场景，累积效应很明显。

0.85 到底变了什么

0.85 删掉了所有 Bridge 相关代码，没有任何回退路径。这意味着：

所有第三方库必须有 New Architecture 版本，否则装不上。旧版 native module 必须重写为 TurboModule，有自定义原生模块的团队这是最大工作量。迁移窗口其实早就有了——0.82（2025年10月）是最后一个能关掉新架构的版本，还在用旧架构的团队窗口在关闭。

实测数据说话

生产环境迁移报告里的数字比较一致：冷启动（TTI）中端 Android 设备平均缩短 25%~40%，内存占用降低 26%左右，屏幕切换从 180ms 降到 110ms。这些是综合数字，具体的收益取决于你的应用在旧架构下是不是真的被 Bridge 卡住。

有一个细节值得注意：Hermes V1 在 0.84 成为默认引擎，配套的 Hades GC 把 GC 最大停顿从 45ms 压到 12ms，这对复杂列表滚动用户感受最直接——之前偶发的卡顿帧，根子很多在这里。

你现在该做什么

第一步：检查 package.json 里有几个 native 依赖，数清楚哪些还只支持旧架构。这是决定迁移工作量的关键数字，不是那个开关。

第二步：跑一下官方提供的 New Architecture 探测脚本，能出具体的迁移清单。

第三步：如果有自定义 native module，对照 TurboModule 模板重写接口，用 Codegen 生成绑定。这部分没有自动工具，得人工做。

第三方库那块是被动等待——可以去 issue 区看维护者的进度，也可以考虑这段时间先 pin 版本。

值不值得迁

官方态度很明确：新架构不是选做题。0.82 之后就不让关，0.85 之后没有旧代码的运行路径。如果你的应用还在 0.74 以下，这个时间点已经不是「要不要迁」，而是「多快能迁完」的问题了。