RN 容器启动优化：从秒开到毫开的实践

前言

2021 年，58 在 GMTC 上分享了《58RN 页面秒开方案与实践》，系统地介绍了 58 在 RN 性能优化上的一系列探索。那套方案做了三件重要的事：

1. 资源预加载 + 静默更新：解决动态更新瓶颈。如果是同步更新，用户要等 2s+ 才能看到页面。改成异步后，用户进入时直接使用本地缓存，更新在后台静默完成。
2. metro 拆包 + 框架预执行：解决框架初始化瓶颈。将 RN 框架代码和业务代码拆成两个包，App 启动时提前执行框架包。
3. Native 并行请求业务数据：解决业务请求瓶颈。框架初始化和业务数据请求从串行改为并行。

这些方案落地后，大部分页面实现了「秒开」，整体首屏从 2280ms 降到了 985ms。

但「秒开」就是终点吗？

我们的数据表明，首屏时间每降低 1s，访问流失率降低约 6.9%。在上述方案全部落地后，我们实测（Pixel 3a 设备）发现 RN 页面的冷启动仍需 1.78s，热启动需 1.1s。用户从点击到看到内容，仍有明显的白屏。

于是我们把目光投向了下一个瓶颈：RN 容器本身的启动耗时。

本文将分享我们如何在已有方案基础上，通过容器预加载和复用机制，将冷启动降至 0.8s（提升 55%），热启动降至 0.33s（提升 70%） 的完整实践。

---

一、起点：前人解决了什么，留下了什么

先明确我们的起点。下图展示了 58RN 秒开方案已经覆盖的瓶颈，以及我们要继续攻克的部分：

秒开方案优化的是用户进入之前的准备工作——资源下载、框架初始化、业务数据。但当用户真正点击进入 RN 页面时，容器的创建和启动仍然是实时发生的：

每次打开，这个链路都要从头走一遍。这就是我们要攻克的第四个瓶颈。

---

二、先看数据：时间都花在哪里？

搭建性能追踪

优化的第一步不是写代码，而是搞清楚时间花在哪里。

我们在 RN 启动链路的每个关键节点打点——路由进入、初始化开始/结束、容器创建开始/结束、代码加载开始/结束、UI 可见。得到了冷启动 1787ms 的完整耗时分布：

两个关键发现：

• 88.3% 的时间消耗在 JS 引擎初始化、代码解析、首屏渲染等 RN 框架内部逻辑上，短期难以从根本上改变。
• 从路由进入到初始化开始，居然空等了 379ms——将近 400ms 什么都没做。

这两个发现直接指明了优化方向：能提前的提前，能复用的复用，能预加载的预加载。

---

三、四步走：渐进式优化

阶段 1：提前初始化时机 —— 砍掉 379ms 的空等

问题：为什么路由进入后要空等 379ms？

排查发现，原来的代码是在页面 onResume 生命周期才触发 RN 初始化。在 Compose 架构下，从路由跳转到页面 Resume，中间经历了一系列生命周期流转，白白浪费了近 400ms。

方案：把初始化时机提前到页面创建时立即触发，而不是等到 Resume。

指标	优化前	优化后	提升
冷启动	1.78s	1.53s	14%
热启动	1.10s	0.63s	43%

改动很小，但热启动直接砍掉将近一半的耗时。消除无意义的等待，往往是性价比最高的优化。

---

阶段 2：预加载基础资源 —— 提前备好弹药

问题：RN 启动时需要加载底层 Native 库和框架代码，每次都要做初始化和解压，累计约 50ms。

方案：在 App 启动时，后台异步完成这两步。用户打开 RN 页面时直接使用，跳过初始化和解压。

指标	优化前	优化后	提升
冷启动	1.53s	1.43s	6.5%
热启动	0.63s	0.63s	—

提升不大，但这是下一步的前置条件——基础资源就绪了，才能预创建完整容器。

---

阶段 3：容器复用 —— 创建一次，用无数次

问题：每次打开 RN 页面，即使是同一个页面的第二次打开，仍要走一遍完整的容器创建流程（~200ms）。同样的容器，为什么要反复创建？

方案：引入容器缓存机制。首次打开正常创建，后续打开直接复用已有容器，跳过创建步骤。

我们设计了两种策略：

• 复用模式：同一个业务包共享同一个容器，性能优先
• 隔离模式：每次创建独立容器，兼容性优先

缓存按页面维度管理，页面销毁时自动清理。

指标	优化前	优化后	提升
冷启动	1.43s	1.43s	—
热启动	0.63s	0.33s	47.6%

热启动从 0.63s 降到 0.33s，已经非常接近原生体验。但冷启动呢？首次打开仍然要创建容器。

---

阶段 4：容器预加载 —— 用户还没点，容器已就绪

问题：容器复用解决了「二次打开」的问题，但首次打开仍是瓶颈。核心矛盾：容器创建发生在用户点击之后，而创建本身需要 200ms。

方案：在 App 启动时，后台异步预创建完整的 RN 容器（包括容器实例、运行环境、业务代码），存入预热缓存。用户首次打开时直接消费。

核心思路：把容器创建的 200ms 从用户的关键路径移到 App 启动后的后台异步线程，用户无感知。

指标	优化前	优化后	提升
冷启动	1.43s	0.8s	44%（累计 55%）
热启动	0.33s	0.33s	—

---

四、踩过的坑：容器复用没有想象中简单

容器复用和预加载的方案设计不难，但落地过程中遇到了一系列工程问题。这些坑如果提前知道，可以少走很多弯路。

坑 1：返回键失效

现象：使用预加载容器后，用户按返回键没反应。

根因：容器创建时需要绑定「返回键回调」。预加载时没有页面上下文，传入的是空回调。而容器创建后，这个回调不可修改。

解法：利用容器的页面恢复机制，每次页面可见时动态重新注入返回键回调。

教训：预加载场景下，所有需要页面上下文的回调都需要延迟绑定。

---

坑 2：路由参数错误

现象：从页面 A 跳到 RN 页面 B，传了 userId=123，但 RN 侧拿到的是上次的 userId=456。

根因：容器复用时，参数是第一次创建时注入的。复用容器不会重新注入。

解法：引入全局参数管理器，每次页面可见时刷新当前参数。RN 侧通过 Bridge 获取最新参数，而不是依赖容器创建时的注入。

关键：在代码加载之前刷新参数，确保 RN 侧拿到的一定是最新值。

---

坑 3：热更新后代码不生效

现象：发了新版 Bundle，用户打开仍然是旧代码。

根因：容器复用时，代码是首次加载时注入的，复用容器不会重新加载。

解法：引入热更新标记机制。热更新完成后打标记，下次打开时检查标记，如果有则重建运行环境并加载新代码。

---

坑 4：预加载时 Native Module 缺失

现象：预加载的容器缺少某些 Native 能力，RN 侧调用报错。

根因：部分 Native Module 需要运行时回调（如关闭页面、弹窗），预加载时没有这些回调，所以没注册。

解法：引入统一的能力工厂。预加载时全量注册所有 Module，回调先用空占位。运行时复用同一份配置，将空回调替换为真实回调。

---

坑 5：全局状态清理问题

现象：退出 RN 页面再进入，某些数据丢失。

根因：容器复用后，退出页面不会销毁容器。但部分 Native 组件在视图卸载时清理了全局变量，再次进入时不会重新赋值。

解法：将状态从全局下沉到视图实例中。每个视图创建时初始化自己的状态，卸载时清理自己的状态，互不影响。

原则：视图创建和视图卸载必须成对出现，状态跟随视图生命周期。

---

坑 6：多语言不刷新

现象：用户切换国家/语言后，RN 页面的文案没有跟着切换。

根因：容器复用后，国际化模块不会主动刷新语言。

解法：与路由参数类似，将语言信息也注入到当前容器。RN 侧每次页面可见时通过 Bridge 获取最新语言，并重置国际化模块。

---

规律总结

容器复用的本质是把「一次性初始化」变成「多次复用」。所有依赖「一次性初始化」的逻辑，都需要改造为「每次使用时刷新」。

---

五、最终效果

性能数据

指标	优化前	优化后	提升幅度
冷启动	1.78s	0.8s	55%
热启动	1.10s	0.33s	70%

优化路径

耗时分布变化

---

六、架构总览

分层架构

缓存生命周期

---

七、总结与展望

核心经验

1. 数据先行。 搭建性能追踪工具后，才发现 379ms 的空等和 88% 的框架内部耗时。没有数据，优化就是盲人摸象。

2. 渐进式优化。 4 个阶段各有侧重，每步都有可量化的收益。不要试图一步到位，逐步迭代更靠谱。

3. 预加载的本质是「空间换时间」。 在用户不需要的时候（App 启动后的空闲期），提前做用户未来需要的事（创建容器），利用空闲时间为关键路径减负。

4. 复用的代价是复杂度。 容器复用带来了返回键、参数、热更新、全局状态、多语言等一系列问题。每一个都需要专门机制来应对。简单的方案背后是复杂的工程。

与 58RN 秒开方案的关系

两套方案是互补关系：秒开方案确保资源就绪，容器优化确保启动极速。叠加使用，才能实现从「秒开」到接近「毫开」的体验。

展望

• Hermes 引擎：预编译 JS 为 bytecode，大幅减少 JS 执行耗时。测试中 140ms 的页面降到 40ms，降幅 80%。
• 新架构（Fabric + TurboModules）：同步通信替代异步 Bridge，实现 Native Module 按需初始化。
• 智能预加载策略：基于用户行为预测，动态决定预加载哪些页面的容器，提高命中率。

性能优化没有终点，但每一步都在让用户的体验更好一点。

---

参考：58RN 页面秒开方案与实践 - 蒋宏伟