React Native面试复习指南：从Bridge到Fabric新架构核心机制解析

1. RN面试复习的底层逻辑与知识框架

1.1 为什么RN面试和纯前端面试完全不是一回事

很多人准备React Native面试的时候，习惯性地拿Web前端的八股文去套，结果一面就挂。我面过不少候选人，简历上写着“精通React Native”，一问到原生模块怎么通信、Bridge的批量更新机制、Fabric渲染器解决了什么问题，就开始含糊其辞。这不是候选人笨，而是复习方向从一开始就偏了。

RN面试的本质是什么？它考察的是一个跨端工程师的能力模型。这个模型至少包含四个维度：JavaScript/TypeScript语言功底、React框架理解深度、原生平台（iOS/Android）的基本认知、以及工程化与性能优化的实战经验。纯Web前端只需要关心浏览器这一个宿主环境，而RN开发者要同时面对JS线程、原生UI线程、Shadow线程三套体系的协作，任何一个环节出问题，表现到用户面前就是白屏、卡顿或者闪退。

所以复习RN面试，第一步不是刷题，而是建立正确的知识框架。你得清楚面试官问的每一个问题，背后对应的是哪个维度的能力。比如问“navigationcontainer使用”是在考察导航架构的理解，问“原生交互”是在考察跨线程通信的认知，问“性能优化”是在考察你对渲染管线的掌握程度。把这些维度理清楚，复习才不会东一榔头西一棒子。

1.2 面试官到底想听到什么

我做过面试官，也做过被面试的人，两边视角都体验过。面试官问一个问题的时侯，他心里其实有一张评分表。拿“RN页面跳转”这个问题举例，初级候选人回答“用react-navigation的navigate方法”就能过关，但高级岗位的面试官想听到的是：NavigationContainer在底层做了什么、路由状态是怎么管理的、深层链接怎么处理、页面栈的内存策略是怎样的。

再比如“性能优化”这个话题，如果你只回答“用FlatList代替ScrollView”“用memo避免重复渲染”，面试官会觉得你停留在API层面。真正加分的回答是：你能说清楚RN的渲染管线——JS线程生成虚拟DOM，通过Bridge（或者新架构下的JSI）把diff结果传给原生侧，原生侧再映射成真正的UIView或Android View。你能指出瓶颈通常出现在哪个环节，以及针对不同环节分别有什么手段。

这就是我常说的：面试复习不是背答案，而是理解答案背后的系统。你理解了系统，面试官怎么问你都接得住；你只背了答案，换个问法就露馅。

1.3 一份可复用的复习路线图

基于上面这个认知，我把自己复习RN面试的路线整理成四个阶段，你可以直接抄作业：

• 第一阶段：语言与框架基础。TypeScript的类型系统（泛型、条件类型、类型收窄）、React的Hooks原理（useState的批量更新、useEffect的依赖比较、useMemo和useCallback的适用边界）。这部分是地基，地基不牢后面全是空中楼阁。
• 第二阶段：RN核心机制。包括Bridge通信原理、新旧架构对比（Paper vs Fabric）、线程模型、组件生命周期与渲染流程、样式系统（Yoga布局引擎）。这部分是RN区别于Web前端的核心，也是面试区分度最高的地方。
• 第三阶段：工程化与性能。打包优化（Metro配置、Hermes引擎）、启动优化（Bundle拆分、预加载）、渲染优化（列表虚拟化、图片缓存策略）、原生交互（TurboModule、JSI）。这部分决定你能不能拿高薪。
• 第四阶段：项目复盘与场景题。把你做过的项目重新梳理一遍，每个技术选型都要能说出“为什么选A不选B”，每个踩过的坑都要能讲出“怎么发现、怎么定位、怎么解决”。

这四个阶段走下来，大概需要三到四周的集中复习时间。如果你基础好，两周也能覆盖；如果原生部分比较薄弱，建议多留一周补iOS和Android的基础概念。

2. 核心机制深度拆解：从Bridge到新架构

2.1 Bridge通信原理与它的历史局限

RN最核心的设计之一就是Bridge。理解Bridge是理解RN一切性能问题的起点。

简单来说，RN的运行时有三条主要的线程：JS线程负责执行JavaScript代码和React的渲染逻辑；原生UI线程（iOS的Main Thread、Android的UI Thread）负责真正的视图渲染和用户交互响应；Shadow线程负责布局计算（Yoga引擎在这里工作）。这三条线程之间不能直接共享内存，所有通信都要通过Bridge来传递序列化的消息。

Bridge的工作方式是异步、批量、序列化的。JS侧调用一个原生方法，消息先被序列化成一个JSON-like的结构，放到消息队列里，然后批量传递给原生侧。原生侧处理完再异步把结果传回来。这个设计的好处是解耦——JS和原生互不干扰，各自跑各自的。但坏处也很明显：通信有延迟，而且高频通信会造成队列拥堵。

我举个实际场景你就明白了。你在做一个列表滚动加载的页面，用户快速滑动的时候，JS线程要不断计算新出现的数据项，然后通过Bridge告诉原生侧“渲染这个、渲染那个”。如果Bridge消息太多，原生侧处理不过来，用户看到的就是白屏或者卡顿。这就是为什么RN的列表性能一直是老大难问题。

面试中如果被问到“RN为什么卡”，你能从Bridge的异步批量特性讲起，再结合具体场景分析，面试官对你的评价会直接上一个档次。

2.2 新架构Fabric、TurboModule与JSI

为了解决Bridge的瓶颈，RN团队推出了新架构，核心是三样东西：JSI（JavaScript Interface）、TurboModule、Fabric。

JSI是基础。它让JavaScript可以直接持有C++对象的引用，并且同步调用C++方法。这意味着JS和原生之间的通信不再需要序列化，也不需要异步等待。你可以把它理解成在JS和原生之间修了一条直达高速，而不是原来那条需要中转的普通公路。

TurboModule是基于JSI的新原生模块方案。老的原生模块通过Bridge异步调用，新的TurboModule支持同步调用，而且可以懒加载——用到的时候才初始化，不用一开始就全部注册。这对启动性能是很大的提升。

Fabric是新架构的渲染器。它把原本分散在三条线程的渲染逻辑重新组织，让布局计算可以并行执行，而且支持优先级调度——用户正在交互的动画优先级最高，后台的数据更新优先级最低。这就解决了老架构下“一个慢渲染阻塞整个UI”的问题。

面试中关于新架构的高频问题包括：JSI和Bridge的本质区别是什么？TurboModule怎么实现同步调用？Fabric的渲染管线是怎样的？这些问题你不需要答得面面俱到，但至少要说清楚“新架构解决了什么问题”和“大致是怎么解决的”。

2.3 线程模型与渲染流程的完整链路

把上面这些串起来，一个RN页面的完整渲染流程是这样的：

1. JS线程执行React代码，生成虚拟DOM树。
2. React的Reconciler计算出需要更新的差异（diff）。
3. 差异通过Bridge（老架构）或JSI（新架构）传递给原生侧。
4. Shadow线程用Yoga引擎计算布局（每个节点的位置和尺寸）。
5. 布局结果传给原生UI线程，映射成真正的原生视图。
6. 原生UI线程完成渲染，用户看到界面。

这个链路里，任何一个环节变慢都会导致用户感知的卡顿。JS线程慢，通常是代码逻辑太重或者计算量太大；Bridge拥堵，通常是通信太频繁；Shadow线程慢，通常是布局层级太深；原生UI线程慢，通常是视图数量太多或者有复杂的离屏渲染。

我复习这部分的时候，会拿一张纸把这个链路画出来，然后在每个环节旁边标注“常见瓶颈”和“优化手段”。这个方法很土，但非常有效，因为面试的时候你可以顺着这条链路去分析问题，而不是零散地蹦出几个优化点。

3. 高频考点实操解析与代码级细节

3.1 NavigationContainer与页面跳转的完整实现

NavigationContainer是react-navigation v5之后的核心组件，它管理着整个App的导航状态。面试中关于它的高频问题包括：它和老的createAppContainer有什么区别？路由状态怎么持久化？深层链接怎么配置？

先看基本用法：

import { NavigationContainer } from '@react-navigation/native'; import { createNativeStackNavigator } from '@react-navigation/native-stack'; const Stack = createNativeStackNavigator(); function App() { return ( <NavigationContainer onStateChange={(state) => { // 路由状态变化时触发，可以在这里做埋点或持久化 console.log('Navigation state changed:', state); }} linking={{ prefixes: ['myapp://', 'https://myapp.com'], config: { screens: { Home: 'home', Detail: 'detail/:id', }, }, }} > <Stack.Navigator initialRouteName="Home"> <Stack.Screen name="Home" component={HomeScreen} /> <Stack.Screen name="Detail" component={DetailScreen} /> </Stack.Navigator> </NavigationContainer> ); }

这里有几个面试常问的点。第一，NavigationContainer必须包裹在导航器的最外层，而且整个App只能有一个。第二，linking配置决定了深层链接怎么映射到具体的页面和参数。第三，onStateChange可以用来做路由埋点或者状态持久化。

页面跳转和传参的写法：

// 跳转并传参 navigation.navigate('Detail', { id: 123, title: '商品详情' }); // 在目标页面接收参数 function DetailScreen({ route, navigation }) { const { id, title } = route.params; // ... }

面试中经常被追问的是：navigate和push有什么区别？navigate会先查找栈中是否已有同名页面，有就跳过去，没有才新建；push则总是新建一个页面。这个区别在需要避免重复页面的场景下非常重要。

3.2 原生交互：从调用电话功能说起

“rn调用电话功能”是一个很典型的原生交互面试题。它考察的是你对Linking API和原生模块调用的理解。

最简单的实现方式是用Linking：

import { Linking } from 'react-native'; const makePhoneCall = (phoneNumber: string) => { const url = `tel:${phoneNumber}`; Linking.canOpenURL(url) .then((supported) => { if (supported) { return Linking.openURL(url); } else { console.warn('设备不支持拨打电话'); } }) .catch((err) => console.error('拨打电话失败:', err)); };

但面试官可能会追问：如果我想在App内部完成拨号而不跳转到系统拨号盘呢？这就需要用原生模块了。iOS侧用CTCallCenter或者UIApplication.shared.open，Android侧用Intent.ACTION_CALL。你需要写一个TurboModule来封装这些原生能力，然后在JS侧调用。

这里的关键知识点是：Linking适合调用系统能力（电话、短信、邮件、浏览器），而自定义原生模块适合需要深度集成或者需要回调原生事件的场景。面试中能把这个边界说清楚，说明你对RN的能力边界有清晰的认知。

3.3 大文件上传与图片选择器的工程实践

“rn react-native-multiple-image-picker 支持大视频的组件”这个热词反映的是一个真实的工程痛点：RN的图片/视频选择器在处理大文件时经常出问题——内存溢出、上传超时、进度无法追踪。

我实际项目中的做法是这样的：

import { launchImageLibrary } from 'react-native-image-picker'; const pickLargeVideo = async () => { const result = await launchImageLibrary({ mediaType: 'video', videoQuality: 'medium', // 不要用high，大视频会爆内存 selectionLimit: 1, maxWidth: 1920, maxHeight: 1080, }); if (result.assets && result.assets[0]) { const asset = result.assets[0]; // 分片上传 await uploadInChunks(asset.uri, asset.fileSize); } }; const uploadInChunks = async (uri: string, totalSize: number) => { const CHUNK_SIZE = 1024 * 1024 * 2; // 2MB一片 const totalChunks = Math.ceil(totalSize / CHUNK_SIZE); for (let i = 0; i < totalChunks; i++) { const start = i * CHUNK_SIZE; const end = Math.min(start + CHUNK_SIZE, totalSize); // 读取分片并上传 await uploadChunk(uri, start, end, i, totalChunks); } };

这里有几个实操心得。第一，videoQuality不要设成high，否则大视频在低端机上直接OOM。第二，分片上传是必须的，单片上传大文件在移动网络下几乎必然失败。第三，要处理断点续传——记录已上传的分片索引，下次从断点继续。

面试中如果被问到文件上传，你可以从“选择器配置”“分片策略”“断点续传”“进度反馈”四个层面去回答，基本就覆盖了工程实践的核心。

4. 性能优化与工程化的实战方法论

4.1 启动性能优化的完整链路

RN的启动性能是面试必问，也是实际项目中最影响用户体验的环节。启动过程大致分为几个阶段：原生容器初始化、JS Bundle加载与解析、React根组件挂载、首屏渲染完成。

每个阶段都有对应的优化手段：

原生容器初始化阶段，可以做的是延迟初始化非必要的原生模块。比如推送SDK、统计SDK这些，不要在主线程初始化，放到后台线程或者等首屏渲染完再初始化。

JS Bundle加载阶段，核心手段是拆包和预加载。把Bundle拆成基础包和业务包，基础包在App启动时就加载，业务包按需加载。Hermes引擎的字节码预编译也能显著减少解析时间。

React根组件挂载阶段，减少首屏的组件层级和渲染量。首屏只渲染可见区域的内容，其他内容延迟渲染。

首屏渲染阶段，图片用占位符，数据用骨架屏，避免白屏等待。

我实测过一个中等复杂度的RN App，做了上述优化之后，冷启动时间从3.2秒降到了1.8秒左右。这个提升在低端安卓机上更明显，能从5秒多降到3秒以内。

4.2 渲染性能：列表、图片与动画

渲染性能的三大战场是列表、图片和动画。

列表优化的核心是虚拟化。FlatList和SectionList都内置了虚拟化能力，但要用好需要配置几个关键参数：

<FlatList data={data} renderItem={renderItem} keyExtractor={(item) => item.id} initialNumToRender={10} maxToRenderPerBatch={5} windowSize={7} removeClippedSubviews={true} getItemLayout={(data, index) => ({ length: ITEM_HEIGHT, offset: ITEM_HEIGHT * index, index, })} />

getItemLayout是最重要的优化——它让列表不需要测量每个item的高度就能知道总高度和滚动位置，大幅减少布局计算。removeClippedSubviews在安卓上效果明显，但iOS上可能有副作用，需要实测。

图片优化的核心是缓存和尺寸控制。用react-native-fast-image替代默认的Image组件，它支持内存缓存和磁盘缓存，而且能自动处理图片的降采样。服务端返回图片URL的时候，尽量带上尺寸参数，不要下载原图再缩放。

动画优化的核心是尽量用原生驱动。Animated的useNativeDriver: true能把动画放到原生UI线程执行，不受JS线程卡顿影响。但注意，不是所有属性都支持原生驱动，transform和opacity支持，width和height不支持。

4.3 工程化：从Metro配置到CI流水线

工程化是区分初级和高级RN开发者的重要维度。面试中常问的工程化话题包括：Metro打包配置、多环境管理、代码分割、CI/CD流水线。

Metro是RN的默认打包工具。常见的优化配置包括：

// metro.config.js module.exports = { transformer: { getTransformOptions: async () => ({ transform: { experimentalImportSupport: false, inlineRequires: true, // 延迟加载模块，加快启动 }, }), }, resolver: { assetExts: ['png', 'jpg', 'ttf', 'mp4'], }, };

inlineRequires是一个很实用的配置，它把模块的require延迟到真正使用的时候，能显著减少启动时的模块加载量。

多环境管理通常用react-native-config或者自定义的构建脚本，把开发、测试、生产环境的API地址、密钥等配置分离。

CI流水线方面，RN项目的构建比纯前端复杂，因为涉及原生代码的编译。常见的做法是用Fastlane管理iOS和Android的构建流程，用Jenkins或GitHub Actions做自动化触发。每次提交代码后自动跑Lint、单元测试、构建测试包，通过后自动分发到测试平台。

面试中聊工程化，不要只说你用了什么工具，要说清楚“为什么用这个工具”“解决了什么具体问题”“带来了什么可量化的收益”。比如“引入Fastlane之后，打包时间从30分钟降到了10分钟，而且不再需要手动配置证书”。

5. 常见问题排查与面试避坑指南

5.1 高频面试题速查表

我把RN面试中最高频的问题整理成了一张表，按难度分级，方便你对照复习：

这张表不是让你背答案，而是帮你查漏补缺。每个问题你都要能展开讲三到五分钟，而且能结合实际项目举例。

5.2 面试中容易踩的坑

我见过很多候选人，技术能力不差，但面试表现不好，问题往往出在几个地方。

第一个坑是只讲API不讲原理。面试官问“怎么做性能优化”，你回答“用FlatList、用memo、用Hermes”，这是罗列，不是回答。好的回答是：“性能优化要分场景，启动阶段主要靠拆包和预加载，渲染阶段主要靠虚拟化和减少重渲染，内存阶段主要靠图片缓存和对象池。我上个项目里，启动优化做了Bundle拆分，把冷启动从3秒降到了1.8秒。”

第二个坑是遇到不会的问题直接说不会。面试中遇到知识盲区很正常，但你可以展示你的思考过程。比如被问到“Fabric的渲染管线”，你如果不熟，可以说：“我对Fabric的具体实现细节了解不够深入，但我知道它是新架构的渲染器，主要解决老架构下渲染阻塞的问题。我的理解是它把布局计算和UI更新做了并行化处理，具体机制我回去会深入研究。”这样既诚实，又展示了学习意愿。

第三个坑是项目经历讲不清楚。面试官问你项目，不是想听你复述需求文档，而是想听你的技术决策和解决问题的过程。用STAR法则组织：背景是什么、任务是什么、你做了什么、结果是什么。重点在“你做了什么”和“为什么这么做”。

5.3 复习节奏与心态管理

最后聊点务实的。RN面试复习最忌讳的是贪多求全，什么都想看，结果什么都没看透。我的建议是以项目为主线，以问题为驱动。

你先把自己简历上写的项目重新过一遍，每个项目问自己三个问题：这个项目用了什么技术栈？为什么选这些技术？遇到了什么难题、怎么解决的？把这三个问题的答案写下来，就是最好的面试素材。

然后针对每个技术点，用“是什么、为什么、怎么用、有什么坑”四个维度去复习。比如复习Hermes，你要知道它是什么（JS引擎）、为什么用它（启动快、内存小）、怎么开启（在build.gradle和Podfile里配置）、有什么坑（不支持某些ES特性、调试方式不同）。

复习节奏上，建议每天集中复习两到三个主题，每个主题花一到两小时。上午看原理和文档，下午写代码验证，晚上整理笔记和模拟回答。周末做一次完整的模拟面试，找朋友或者自己对着镜子讲。

心态上，不要追求“全部都会”。RN的知识体系很庞大，没有人能全部精通。面试考察的是你的知识深度和学习能力，不是你的知识广度。遇到不会的问题，坦诚承认并展示思考过程，比硬编一个错误答案要好得多。

我在实际带团队和面试候选人的过程中发现，那些拿到好offer的人，往往不是知识面最广的，而是对自己做过的项目理解最深、对核心机制讲得最透的。所以复习的时候，与其泛泛地刷一百道题，不如把二十道核心题吃透，每道题都能讲出深度和细节。这个道理听起来简单，但真正做到的人不多。