React Native 性能优化实战指南

启动、渲染、列表与内存的完整优化路线

---

一、性能优化从"量化"开始

很多团队优化性能靠"感觉"——觉得卡了就改一改，改完也不知道有没有用。这种拍脑袋式的优化往往事倍功半。

性能优化正确的第一步是先量化，再优化：搞清楚瓶颈在哪、优化前后差多少。没有数据支撑的优化都是盲目的。

本文按"分析 → 优化 → 验证"的思路，覆盖启动、渲染、列表、内存、图片五大维度，给你一套可落地的路线图。

---

二、先量化：性能分析工具

2.1 组件层：React DevTools Profiler

用于定位"哪些组件渲染慢、渲染次数多"：

🔹 打开 React DevTools 的 Profiler 面板，录制一次交互。

🔹 查看每个组件的渲染耗时和渲染次数。

🔹 优先优化渲染次数多、耗时长的组件。

2.2 JS 层：Hermes Profiler

Hermes 内置 CPU 分析能力，可以定位 JS 热点函数：

🔹 在 Chrome DevTools 或 Hermes Debugger 中连接。

🔹 录制 CPU Profile，找到耗时函数。

2.3 系统层：Systrace / Perfetto / Instruments

🔹 Android：Systrace / Perfetto 做系统级 trace，查看线程调度、渲染管线。

🔹 iOS：Instruments 分析 CPU、内存、渲染、能耗。

2.4 渲染层：why-did-you-render

一个开发期工具，能自动标记"不必要的重渲染"：

import whyDidYouRender from '@welldone-software/why-did-you-render'

if (__DEV__) {
  whyDidYouRender(React, {
    trackAllPureComponents: true,
  })
}

开发时在 Console 里就能看到哪些组件明明 props 没变却重新渲染了。

---

三、减少 Re-render：性能优化的基本功

React 的默认行为是"父组件重渲染，子组件也重渲染"。对于组件树很深的页面，这会造成大量浪费。

3.1 React.memo：组件级记忆

import { memo } from 'react'

// 只有当 props 变化时才重渲染
const TodoItem = memo(function TodoItem({ todo }) {
  return <Text>{todo.title}</Text>
})

3.2 useMemo / useCallback：值与函数记忆

import { useMemo, useCallback } from 'react'

// 昂贵计算只依赖 data 时才重算
const sorted = useMemo(() => expensiveSort(data), [data])

// 稳定函数引用，避免子组件因回调变化而重渲染
const handlePress = useCallback((id) => {
  // ...
}, [])

3.3 稳定 props 引用

这是最容易被忽视的一点。内联对象和箭头函数每次渲染都会创建新引用，导致 React.memo 失效：

// ❌ 每次渲染都是新对象/新函数，memo 形同虚设
<TodoItem style={{ padding: 8 }} onPress={() => handlePress(id)} />

// ✅ 提取到组件外或 useCallback/useMemo
<TodoItem style={ITEM_STYLE} onPress={handlePress} />

3.4 状态下沉

把 state 放到"最小必要"的组件里，缩小重渲染范围：

// ❌ 整个页面因一个输入框的 state 而重渲染
function Page() {
  const [text, setText] = useState('')
  return (
    <>
      <TextInput value={text} onChangeText={setText} />
      <ExpensiveList />  {/* 也被迫重渲染 */}
    </>
  )
}

// ✅ 把输入框拆成独立组件，state 下沉
function Page() {
  return (
    <>
      <SearchBox />
      <ExpensiveList />
    </>
  )
}

3.5 拆分组件

一个巨型组件既难维护也难优化。把大组件拆成职责单一的小组件，才能精细控制每个部分的重渲染。

---

四、列表性能：最容易被忽视的杀手

长列表是 RN 性能问题的重灾区。用错组件，几十条数据就能卡成幻灯片。

4.1 用 FlatList，别用 ScrollView

ScrollView 会把所有子元素一次性渲染，列表一长就崩。FlatList 采用虚拟化，只渲染可视区域：

// ❌ 长列表用 ScrollView = 灾难
<ScrollView>
  {items.map(item => <Item key={item.id} {...item} />)}
</ScrollView>

// ✅ 用 FlatList 虚拟化
<FlatList
  data={items}
  keyExtractor={(item) => item.id}
  renderItem={({ item }) => <Item {...item} />}
/>

4.2 追求极致用 FlashList

Shopify 出品的 FlashList（@shopify/flash-list）性能比 FlatList 更好，API 几乎兼容：

import { FlashList } from '@shopify/flash-list'

<FlashList
  data={items}
  keyExtractor={(item) => item.id}
  renderItem={({ item }) => <Item {...item} />}
  estimatedItemSize={80}
/>

只需注意两点：给 estimatedItemSize 一个合理的估计值，且列表项高度要稳定。

4.3 列表项优化

🔹 列表项用 React.memo + 稳定 props，避免滚动时整列重渲染。

🔹 keyExtractor 必填，且返回稳定唯一值（不要用数组下标）。

🔹 getItemLayout：如果列表项高度固定，提供这个能让 scrollToIndex 精确定位。

<FlatList
  getItemLayout={(data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  })}
/>

🔹 避免列表项内复杂布局：深嵌套的布局会放大渲染成本，善用 View 扁平化。

---

五、启动性能：用户的第一印象

启动速度是用户留存的关键指标。启动优化核心围绕"少加载、早显示"。

5.1 引擎与字节码

🔹 启用 Hermes：字节码预编译，显著减少启动时的 JS 解析时间。

🔹 Inline Requires：按需加载模块，而不是启动时加载全部 Bundle。

5.2 减小 Bundle 体积

🔹 Tree Shaking：移除未使用的代码。

🔹 按需加载：把非首屏功能拆成独立 Bundle，用到再加载。

🔹 RAM Bundle（iOS）：把 Bundle 拆成可懒加载的模块。

5.3 延迟初始化

🔹 TurboModule 懒加载：新架构下原生模块按需初始化，不再一启动全加载。

🔹 延迟非首屏初始化：把统计 SDK、非关键功能的初始化延后到首屏渲染完成后。

5.4 首屏占位（Skeleton）

用户不喜欢白屏。用一个骨架屏占位，让用户"看到"内容在加载，比白屏的体感好得多：

// 数据未就绪时显示骨架屏
if (isLoading) return <Skeleton />
return <Content data={data} />

---

六、内存管理：别让 App 越用越卡

内存泄漏会导致 App 使用一段时间后变卡，甚至被系统杀掉。

6.1 及时清理副作用

useEffect 里注册的订阅、定时器、监听器，必须在清理函数中释放：

useEffect(() => {
  const subscription = eventEmitter.addListener('event', handler)
  const timer = setInterval(tick, 1000)

  // 清理函数
  return () => {
    subscription.remove()
    clearInterval(timer)
  }
}, [])

6.2 图片及时释放

大图是最主要的内存占用来源。列表滚动出屏幕的图片要能及时释放，避免内存堆积。

6.3 大列表虚拟化

虚拟化本身就是内存优化——只渲染可见项，内存占用与列表长度无关。

6.4 监控内存泄漏

🔹 iOS：用 Instruments 的 Leaks 工具检测泄漏。

🔹 Android：用 LeakCanary 自动检测常见泄漏模式。

---

七、图片优化：最大的性能杠杆

图片往往占 App 内存和流量的最大头，优化图片是性价比最高的性能投入。

7.1 用 FastImage

react-native-fast-image 提供了原生缓存和优先级控制：

import FastImage from 'react-native-fast-image'

<FastImage
  style={{ width: 200, height: 200 }}
  source={{
    uri: 'https://cdn.example.com/img.jpg',
    priority: FastImage.priority.normal,
  }}
  resizeMode={FastImage.resizeMode.cover}
/>

7.2 尺寸与格式

🔹 CDN 裁剪：按显示尺寸请求图片，不要拉原图再缩放。

🔹 WebP 格式：同等质量下体积更小，加载更快。

🔹 合理 resizeMode：用 cover / contain 控制缩放，避免加载超大图占用内存。

💡 好消息是，新架构（Fabric）下的 Image 组件性能已显著提升，部分场景不再必须引入 FastImage。

---

八、渲染层优化（新架构红利）

新架构的 Fabric 渲染器带来了两个自动的性能提升：

🔹 View Flattening：自动合并无副作用的嵌套 View，减少原生视图层级。你写的深嵌套布局，在原生侧会被"拍平"，渲染更快。

🔹 同步 Commit：布局和渲染提交改为同步，降低渲染延迟，减少中间帧。

这意味着升级到新架构本身就是一次性能优化，很多之前需要手动优化的点，现在由框架自动处理了。

---

九、优化路线图

性能优化要有优先级，建议按下面的顺序推进：

1. 先量化：用 Profiler 找到真正的瓶颈，别拍脑袋。

2. 先改最痛的点：通常是长列表和图片，投入产出比最高。

3. 减少 Re-render：React.memo、useMemo、状态下沉，成本低见效快。

4. 启动优化：Hermes、Inline Requires、骨架屏。

5. 内存治理：清理副作用、监控泄漏。

6. 升级新架构：享受 Fabric、TurboModules 的自动优化红利。

---

十、常见误区

误区 1：盲目加 memo

React.memo 本身也有比较成本，对简单组件反而可能更慢。优先优化真正昂贵的组件，不要全量套 memo。

误区 2：过早优化

没有量化的优化是浪费。先跑起来、先测量，再针对热点优化。大部分性能问题集中在少数几个组件上。

误区 3：忽略图片

图片优化被严重低估。加载一张原图可能比优化十处 JS 代码带来的收益都大。

误区 4：升级 RN 版本就能解决一切

新架构确实带来性能提升，但它不是万能药。列表项渲染、图片加载、内存泄漏这些老问题，仍然需要主动治理。

---

十一、总结

RN 性能优化没有银弹，但有清晰的路径：

🔹 量化优先：用 Profiler / Systrace / Instruments 找到瓶颈。

🔹 渲染优化：减少 Re-render，善用 memo、useMemo、状态下沉。

🔹 列表优化：用 FlatList / FlashList，列表项 memo + 稳定 props。

🔹 启动优化：Hermes、Inline Requires、骨架屏。

🔹 内存与图片：及时清理副作用，用 FastImage + CDN 裁剪。

🔹 吃新架构红利：升级到 0.76+，享受 Fabric 与 TurboModules 的自动优化。

记住核心原则：先测量，再优化，把力气花在真正的热点上。这样你花在性能上的每一分时间，都能换来可感知的体验提升。

---

参考资源

🔹 React Native 性能官方文档：https://reactnative.dev/docs/performance

🔹 FlashList：https://shopify.github.io/flash-list/

🔹 react-native-fast-image：https://github.com/DylanVann/react-native-fast-image

🔹 Hermes Profiler：https://hermesengine.dev/docs/profile/

💡 提示：性能表现与具体设备、数据规模、RN 版本强相关，优化时请以真机测量数据为准。