很多人一看到“React Native 八股文”这几个字，脑子里浮现的就是题海和背诵，但我在移动端团队和前端团队都面试过不少候选人，一个很明显的感受是：能把八股聊好的人，不是在背书，而是在讲系统设计。React Native 相关的面试题尤其如此，它横跨 JS 引擎、原生渲染、布局、网络、状态管理和工程化，任何一个“标准答案”背后都能拆出一串设计取舍。这篇指南我不想做成几十个问题的清单式问答，而是按一条完整链路把核心原理、启动优化、渲染性能、状态管理、新架构、多端适配和高频题答法串起来，帮你在准备面试或者刚接手 RN 项目时，能直接把理解用到实践里。
1. 为什么八股文绕不开“桥”：RN 的核心模型可能和你想的不一样
1.1 从单线程心智到多线程协作
很多人被问到“React Native 是单线程还是多线程”时，嘴巴比脑子快，直接说“JS 是单线程的”。这个答案在浏览器环境里基本成立，但在 React Native 里只能算答对了一半。RN 应用里至少有三类线程在同时干活：JS 线程负责业务逻辑、状态更新、组件 diff；UI/原生线程负责原生视图的渲染、手势响应和屏幕刷新；在老架构里还有专门的 Shadow 线程，用来计算布局和管理 shadow tree；新架构里 Fabric 把渲染和布局流程做了整合，但多线程协同的本质没有变。
面试官问这个题，通常不是想听“单线程”这三个字，而是想看你能不能把 JS 引擎和原生渲染框架分清楚。React Native 不是 WebView 套壳，JS 代码跑在 JavaScriptCore 或 Hermes 这个独立的 JS 引擎里，组件最终会被映射成 UIView、Android View 这种真实的原生视图。业务代码确实跑在单线程的 JS 引擎上，但整个 RN 应用是由多线程协作驱动的。这个模型带来一个非常实用的推论：JS 线程卡住时，页面不一定掉帧，但事件处理和状态更新都会延迟，用户会感觉“点了没反应”；UI 线程卡住时，才是真正意义上的掉帧。很多调优问题一旦把这两件事分开，排查范围就会小很多。
1.2 桥接、异步边界和“不掉帧”的代价
老架构里最常考的点就是“桥（Bridge）”。你需要说清楚：JS 线程和原生线程之间不是函数直接调用，而是通过一个异步消息队列传递序列化后的调用。每次 JS 调用原生方法时，会先把参数序列化成 JSON，经过 Bridge 批量传给原生侧；原生侧的回调也会排队返回 JS 线程。这就是为什么 setState 之后不能立刻拿到原生模块的返回值，为什么某些原生方法调用存在性能损耗，为什么在 JS 和 Native 之间频繁传大量数据是大忌。
面试时我建议不要只讲“桥是异步的”，而是补一句“这是为了不掉帧”。UI 线程最怕被 JS 长任务阻塞，如果所有通信都做成异步、批量，UI 线程就可以在每一帧的空隙处理消息，渲染保持流畅。代价是这样一层异步边界让数据不是实时同步的，组件生命周期里拿到某些状态的时机也需要仔细推敲。把这个取舍讲清楚，面试官就会知道你理解的是一个分布式消息系统，而不是一个简单的 API。简单整理一下：
| 线程/角色 | 主要职责 | 常见瓶颈 |
|---|---|---|
| JS 线程 | 执行业务逻辑、状态更新、diff | 长任务阻塞导致交互延迟 |
| UI/原生线程 | 原生视图渲染、手势、屏幕刷新 | 掉帧、卡顿、原生耗时操作 |
| Shadow 线程（老架构） | 布局计算、shadow tree | 复杂布局计算耗时 |
| 原生模块线程池 | 耗时的原生模块调用 | 线程竞争、资源竞争 |
2. 启动白屏：一道面试题背后藏着一整条性能链路
2.1 冷启动时间到底花在哪
“React Native 启动白屏”是搜索热词，也是面试题。想回答好这个问题，不能只说“加个 Splash”，得先把冷启动链路拆开。RN App 冷启动大致要经过：App 进程启动、系统加载主 Activity 或 ViewController、初始化原生环境、创建 JS 引擎、加载 JS Bundle、执行 JS 入口、React 完成首屏协调渲染。白屏期基本发生在“原生容器已经就绪，但 JS 还没执行完首帧”的阶段，用户看到的 root view 是原生的空白背景。
如果把时间再量化一下：Bundle 从磁盘读取或网络下载可能占 100~500ms，JS 引擎初始化需要 50~200ms，执行整个 JS Bundle 在调试包上甚至可能到几秒钟，首屏组件树又要等 React 完成协调才会显示。老架构下 JS Bundle 需要在运行时解析和编译，而 Hermes 出现之后可以先在打包时编译成字节码，启动时间才能大幅下降。面试时你能把这条链路说出来，就已经比只会说“用 Hermes 就好了”的人高一个层次。
2.2 一线项目常用的白屏优化手段
真正在项目里做首屏优化，手段是组合拳，不是单个开关能解决的：
- 启用 Hermes 并预编译字节码：Hermes 不仅执行快，还支持打包阶段生成 hbc 字节码，减少运行时解析开销。
- 拆分 Bundle：首屏只加载核心包，其他业务模块按路由懒加载。很多团队会把第三方库、业务代码、基础框架拆成多份。
- 离线包或本地内置：至少把首屏 Bundle 内置到 App 资源目录，不要依赖远程下载。远程 bundle 适合热更新，但绝不能成为冷启动路径上的硬依赖。
- 原生启动屏兜底：在 JS 执行完成之前，用原生启动屏展示品牌或加载态，避免用户盯着白屏。
- 首屏组件减负：第一个页面只渲染必要组件，不要在首屏发起十几个并行请求，图片先占位，等页面 ready 后再填充。
- 新架构的渲染调度：Fabric 在部分场景下支持同步渲染和更好的跨线程调度，对首屏可见时间有帮助。
这里有个实践教训：不要为了“启动快”把所有代码都塞进内置 Bundle，安装包体积会爆炸，内存占用也会升高。正确做法是区分首屏资源和非首屏资源，核心链路内置，次级模块再走按需加载。
3. 组件、列表与渲染性能：别再把“虚拟DOM优化”挂嘴边
3.1 从 React.memo 到重新渲染的“爆炸半径”
八股文里常问“React 中如何避免不必要的渲染”，很多人张口就是 shouldComponentUpdate、React.memo、useMemo。这个答案本身没错，但面试官一定会追问：为什么 React.memo 只做浅比较？因为 React 只能通过 props 的引用是否变化来判断要不要跳过渲染。如果你的父组件每次 render 都新建内联函数、新建对象字面量，memo 就是摆设。这个问题背后的本质，是数据引用的稳定性。
在真实项目里，我看到过太多团队把 useCallback 用滥，盲目标注依赖数组，结果闭包捕获了旧数据，状态更新不到新页面。回答“渲染性能优化”时，核心思路是在“爆炸半径”边缘做隔离。只要高频更新的组件尽量靠近叶子节点，就不会让整棵树重新 diff。移动端尤其要注意这一点：RN 页面上几十个原生视图的创建和更新成本远高于 Web DOM，每一次无意义的 render 都可能引发原生视图属性的同步，累积起来就变成卡顿。
3.2 FlatList 配置表和离屏渲染边界
FlatList 是 React Native 面试绕不开的组件，但很多面试者只知道“用 FlatList 代替 ScrollView”。真实项目里，FlatList 默认配置在数据量小的时候没问题，一旦列表上千条，就会遇到首次加载慢、滑动卡顿、内存飙升。需要记住几个关键属性：
| 属性 | 作用 | 实践经验 |
|---|---|---|
| initialNumToRender | 首批渲染条数 | 不要太大，默认 10 左右足够 |
| windowSize | 渲染窗口大小 | 调小可以减少内存，但滑动可能出现白块 |
| maxToRenderPerBatch | 每批最多渲染条数 | 太大首帧卡，太小滚动加载慢 |
| updateCellsBatchingPeriod | 渲染批次间隔 | 与 maxToRenderPerBatch 配合调 |
| removeClippedSubviews | 移除屏幕外组件 | 长列表可开启，但注意 iOS 兼容性 |
| getItemLayout | 提供 item 固定高度/偏移 | 必须给，能避免动态测量开销 |
这里有一个很实用的经验：如果列表项高度是固定的，一定要提供 getItemLayout，FlatList 可以直接计算滚动偏移，跳过动态测量。如果高度不固定，尽量把需要动态测量的内容控制在单个 cell 内部，不要让整行的高度由异步图片加载或嵌套列表决定。key 也要保持稳定，不要用数组 index 当 key，列表项内部有输入框或滚动位置时会出各种诡异问题。
离屏渲染是另一个容易被忽略的八股点。iOS 上阴影、圆角、mask 组合不当会给 GPU 造成压力，RN 里尤其容易在图片卡片上踩坑。建议优先使用预切圆角图、避免在滚动列表里堆大量阴影和半透明视图，这会直接影响滑动的帧率。
4. 状态管理和数据流：面试官真正想听的架构判断
4.1 Context、Redux、Zustand 的取舍
React Native 面试里关于状态管理的套路答案，通常就是“用 Redux，因为单向数据流、可预测”。但这两年面试官已经开始追问：你项目里见过 Redux 的什么痛点？为什么有人觉得不需要 Redux？这时候你要是只会背概念，很容易被问住。
我一般会从边界讲起。Context 适合低频状态，比如主题切换、登录态，不适合高频业务状态，因为 provider value 一改，所有消费组件都会重渲染，而且缺少中间件、DevTools、持久化这些配套能力。Redux 的价值是约束：统一 action、reducer、中间件，让状态变更可追踪、可回放。代价是模板代码多，异步逻辑要额外引入 thunk 或 saga，团队维护成本高。Zustand 这类轻量库在 RN 社区里越来越流行，核心是外部 store 加 selector 订阅，不限死数据更新方式，哪个组件订阅了哪一段数据，就只重渲染那个组件。
实际项目里我的建议是：全局服务数据用 Redux 或 Zustand 都行，关键是团队约定要一致；页面临时状态用 useState/useReducer；跨页面共享但更新频率低的状态用 Context。面试时不要捧一个踩一个，讲清楚每种工具的适应场景，比站队更有说服力。
4.2 跨端数据同步和不可变数据带来的心智负担
React Native 的状态管理比 Web 多一层复杂度：它要跨 JS 和原生。比如你在 Redux 里存了一张图片 URL，业务上希望原生侧提前做缓存，那就需要写原生模块监听状态变化，再调用原生缓存逻辑。再比如列表更新时，reducer 返回了一个新数组，即使只改了一个 item，FlatList 也会拿到新的数据源引用，需要靠 key 和 memo 避免整列表重渲染。
这里可以讲一个面试加分点：不可变数据不是单纯为了“高级”，而是为了让引用比较变得廉价。用 Immer 也可以，但要知道 draft 机制在 JS 引擎里多了一层 Proxy 开销，在海量数据频繁更新时，可能比手写展开慢。还有一个很常见的坑：Redux 里的数据要传给原生模块时，必须确保是可序列化的值。Date、Map、函数过桥时会被处理掉，很多团队把 Date 对象存进 Redux 后再传给原生模块，时间显示就出问题了。面试时能把这个边界讲出来，面试官会认为你真的在移动端写过跨端业务逻辑，而不是只在网页上写 TodoList。
5. 新架构、OpenHarmony 和多端适配：今年的八股文已经变了
5.1 新架构不是“换了个桥”而是“拆了桥”
React Native 0.7x 之后新架构全面铺开，八股文题库也必须更新。老架构的核心是 Bridge，新架构的核心是 JSI、Fabric、TurboModules 和 Codegen。JSI 让 JS 引擎和原生代码之间可以直接持有 C++ 对象引用，不再需要完整 JSON 序列化；Fabric 重构了 Shadow Tree 和渲染流程，UI 更新可以跨线程调度；TurboModules 让原生模块按需加载，不再在 App 启动时初始化全部原生模块；Codegen 则根据 JS 规范自动生成原生和 JS 两端的类型代码，减少手写通信层的模板代码，也降低类型不一致导致的崩溃。
面试可以这样答：新架构不是简单地把桥从异步改成同步，而是拆掉了“桥”这个中间人，用 JSI 在 JS 和原生之间建立更直接的通信层。注意不要把“同步”理解成没有代价，JSI 调用依旧要考虑跨线程成本，只是大量消除了序列化和数据拷贝。很多团队至今还在旧架构上，不是因为新架构不好，而是因为老的水合库和原生模块没有完全兼容。这也是一个非常实际的面试题答案：为什么你们项目还没启用新架构？不是不会，而是需要评估原生依赖生态和团队排期。
5.2 多端适配时代的能力边界
React Native 从诞生起就是“Learn once, write anywhere”。现在的团队不仅跑 iOS、Android，还希望适配 OpenHarmony、Windows、macOS 等平台，搜索引擎里“react native for openharmony”热度很高，说明多端适配是真实需求。面试官问“RN 能不能一套代码到处跑”时，最稳的回应是：RN 确实是跨端方案，但不是“一套代码所有平台完美”，平台差异层依然存在。iOS 的权限逻辑、Android 的返回键处理、OpenHarmony 的分布式能力，都需要通过原生模块或社区库做适配。
这里有一个实操经验：适配一个新平台，最先要去确认这个平台是否支持 JSI 和 Fabric 的最小能力集，然后再看社区组件覆盖率。如果核心页面依赖大量自定义原生模块，跨端成本会急剧上升。RN for OpenHarmony 是生态发展的方向之一，但投入前要评估组件库、构建链、调试工具链是否满足自己项目的体量。多端不是目标，保持业务一致性和用户体验才是目标，把这一层判断说出来，面试官会看到你有架构思维。
6. 高频面试题的答法：从背答案到讲系统设计
6.1 为什么 setState 后不能马上拿到最新值
这道题考察的是 React 的状态批量更新机制。在 React 18 中，setState 不会立即修改 state，而是进入更新队列合并，在事件处理函数结束或异步回调里统一触发渲染。React Native 里由于 JS 和原生渲染之间还有一层异步调度，setState 后立刻读 this.state 很可能还是旧值。回答时建议分三层展开：第一层是 React 的批处理机制，第二层是 React Native 的渲染调度，第三层是如果要依赖新值，用函数式 setState 或在 useEffect 中获取，而不是依赖时序。
类似的高频题还有列表 key 为什么不能用 index，因为它破坏了组件身份，导致状态、滚动位置、焦点错乱。还有一个容易被忽略的问题：为什么原生事件监听要在组件卸载时清理？因为页面销毁后原生模块的监听可能还存活着，会造成内存泄漏和事件回调重复执行。这些题本身不复杂，但能在简历项目里找到对应场景，比单纯背定义有力得多。
6.2 原生模块怎么和 JS 通信、事件怎么传
原生模块通信是 React Native 工程化的核心八股。老架构下，JS 侧通过 NativeModules 获取原生模块，原生侧通过 RCT_EXPORT_METHOD 导出方法，原生调 JS 则通过事件发射器。新架构下推荐用 TurboModule 和 JSI 函数，还要在 Codegen 里声明接口。面试时可以把调用流程简洁地讲一遍：JS 发起调用，通信层传递，原生方法执行，回调或事件返回，JS 再处理。然后补一句“事件要区分高频和低频”。高频手势事件最好在原生侧做节流，低频业务事件走事件总线即可。
还有一个升级题：如果原生模块返回大量数据，怎么优化？答案不是“切到新架构”，而是从数据层减少传输：只传必要字段、分页返回、把大图路径传给原生而不是 base64、用文件缓存和数据库代替全量内存。这个思路在面试里是很大的加分项，因为它说明你能从性能和架构角度思考，而不是只会背 API。最后一个通用答法是：遇到不确定的问题，先说“我会先查日志、看配置、复现路径”，再补充可能的原因和侧重点，面试官要的是解决问题的路径，不是完美答案。
最后再分享一个我自己的经验：准备 React Native 八股文的时候，别按题目编号去背，而是按“一条用户操作会触发哪些链路”去讲。比如用户点了一个按钮，从事件响应、JS 状态更新、diff、shadow tree 到原生视图刷新，整条链路能讲顺，绝大多数高频题都能覆盖。我每次复盘知识点都会用三种方式表达：一句话说给产品经理听，三分钟讲给同事听，半小时把 Demo 写出来。能做到第三层，你就不需要担心面试官怎么问了。
