如果你写 React Native 列表大概率第一反应就是FlatList data{...} renderItem{...} /一把梭。我也这么写过然后项目一上线真机一滑列表卡成 PPT冷启动进列表页白屏能清醒两秒——这种场面做 React Native 的同学应该都不陌生。问题基本就出在 FlatList 上数据一多、item 一复杂默认配置完全不够用。这篇文章不聊虚的直接讲我打磨过 N 轮的手写 FlatList 优化配置把每个参数为什么这么设、哪些坑不能踩、启动白屏和滚动卡顿怎么一起治全部拆开讲清楚。适合正在做列表页优化、被长列表性能折磨的人参考。1. 为什么 FlatList 需要手写优化配置1.1 默认配置只是及格线不是满分答卷FlatList 底层是 VirtualizedList它的默认参数偏向通用兜底initialNumToRender10、maxToRenderPerBatch10、windowSize21。意思是首屏先渲染 10 条滚动时每批最多补渲染 10 条可视区上下的渲染 buffer 各保留 10 个屏幕高度。这种配置对几十条的小列表完全没问题但对消息记录、商品流这类动辄几百上千条的长列表默认值大概率翻车。我用一个实际场景说明。假设消息列表每屏能显示 8 条首屏默认渲染 10 条其实是够的但如果你的 item 是 200px 高的卡片一屏可能只显示 3 条默认 10 条等于一下子渲染了三屏半的内容首屏耗时被白白拉高。反过来如果 item 很矮只有 30px一屏能显示 12 条默认 10 条又不够用户刚滑一下就开始补渲染白块闪现就来了。默认值管不了这么细致的业务差异必须手动调。手写两个字的关键就在这里——不是让你抛弃 FlatList 自己从零造轮子而是把优化配置显式写出来根据真实场景一参数一参数去抠不带任何差不多得了的心态。1.2 手写优化的边界该自己做的别指望框架很多人以为 FlatList 优化就是把几个参数填满就完事其实框架能帮你做的只有何时渲染、渲染多少、回收多少。真正耗性能的通常是 item 内部的组件逻辑图片解码、复杂布局、匿名函数、未 memo 的子组件——这些 FlatList 管不着。所以我说手写优化分两层。第一层是 FlatList 本身的显式配置比如getItemLayout、windowSize、removeClippedSubviews这些第二层是你自己的列表项组件要让它在数据未变时完全不参与重渲染函数引用保持稳定图片资源不要触发频繁解码。这两层缺一不可只调参数不改 item 组件效果会非常有限。还有一类边界是不要为了优化而优化。比如你的列表总共就 20 条渲染成本本来就可控这时候去压缩initialNumToRender反而可能让首屏看起来单薄。手写的前提是确实遇到了性能问题且定位到是 FlatList 引起的否则保持默认即可别给自己加戏。1.3 性能瓶颈的底层逻辑16.7ms 的预算怎么花屏幕刷新率 60fps 意味着每一帧只有约 16.7ms 的预算。用户滑动列表时每帧内要完成手势响应、JS 执行、组件 diff、Native 布局、绘制任何一个环节超时就会掉帧。在 React Native 里FlatList 的性能瓶颈通常分三层JS 线程每次状态更新触发组件树调度列表项越多、diff 越重JS 线程越忙。如果renderItem里用了内联箭头函数每次父组件 render 都会生成新引用导致所有可见 item 全量参与 diff。渲染/提交阶段JS 生成的 element 要交给 Native 层处理。旧架构走 Bridge 异步序列化数据量大时耗时明显新架构走 Fabric 的 JSI 直调效率提升不少但 UI 操作同步化后对 JS 侧代码质量的要求反而更高——写差了会直接卡 UI 线程。UI 线程层级过深、阴影、半透明叠加、图片未压缩都会拉低绘制帧率。FlatList 滚动本身只是触发渲染真正让帧率崩掉的往往是 item 布局太复杂。理解这三层之后再回头看待优化参数思路就清晰了initialNumToRender、maxToRenderPerBatch管的是 JS 线程和渲染阶段的单次工作量windowSize管的是渲染范围removeClippedSubviews管的是回收策略而 item 组件是否 memo、函数是否稳定管的是diff 范围。所有优化都是在 16.7ms 这个预算内做取舍。2. 核心优化参数逐项拆解2.1 initialNumToRender首屏渲染量要算不能全凭默认initialNumToRender决定首屏一次性渲染多少条直接影响启动白屏的时长。这是和react native 启动白屏这个热搜词关系最紧的一个参数。我建议不要拍脑袋先算一版拿真机的可视区域高度除以你 item 的预估高度得到首屏大概能显示多少条然后乘 1.2~1.5 作为初始值。比如可视高度 700px、item 高度 120px首屏约 5.8 条乘 1.3 之后取整 8initialNumToRender{8}就比较合理。这样首屏刚好铺满还给滑动留了一点 buffer不会一滑就露白。很多团队为了治白屏会把initialNumToRender压到 1 或 2我实测过效果其实很反直觉首屏只渲染两三条屏幕大部分区域是空的用户看到的不是更快而是残缺。数据到达后虽然会立刻补渲染但这个从残缺到完整的过程在视觉上更明显观感反而更差。正确做法是刚好铺满首屏不是尽量少渲染。2.2 maxToRenderPerBatch 与 updateCellsBatchingPeriod补帧节奏调校maxToRenderPerBatch默认 10指每次批量渲染最多新增多少 cellupdateCellsBatchingPeriod默认 50ms指两次批量渲染的最小时间间隔。这两个参数决定滚动时的补帧节奏。需要理解这套机制的行为用户滚动时VirtualizedList 会检测哪些 index 进入了渲染范围然后安排批量渲染。每次批量渲染数量不能超过maxToRenderPerBatch并且完成一批后至少要等updateCellsBatchingPeriod毫秒才能启动下一批。按默认值粗略估算50ms 一批、每批 10 个理想情况下一秒能补 200 个 cell但如果每个 cell 渲染要 8ms10 个就是 80ms已经超过一帧的 16.7msJS 线程会明显阻塞表现就是滚动卡顿。我的经验值是纯文本、轻量 card 的列表maxToRenderPerBatch可以放宽到 12~15updateCellsBatchingPeriod保持 50item 内部有图片、网络请求、稍复杂布局的列表压到 5~6配合updateCellsBatchingPeriod提高到 80~100ms。宁可让补渲染稍微慢半拍也不要让单帧 JS 执行时间爆炸。2.3 windowSize 与 removeClippedSubviews渲染范围的收与放windowSize默认 21意思是可视区上下各保留 10 个屏幕高度的内容作为 buffer。值越大快速滑动时越不容易出现白块但内存和渲染开销越高。值越小渲染范围越窄滚动越快但快速回滑时容易看到空白占位。针对不同场景我的设置习惯普通商品流、双列瀑布流11~15。既要保证快速滑动体验又不能太占内存。聊天记录/消息流5~7。这类列表方向单一、历史数据巨大把渲染范围压缩到很窄滚动速度提升明显。代价是往回快速翻的时候偶尔出现空白占位可接受。嵌套在 ScrollView 里的 FlatList能用但慎用windowSize 建议设很小否则滚出可视区的 cell 不回收内存压力很大。removeClippedSubviews是另一个容易踩坑的参数。它的作用是回收被裁剪出可视区的 Native 子视图Android 上默认 trueiOS 旧架构默认 false 且存在已知 bug可能引发内容错位、白块。如果你还在旧架构 iOS 上我强烈建议显式设为 false靠windowSize控制渲染范围如果你已经切到 New ArchitectureFabric这个参数行为稳定了很多可以放心开 true。2.4 getItemLayout 与 keyExtractor少踩两个经典坑如果列表的 item 高度固定必须手写getItemLayout。这是收益最高、但也最容易被忽略的优化点。不写它VirtualizedList 只能靠动态测量每个 cell 的高度来推算滚动位置测量是异步的滚动定位、跳转都受影响。写了它任何 index 的偏移量都能直接算出来跳转精确且无需等待测量。getItemLayout{(data, index) ({ length: ITEM_HEIGHT, offset: ITEM_HEIGHT * index, index, })}但这里有个前提item 高度必须真的固定。如果你写了getItemLayout但实际 item 高度因内容不同而变化滚动位置会全部错乱表现就是滚着滚着突然跳到错误的位置、或者某一段内容空白。这种 bug 特别隐蔽排查起来很费劲。keyExtractor的坑更常见。很多人直接不写或者用数组 index 当 key。FlatList 内部靠 key 来判断 cell 是否可以复用key 如果不稳定数据更新时复用逻辑会退化甚至出现内容错位。比如一个商品列表删除中间某条数据后如果 key 是 index后面的 item 都会被重新创建而不是复用性能损耗叠加视觉闪烁。经验上有 id 用 id没有就用组合字段生成${item.type}-${item.id}这种形式确保唯一且稳定。3. 实操一份可复用的手写 FlatList 优化配置3.1 从零手写 OptimizedFlatList 组件下面直接给一份我常用的封装可以当模板抄。注意这套配置针对固定高度 item 的长列表如果你的 item 高度动态去掉getItemLayout并按注释调整其他参数。import React, { useCallback } from react; import { FlatList, Platform, StyleSheet } from react-native; const ITEM_HEIGHT 120; // 改成你 item 的实际固定高度 function OptimizedFlatList({ data, renderItem, ListEmptyComponent, onEndReached }) { const getItemLayout useCallback( (_, index) ({ length: ITEM_HEIGHT, offset: ITEM_HEIGHT * index, index }), [] ); const keyExtractor useCallback((item) String(item.id), []); // 关键包一层 useCallback保证函数引用稳定 const optimizedRenderItem useCallback( (info) renderItem(info), [renderItem] ); return ( FlatList data{data} renderItem{optimizedRenderItem} keyExtractor{keyExtractor} getItemLayout{getItemLayout} initialNumToRender{8} maxToRenderPerBatch{8} updateCellsBatchingPeriod{50} windowSize{11} removeClippedSubviews{Platform.OS android} onEndReached{onEndReached} onEndReachedThreshold{0.3} ListEmptyComponent{ListEmptyComponent} showsVerticalScrollIndicator{false} / ); } export default OptimizedFlatList;业务侧使用的时候renderItem也要保持稳定const renderItem useCallback(({ item }) { return ListItem item{item} onPress{handlePress} /; }, [handlePress]); return OptimizedFlatList data{data} renderItem{renderItem} onEndReached{handleLoadMore} /;如果 item 高度不固定getItemLayout就不能用了。这时有两个替代思路一是把 item 内部结构做成固定高度比如标题最多两行、缩略图定高、内容区域弹性撑开整体高度恒定二是改成 section 列表section header 定高、行 item 定高通过简单的 section 遍历算出 offset仍然可以手写getItemLayout。实在做不到只能去掉它但要对scrollToIndex的定位不准有心理准备。3.2 列表项组件的 memo 化与图片细节FlatList 的配置只是外层item 内部才是大头。item 必须用React.memo包裹并且 item 内部的所有回调都要用useCallback否则一旦父组件状态更新所有可见 item 都会跟着重渲染。这里说一个很典型的反例renderItem里直接写ListItem item{item} onPress{() go(item.id)} /这个内联箭头函数每当父组件 render 都会生成新引用React.memo发现onPress变了memo 直接失效等于没写。正确写法const ListItem React.memo(function ListItem({ item, onPress }) { return ( Pressable onPress{onPress} style{styles.card} FastImage source{{ uri: item.thumb }} style{styles.thumb} / View style{styles.info} Text numberOfLines{1} style{styles.title}{item.title}/Text Text numberOfLines{2} style{styles.desc}{item.desc}/Text /View /Pressable ); });图片是列表性能的重灾区。Android 上图片解码发生在主线程滚动时新图片进入可视区会直接卡帧。我通常做三件事图片尺寸在服务端或 CDN 就压缩成列表需要的规格不做原图resizeMode cover这种慢性自杀fadeDuration{0}去掉图片加载淡入动画滚动场景下淡入反而加重卡顿感缓存策略显式声明像cache: force-cache至少在二次进入列表时不重新下载。如果列表里有视频封面、大图这种不可控资源建议用react-native-fast-image这类原生缓存库它能做磁盘缓存、内存缓存、请求优先级控制比系统Image在高强度滚动下稳很多。3.3 联动处理启动白屏从首屏数据到骨架屏启动白屏这个话题和 FlatList 的关系我之前说过分三层JS bundle 加载、数据加载、FlatList 首屏渲染。这里重点讲后两层因为这两层是和列表页代码直接相关的。数据加载方面最影响白屏感知的是页面初始化时有没有数据可渲染。如果页面启动后先发网络请求拿到数据之前列表是空的白屏时间就等于网络耗时。我建议有本地缓存就先渲染缓存数据然后后台刷新没有缓存就上骨架屏不要用ActivityIndicator居中转圈——一个撑满大半屏的转圈在视觉上就是白屏菊花观感并不好。骨架屏的实现不需要引入重型动画库。最稳的是用纯 View 加浅色背景模拟内容占位再配一个轻量的透明度循环动画这个动画只在骨架屏阶段运行数据到达后卸载。function Skeleton() { const opacity useRef(new Animated.Value(0.4)).current; useEffect(() { const loop Animated.loop( Animated.sequence([ Animated.timing(opacity, { toValue: 1, duration: 600, useNativeDriver: true }), Animated.timing(opacity, { toValue: 0.4, duration: 600, useNativeDriver: true }), ]) ); loop.start(); return () loop.stop(); }, [opacity]); return ( Animated.View style{[styles.skeletonWrapper, { opacity }]} {Array.from({ length: 6 }).map((_, i) ( View key{i} style{styles.skeletonCard} / ))} /Animated.View ); }FlatList 首屏渲染层面就是 2.1 里说的initialNumToRender不要过小也不要过大以刚好铺满首屏为目标。我实测过一个消息流页面把initialNumToRender从默认 10 压到 6首帧绘制时间降了约 30%配合骨架屏之后用户基本感知不到白屏间隙。这个数值根据不同屏幕和 item 高度要重新算不要照抄。还有一个容易忽略的点如果列表页初始化时需要从本地 SQLite 或 AsyncStorage 读大量数据尽量放到InteractionManager空闲期去读避免阻塞首帧渲染InteractionManager.runAfterInteractions(async () { const localData await loadLocalData(); setData(localData); });3.4 性能验证让优化结果有数据支撑配置调完不能光靠手感说好像顺了要有量化验证。我常用的几个手段打开 Metro 的 Performance Monitor开发菜单里选择 Show Perf Monitor看 JS FPS 和 UI FPS。在真机上快速滚动列表如果 JS FPS 低于 45明显有问题先查 item 组件是否 memo、函数引用是否稳定。用 Chrome DevTools 的 Performance 面板做火焰图分析启用 Debug JS Remote 后录制一段滚动操作观察火焰图里 React 相关渲染段是不是又长又集中。如果发现大量 React element creation基本就是 renderItem 没稳住。低端 Android 真机实测模拟器说明不了问题性能优化必须在低端机上验证。我一般拿一款千元 Android 真机快速滑到底再快速滑回顶部反复几次观察白块、卡顿和内存增长。performance.mark也可以用来测量关键节点比如进入列表页到首帧渲染结束的耗时performance.mark(list-start); // 数据到达后 performance.mark(list-first-frame); performance.measure(first-frame, list-start, list-first-frame);在分析阶段性优化效果时把每次调整前的测量数据记录下来对比起来很直观。3.5 分页加载与数据更新里的隐形坑长列表必然要分页。onEndReachedThreshold默认 0.5表示距离底部还有半屏距离时触发加载。这个值和每页数据量直接相关如果每页只有 5 条、每条约 120px一页内容约 600px比一屏还矮阈值设 0.5 会导致用户滑到底部还要等网络返回才有下一页体验上卡住了。这种场景阈值要设大一点比如 0.8~1提前触发预加载。如果每页数据很大一页好几屏阈值设 0.2~0.3 就够。分页请求还有一个经典 bugonEndReached在数据加载过程中会被反复触发。必须加锁用一个 ref 控制const loadingRef useRef(false); const handleLoadMore useCallback(async () { if (loadingRef.current) return; loadingRef.current true; try { const next await fetchNextPage(); setData(prev [...prev, ...next]); } finally { loadingRef.current false; } }, []);数据更新方面特别提醒extraData的坑。FlatList 默认只比较data的引用是否变化如果你修改了数组内部某个对象的属性、但没有替换整个数组引用FlatList 认为数据没变就不会重渲染。比如选中状态、收藏状态这类非数组结构变化的操作要传extraData{selectedId}或者维护一个refreshVersion状态传进去强制触发刷新FlatList data{list} extraData{selectedId} renderItem{renderItem} /还有一种情况是下拉刷新后新数据想滚动到顶部且不闪白块可以配合viewabilityConfig做克制viewAreaCoveragePercentThreshold: 50时一个 item 遮住半屏才回调onViewableItemsChanged避免快速滑动时回调风暴。4. 常见问题与排查技巧实录4.1 冷启动白屏先分清是没有数据还是渲染太重遇到冷启动白屏别急着改 FlatList先定位白屏出现在哪个阶段。最简单的方式是白屏期间看网络面板如果数据请求还没返回说明白屏归数据加载慢管FlatList 只能背一部分锅优先上缓存和骨架屏如果数据早就返回了屏幕还是白的再查是不是首屏渲染太重。前者按 3.3 的方法处理。后者的排查重点是initialNumToRender和 item 首屏组件复杂度。可以做个二分实验把列表改成只渲染一条固定 item看首屏速度是否明显提升。如果提升了说明问题出在首屏渲染量或 item 复杂度上如果没变化说明还有更前置的耗时点比如页面导航配置、全局状态初始化。另一个冷启动白屏的元凶是ListFooterComponent。有人会在 footer 里放图表、复杂统计这类重组件它虽然在列表底部但滚动接近底部时就会提前渲染占掉主线程时间。轻量化 footer或者改成一个简单的 ActivityIndicator能救回不少帧数。4.2 快速滑动白块按顺序排查三个原因白块blank cells在快速滑动时出现是最典型的 FlatList 优化失败场景。我的排查顺序是固定的先查removeClippedSubviews。如果在 iOS 旧架构上开了 true关掉重试。很多人白块问题其实就出在这里和windowSize没关系。再查windowSize是不是压得太低。低于 5 之后快速滑动回看时很容易露白。往 11~15 方向调看白块消失没有。最后查getItemLayout是否和真实 item 高度不匹配。高度写错的情况下滚动定位会失真某些 index 的内容会计算出错误的 offset表现就像一段内容凭空消失。如果三步都试过还是白块考虑是不是数据量过大且分页不及时。快速滑过未加载区域时FlatList 会先渲染空白占位等数据到了再填上。这种情况要把分页加载的触发时机提前或者让数据一次性给够——二选一取决于你的数据规模。4.3 滚动掉帧与内存上涨一个容易忽略的元凶滚动掉帧和内存上涨经常一起出现我遇到最多的情况是onViewableItemsChanged回调写得太重。有人会在 item 完全露出屏幕时触发曝光上报viewAreaCoveragePercentThreshold还设得很严格结果列表滚动时回调频繁触发每次回调里又带着setState把整条列表的渲染频率拉爆。曝光上报的正确姿势是把埋点数据先攒着离开页面或者用户停止滚动时批量上报。简单实现可以用InteractionManager.runAfterInteractions延迟执行const onViewableItemsChanged useRef(({ viewableItems }) { if (!viewableItems.length) return; pendingReports.current.push(...viewableItems.map(i i.item.id)); InteractionManager.runAfterInteractions(flushReports); }).current;另外内存只增不减还有可能是图片引用问题。列表页频繁进出时图片组件如果没有正确释放内存会一路涨到系统杀进程。检查一下图片组件是否在componentWillUnmount时取消了请求、清除了缓存引用如果用的是原生缓存库确认它的缓存策略是 LRU 且设置了maxCacheSize。4.4 排查工具清单与配置微调思路最后整理一份排查工具清单是我自己一直在用的组合排查项工具/命令重点关注指标JS FPS / UI FPSRN Dev Menu → Perf Monitor滚动时两者均不低于 45~50render 耗时Chrome DevTools Performance火焰图中 React 渲染段是否集中且长内存曲线Xcode Instruments / Android Studio Profiler列表循环滚动后内存是否持续上涨首屏耗时performance.markperformance.measure进入页面到首帧可用的耗时白块/错位低端 Android 真机快速滑动白块出现频率、内容是否错位关于配置微调我的思路是一次只动一个变量。FlatList 参数之间相互影响同时调两个参数出了问题你很难判断是谁的锅。比如第一次只调windowSize记录滚动表现和内存数据第二次只调maxToRenderPerBatch再记录最后组合验证。每一次优化都留一个可对比的测量结果比蒙着头试半天的效率高得多。FlatList 优化没有一套配置能通吃所有列表。聊天流、商品流、纯文本流这三类场景的最优参数都不一样我上面这套手写配置是起点模板最终要结合你本地的 item 高度、数据到达速度、用户滑动习惯去微调。而且我建议每次发版前都用低端 Android 真机狠狠滑几遍列表因为大多数白块和卡顿问题是在中端机上都很难复现、但在低端机上原形毕露的。调优这件事最终都要靠真机反馈来兜底。