很多人一看到“React Native 八股文”这几个字脑子里浮现的就是题海和背诵但我在移动端团队和前端团队都面试过不少候选人一个很明显的感受是能把八股聊好的人不是在背书而是在讲系统设计。React Native 相关的面试题尤其如此它横跨 JS 引擎、原生渲染、布局、网络、状态管理和工程化任何一个“标准答案”背后都能拆出一串设计取舍。这篇指南我不想做成几十个问题的清单式问答而是按一条完整链路把核心原理、启动优化、渲染性能、状态管理、新架构、多端适配和高频题答法串起来帮你在准备面试或者刚接手 RN 项目时能直接把理解用到实践里。1. 为什么八股文绕不开“桥”RN 的核心模型可能和你想的不一样1.1 从单线程心智到多线程协作很多人被问到“React Native 是单线程还是多线程”时嘴巴比脑子快直接说“JS 是单线程的”。这个答案在浏览器环境里基本成立但在 React Native 里只能算答对了一半。RN 应用里至少有三类线程在同时干活JS 线程负责业务逻辑、状态更新、组件 diffUI/原生线程负责原生视图的渲染、手势响应和屏幕刷新在老架构里还有专门的 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~500msJS 引擎初始化需要 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 固定高度/偏移必须给能避免动态测量开销这里有一个很实用的经验如果列表项高度是固定的一定要提供 getItemLayoutFlatList 可以直接计算滚动偏移跳过动态测量。如果高度不固定尽量把需要动态测量的内容控制在单个 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 返回了一个新数组即使只改了一个 itemFlatList 也会拿到新的数据源引用需要靠 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 写出来。能做到第三层你就不需要担心面试官怎么问了。 
长河君 · 2026/8/30 6:58:08 · 阅读 1.2k React Native 八股文：从桥到新架构的系统设计指南
很多人一看到“React Native 八股文”这几个字脑子里浮现的就是题海和背诵但我在移动端团队和前端团队都面试过不少候选人一个很明显的感受是能把八股聊好的人不是在背书而是在讲系统设计。React Native 相关的面试题尤其如此它横跨 JS 引擎、原生渲染、布局、网络、状态管理和工程化任何一个“标准答案”背后都能拆出一串设计取舍。这篇指南我不想做成几十个问题的清单式问答而是按一条完整链路把核心原理、启动优化、渲染性能、状态管理、新架构、多端适配和高频题答法串起来帮你在准备面试或者刚接手 RN 项目时能直接把理解用到实践里。1. 为什么八股文绕不开“桥”RN 的核心模型可能和你想的不一样1.1 从单线程心智到多线程协作很多人被问到“React Native 是单线程还是多线程”时嘴巴比脑子快直接说“JS 是单线程的”。这个答案在浏览器环境里基本成立但在 React Native 里只能算答对了一半。RN 应用里至少有三类线程在同时干活JS 线程负责业务逻辑、状态更新、组件 diffUI/原生线程负责原生视图的渲染、手势响应和屏幕刷新在老架构里还有专门的 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~500msJS 引擎初始化需要 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 固定高度/偏移必须给能避免动态测量开销这里有一个很实用的经验如果列表项高度是固定的一定要提供 getItemLayoutFlatList 可以直接计算滚动偏移跳过动态测量。如果高度不固定尽量把需要动态测量的内容控制在单个 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 返回了一个新数组即使只改了一个 itemFlatList 也会拿到新的数据源引用需要靠 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 写出来。能做到第三层你就不需要担心面试官怎么问了。