什么是 ‘Flamechart’ 分析中的 React 瓶颈？解析 `Scripting` 耗时与 `Painting` 耗时的因果关系

各位同学，大家好！

欢迎来到今天的讲座。我们今天要深入探讨的主题是：在 React 应用的性能优化中，如何利用 Flamechart 识别瓶颈，特别是 Scripting 耗时与 Painting 耗时之间的因果关系。作为一名开发者，我们不仅要写出功能完善的代码，更要关注用户体验，而性能正是用户体验的核心。一个迟缓、卡顿的页面，即使功能再强大，也难以留住用户。

React 凭借其组件化、声明式编程的特性，极大地提高了开发效率。然而，不恰当的使用方式也可能导致性能问题。理解这些问题并掌握诊断工具，是每位 React 开发者进阶的必经之路。

一、性能瓶颈的宏观视角：为什么 React 应用会慢？

在深入 Flamechart 之前，我们先来回顾一下 Web 应用的生命周期和 React 的工作原理。当用户访问一个 Web 页面时，浏览器会经历一系列步骤：

1. 加载 (Loading)：下载 HTML、CSS、JavaScript 等资源。
2. 解析 (Parsing)：解析 HTML 构建 DOM 树，解析 CSS 构建 CSSOM 树。
3. 渲染 (Rendering)：
   • 样式计算 (Style Calculation)：根据 CSSOM 树计算每个元素的最终样式。
   • 布局 (Layout/Reflow)：根据 DOM 树和计算出的样式，确定每个元素在屏幕上的位置和大小。
   • 绘制 (Paint)：将布局好的元素绘制到屏幕上。这涉及到像素的填充、图像的渲染等。
   • 合成 (Compositing)：将不同图层组合成最终的屏幕图像。
4. 脚本执行 (Scripting)：执行 JavaScript 代码，处理用户交互、数据操作、DOM 更新等。

React 应用的性能瓶颈通常就发生在渲染阶段和脚本执行阶段。React 的核心机制是虚拟 DOM (Virtual DOM) 和协调 (Reconciliation)。当组件的状态或属性发生变化时，React 会：

1. 重新渲染 (Re-render)：调用组件的 render 方法（或函数组件体），生成新的虚拟 DOM 树。
2. 协调 (Reconciliation)：将新的虚拟 DOM 树与旧的虚拟 DOM 树进行比较，找出差异。
3. 提交 (Commit)：将差异应用到真实的 DOM 上，这会触发浏览器的渲染流程。

这个过程中的每一步都可能成为性能瓶颈，而 Flamechart 正是帮助我们直观看到这些耗时的利器。

二、揭秘 Flamechart：性能分析的显微镜

Chrome DevTools 的 Performance 面板是前端性能分析的强大工具。当我们录制一段性能会话后，会看到一个瀑布流式的图表，其中 Flamechart (火焰图) 是最核心的部分。

什么是 Flamechart？

Flamechart 以可视化的方式展示了主线程在一段时间内执行的函数调用堆栈。

• 横轴 (X 轴)：代表时间，从左到右表示时间线的推进。
• 纵轴 (Y 轴)：代表调用栈的深度。每个矩形代表一个函数调用。
  • 越上层的矩形表示越具体的函数（子函数）。
  • 越下层的矩形表示调用者（父函数）。
• 矩形的宽度：表示该函数执行所花费的时间，宽度越宽，耗时越长。
• 矩形的颜色：通常根据活动类型进行着色，例如黄色表示 Scripting (JavaScript 执行)，紫色表示 Recalculate Style (样式计算)，绿色表示 Layout (布局)，蓝色表示 Painting (绘制)。

通过 Flamechart，我们可以清晰地看到在特定时间点，主线程在忙些什么，哪个函数调用链耗时最长，从而定位性能瓶颈。

在 Flamechart 中，我们最常关注的几个主要活动类别包括：

• Scripting (脚本执行)：JavaScript 代码的执行时间，包括 React 的协调过程、事件处理、数据计算等。
• Rendering (渲染)：这是一个更广泛的类别，通常包括 Style Calculation、Layout 和 Paint。
• Painting (绘制)：浏览器将元素像素绘制到屏幕上的时间。
• Layout (布局)：浏览器计算元素几何尺寸和位置的时间。
• Idle (空闲)：主线程没有执行任务的时间。

今天，我们的重点将放在 Scripting 和 Painting 这两个核心耗时类别上。

三、深挖 Scripting 瓶颈：JavaScript 的性能陷阱

Scripting 耗时高，意味着我们的 JavaScript 代码执行效率低下，或者执行了过多的不必要任务。在 React 应用中，这通常与以下几个方面紧密相关：

3.1 Scripting 包含什么？

• React 协调过程 (Reconciliation)：当组件状态或属性更新时，React 比较虚拟 DOM 树的差异，这是纯粹的 JavaScript 计算。
• 组件的 render 函数/函数组件体执行：生成虚拟 DOM 的过程。
• 生命周期方法/Hooks 执行：如 componentDidUpdate、useEffect、useLayoutEffect 等。
• 事件处理函数：用户交互触发的回调函数。
• 数据处理和计算：例如数组排序、过滤、复杂的数学运算等。
• 第三方库的初始化和执行：地图库、图表库、日期库等。

3.2 导致高 Scripting 耗时的常见原因

3.2.1 过度的组件重新渲染 (Excessive Re-renders)

这是 React 应用中最常见的性能问题之一。当父组件状态变化时，其所有子组件（即使它们的 props 没有变化）默认都会重新渲染。

反例代码：

// components/ExpensiveComponent.jsx
import React from 'react';

const ExpensiveComponent = ({ value }) => {
  // 模拟一个耗时操作，例如复杂的计算或大量 DOM 操作
  // 实际应用中可能是一个复杂的图表、表格或动画
  const startTime = performance.now();
  let result = 0;
  for (let i = 0; i < 1000000; i++) {
    result += Math.sqrt(i) * Math.sin(i);
  }
  const endTime = performance.now();
  console.log(`ExpensiveComponent rendered with value ${value}. Calculation took ${endTime - startTime}ms.`);

  return (
    <div style={{ border: '1px solid red', padding: '10px', margin: '10px' }}>
      <h3>Expensive Component</h3>
      <p>Value: {value}</p>
      <p>Result of heavy calculation: {result.toFixed(2)}</p>
    </div>
  );
};

export default ExpensiveComponent;

// App.jsx
import React, { useState, useCallback } from 'react';
import ExpensiveComponent from './components/ExpensiveComponent';
import ChildComponent from './components/ChildComponent';

const ChildComponent = ({ count, onClick }) => {
  console.log('ChildComponent rendered');
  return (
    <div style={{ border: '1px solid blue', padding: '10px', margin: '10px' }}>
      <h4>Child Component</h4>
      <p>Count: {count}</p>
      <button onClick={onClick}>Increment Count</button>
    </div>
  );
};

function App() {
  const [parentData, setParentData] = useState(0);
  const [childCount, setChildCount] = useState(0);

  // 每次 App 渲染时，这个函数都会重新创建
  const handleChildClick = () => {
    setChildCount(prev => prev + 1);
  };

  return (
    <div>
      <h1>Parent Component</h1>
      <button onClick={() => setParentData(prev => prev + 1)}>
        Update Parent Data ({parentData})
      </button>
      {/* 即使 childCount 没有变化，ChildComponent 也会因为父组件渲染而重新渲染 */}
      <ChildComponent count={childCount} onClick={handleChildClick} />
      {/* ExpensiveComponent 也会因为父组件渲染而重新渲染 */}
      <ExpensiveComponent value={parentData % 5} />
    </div>
  );
}

export default App;

在上述 App.jsx 中，当 parentData 状态更新时，App 组件会重新渲染。由于 ChildComponent 和 ExpensiveComponent 都是 App 的子组件，它们也会被重新渲染，即使它们的 props 在逻辑上可能没有改变（例如 ChildComponent 的 count ）。特别地，ExpensiveComponent 中的模拟耗时计算会在每次渲染时都执行。

3.2.2 复杂计算直接放在渲染逻辑中

在 render 函数或函数组件体中执行耗时的计算，会阻塞 UI 渲染，增加 Scripting 时间。

// Bad example: Heavy calculation in render
function MyComponent({ data }) {
  // 假设 data 是一个大型数组，每次渲染都进行耗时计算
  const processedData = data.filter(item => item.isActive).map(item => item.value * 2);

  return (
    <div>
      {processedData.map(item => <p key={item}>{item}</p>)}
    </div>
  );
}

3.2.3 useEffect 的不当使用

不正确的依赖数组会导致 useEffect 回调函数频繁执行，尤其当回调函数中包含耗时操作时。

function MyEffectComponent({ items }) {
  const [filteredItems, setFilteredItems] = useState([]);

  useEffect(() => {
    // 假设 items 是一个大型数组，这里进行复杂过滤
    const newFiltered = items.filter(item => item.category === 'active');
    setFilteredItems(newFiltered);
  }, []); // ❌ 依赖数组为空，但 items 可能在外部变化，导致数据不一致且无法响应更新
        // 如果这里是 [items]，那么每次 items 变化都会重新执行，这可能是预期的
        // 但如果 items 频繁变化，且过滤操作很重，就成了瓶颈
}

3.2.4 大规模数据处理

在 JavaScript 中处理大量数据（如排序、过滤、转换）本身就是耗时的 Scripting 任务。

3.2.5 不可变数据结构的使用不当

在 React 中，我们通常推荐使用不可变数据。但如果在每次更新时都无脑地创建全新的大型对象或数组，即使内容没有变化，也会增加内存开销和 Scripting 耗时。

// Bad example: creating new objects/arrays unnecessarily
function ParentComponent() {
  const [state, setState] = useState({ list: [1, 2, 3] });

  const handleClick = () => {
    // 即使只是更新其他属性，也可能创建新的 list 引用
    setState(prev => ({ ...prev, otherProp: 'new' })); // list 引用没变，但如果子组件的 props 接收的是 prev.list，则仍是旧引用
    // 如果是这样：
    // setState(prev => ({
    //   ...prev,
    //   list: [...prev.list], // 即使内容相同，也创建了新引用
    //   otherProp: 'new'
    // }));
    // 那么依赖 list 的 memoized 组件就会重新渲染
  };

  return <ChildComponent data={state.list} />;
}

// ChildComponent 如果使用了 React.memo，但 data 的引用频繁变化，memoization 就会失效。
const ChildComponent = React.memo(({ data }) => {
  console.log('ChildComponent rendered');
  return <div>{data.join(', ')}</div>;
});

3.3 缓解 Scripting 瓶颈的策略

3.3.1 使用 React.memo (针对函数组件)

React.memo 是一个高阶组件 (HOC)，它会浅比较组件的 props。如果 props 没有变化，组件就不会重新渲染。

优化后的代码示例：

// components/ExpensiveComponent.jsx (无需修改，因为它本身没有子组件，且其内部计算需要执行)
// 但我们可以在父组件中使用 memo 包裹它，使其在 props 不变时跳过渲染
import React from 'react';

const ExpensiveComponent = ({ value }) => {
  const startTime = performance.now();
  let result = 0;
  for (let i = 0; i < 1000000; i++) {
    result += Math.sqrt(i) * Math.sin(i);
  }
  const endTime = performance.now();
  console.log(`ExpensiveComponent rendered with value ${value}. Calculation took ${endTime - startTime}ms.`);

  return (
    <div style={{ border: '1px solid red', padding: '10px', margin: '10px' }}>
      <h3>Expensive Component</h3>
      <p>Value: {value}</p>
      <p>Result of heavy calculation: {result.toFixed(2)}</p>
    </div>
  );
};

// 使用 React.memo 包裹
export default React.memo(ExpensiveComponent);

// components/ChildComponent.jsx
import React from 'react';

const ChildComponent = ({ count, onClick }) => {
  console.log('ChildComponent rendered');
  return (
    <div style={{ border: '1px solid blue', padding: '10px', margin: '10px' }}>
      <h4>Child Component</h4>
      <p>Count: {count}</p>
      <button onClick={onClick}>Increment Count</button>
    </div>
  );
};

// 使用 React.memo 包裹
export default React.memo(ChildComponent);

// App.jsx
import React, { useState, useCallback } from 'react';
import ExpensiveComponent from './components/ExpensiveComponent'; // 导入的是 memoized 版本
import ChildComponent from './components/ChildComponent'; // 导入的是 memoized 版本

function App() {
  const [parentData, setParentData] = useState(0);
  const [childCount, setChildCount] = useState(0);

  // 使用 useCallback  memoize 事件处理函数
  // 只有当 childCount 变化时，这个函数才会重新创建
  const handleChildClick = useCallback(() => {
    setChildCount(prev => prev + 1);
  }, []); // 空依赖数组意味着这个函数只会在组件挂载时创建一次

  return (
    <div>
      <h1>Parent Component</h1>
      <button onClick={() => setParentData(prev => prev + 1)}>
        Update Parent Data ({parentData})
      </button>
      <ChildComponent count={childCount} onClick={handleChildClick} />
      <ExpensiveComponent value={parentData % 5} />
    </div>
  );
}

export default App;

现在，当 parentData 更新时：

• App 组件会重新渲染。
• ChildComponent 的 count prop 没有变化，onClick prop 也因为 useCallback 保持了引用稳定性，所以 ChildComponent 不会重新渲染。
• ExpensiveComponent 的 value prop 会变化 (parentData % 5 可能会变)，所以它会重新渲染。如果 parentData % 5 保持不变，ExpensiveComponent 也不会重新渲染。

3.3.2 使用 useCallback 优化函数引用

当函数作为 props 传递给 React.memo 包裹的子组件时，父组件每次渲染都会创建一个新的函数引用，导致 React.memo 失效。useCallback 可以 memoize 函数，确保在依赖不变的情况下，返回相同的函数实例。

3.3.3 使用 useMemo 优化计算结果

useMemo 可以 memoize 昂贵的计算结果。只有当其依赖数组中的值发生变化时，才会重新执行计算。

function MyComponent({ data }) {
  // 使用 useMemo 缓存计算结果
  const processedData = React.useMemo(() => {
    // 只有当 data 引用变化时，才重新执行这个耗时计算
    console.log('Performing heavy data processing...');
    return data.filter(item => item.isActive).map(item => item.value * 2);
  }, [data]); // 依赖数组包含 data

  return (
    <div>
      {processedData.map((item, index) => <p key={index}>{item}</p>)}
    </div>
  );
}

3.3.4 虚拟化/窗口化 (Virtualization/Windowing)

对于大型列表或表格，一次性渲染所有元素会导致大量的 DOM 节点和 Scripting 耗时。虚拟化技术只渲染当前可见区域的元素，大大减少了 DOM 数量和渲染开销。常用的库有 react-window 和 react-virtualized。

3.3.5 节流 (Throttling) 和防抖 (Debouncing)

对于频繁触发的事件（如 scroll, resize, mousemove, input），可以使用节流或防抖来限制事件处理函数的执行频率，减少不必要的 Scripting 任务。

3.3.6 优化 Context API 使用

Context API 是传递数据的好方式，但如果 Context 的 value 频繁变化，并且消费者组件没有进行 React.memo 优化，或者消费者组件的 shouldComponentUpdate 逻辑不当，会导致大量不必要的重新渲染。可以考虑：

• 拆分 Context：将不相关的状态拆分到不同的 Context 中。
• 使用 Context Selectors (如 useContextSelector from use-context-selector 库)：只在 Context 值中特定部分变化时才触发组件更新。

3.3.7 善用 shouldComponentUpdate (针对类组件)

对于类组件，可以通过实现 shouldComponentUpdate 生命周期方法，手动控制组件是否重新渲染。PureComponent 提供了浅比较 props 和 state 的默认实现。

3.3.8 Web Workers

将复杂的、计算密集型的任务（如大型数据处理、图像处理）放到 Web Workers 中执行，可以避免阻塞主线程，从而降低 Scripting 耗时。

四、解析 Painting 瓶颈：像素绘制的代价

Painting 耗时高，通常意味着浏览器在将元素绘制到屏幕上时遇到了困难，或者需要绘制的区域过于复杂或频繁。

4.1 Painting 包含什么？

Painting 是浏览器渲染流程中的一个环节，它负责将 Layout 阶段计算出的元素几何信息，以及 Style Calculation 阶段计算出的样式信息，转换成屏幕上的像素。这包括：

• 填充背景色、背景图
• 绘制文本、边框、阴影
• 应用滤镜、渐变等复杂样式
• 将不同的渲染层 (Layer) 组合起来

4.2 导致高 Painting 耗时的常见原因

4.2.1 频繁或大规模的重绘 (Repaint)

改变元素的某些 CSS 属性会触发重绘，例如 color, background-color, box-shadow, border, visibility 等。如果这些属性频繁变化，或者变化影响到大面积区域，就会导致高 Painting 耗时。

4.2.2 复杂的 CSS 样式

使用复杂的 CSS 样式，如 box-shadow、border-radius、filter、gradient、opacity 动画等，尤其是它们应用于大量元素或频繁变化时，会增加绘制的复杂度。

4.2.3 动画不当

对会触发 Layout 或 Paint 的 CSS 属性（如 width, height, top, left, margin, padding）进行动画，会导致动画的每一帧都触发 Layout 和 Paint。

4.2.4 元素重叠

如果大量元素相互重叠，浏览器需要进行更多的计算来确定每个像素的最终颜色，这会增加 Painting 成本。

4.2.5 过多的 DOM 元素

尽管这主要影响 Scripting 和 Layout，但过多的 DOM 元素也会间接增加 Painting 的工作量，因为每个元素都需要被绘制。

4.3 缓解 Painting 瓶颈的策略

4.3.1 优化 CSS 动画

优先使用 transform (例如 translate, scale, rotate) 和 opacity 进行动画。这些属性通常可以在 GPU 上进行合成，避免触发 Layout 和 Paint，从而实现更流畅的动画。

性能友好的 CSS 属性与触发机制：

属性类型	触发 Layout	触发 Paint	触发 Composite	示例属性
仅 Composite	否	否	是	transform, opacity
Paint & Composite	否	是	是	color, background-color, box-shadow
Layout & Paint & Composite	是	是	是	width, height, top, left, margin, padding, font-size

4.3.2 避免强制同步布局 (Forced Synchronous Layout)

在 JavaScript 中读写 DOM 属性时，如果先读取会触发 Layout 的属性（如 offsetWidth, offsetHeight, getComputedStyle().width），然后立即修改会触发 Layout 的属性（如 width），会导致浏览器强制执行一次同步布局，这会阻塞主线程。应尽量批量处理 DOM 读写操作，避免交叉。

// Bad example: Forced synchronous layout
const element = document.getElementById('myElement');
const width = element.offsetWidth; // 触发同步布局
element.style.width = (width + 10) + 'px'; // 再次触发布局

// Good example: Batch reads and writes
const element = document.getElementById('myElement');
const width = element.offsetWidth; // 读取
// ...其他读取操作
element.style.width = (width + 10) + 'px'; // 写入
// ...其他写入操作

4.3.3 使用 will-change 属性 (谨慎使用)

will-change CSS 属性可以提前告知浏览器，某个元素的特定属性将在不久的将来发生变化。浏览器可以据此进行优化，例如将其提升到单独的渲染层。但滥用 will-change 反而会消耗更多资源，甚至导致性能下降。只在确实需要优化的关键动画元素上使用，并且在动画结束后移除。

.animated-element {
  will-change: transform, opacity;
}

4.3.4 最小化 DOM 元素和层级

减少页面上的 DOM 元素数量和深度，可以降低浏览器在 Layout 和 Painting 阶段的工作量。虚拟化技术在这里再次发挥作用。

4.3.5 理解和利用层合成 (Layer Compositing)

浏览器会将页面划分为不同的渲染层，然后独立绘制这些层，最后将它们合成为最终图像。某些 CSS 属性（如 transform, opacity, filter, will-change）会促使浏览器为元素创建新的渲染层，这有助于性能提升，因为层内的变化不会影响其他层，且可以利用 GPU 加速。
但是，创建过多的渲染层也会消耗大量内存，并增加合成的开销。需要权衡利弊。可以通过 Chrome DevTools 的 Layers 面板查看页面当前的渲染层。

五、因果链条：Scripting 如何引爆 Painting？

现在我们来讨论今天的核心问题：Scripting 耗时与 Painting 耗时之间的因果关系。

简而言之，Scripting 阶段的 JavaScript 代码执行，尤其是 React 的协调和提交过程，是触发浏览器后续 Layout 和 Painting 阶段的“源头”。

这是一个典型的事件驱动的渲染流程：

1. 用户交互或数据更新 (Input/Data Change)：例如用户点击按钮、输入文本、从 API 获取数据等。
2. Scripting 阶段 (React 工作)：
   • JavaScript 事件处理函数被执行。
   • setState 或 useState 的更新被触发。
   • React 开始执行其协调 (Reconciliation) 算法，比较新旧虚拟 DOM 树的差异。
   • 确定需要对真实 DOM 进行哪些增、删、改操作。
   • 提交 (Commit) 阶段，React 将这些 DOM 操作应用到真实 DOM 上。
   • 如果组件中包含耗时的计算（如我们在 ExpensiveComponent 中模拟的），这些计算也会计入 Scripting 耗时。
3. 浏览器渲染流程被触发 (Browser Rendering Pipeline)：
   • 样式计算 (Recalculate Style)：DOM 变化或 CSS 属性变化可能导致浏览器重新计算受影响元素的样式。
   • 布局 (Layout/Reflow)：如果 DOM 结构、元素尺寸或位置发生变化，浏览器需要重新计算所有受影响元素的几何信息。
   • 绘制 (Paint)：如果元素的视觉外观发生变化（无论是通过 DOM 变化还是 CSS 属性变化），浏览器需要将受影响的区域重新绘制成像素。
   • 合成 (Compositing)：将所有渲染层组合成最终显示在屏幕上的图像。

因果关系图示：

用户交互/数据变化
        ↓
[Scripting] (JavaScript执行，React协调与DOM更新)
        ↓ (DOM/CSSOM 变化)
[Recalculate Style] (浏览器计算样式)
        ↓ (样式或几何尺寸变化)
[Layout] (浏览器计算元素位置和大小)
        ↓ (元素视觉外观变化)
[Paint] (浏览器绘制像素)
        ↓
[Compositing] (浏览器合成图层)
        ↓
屏幕显示更新

从 Flamechart 上看，你会发现 Scripting 活动通常会紧密地伴随着 Recalculate Style, Layout, Paint 等活动。一个宽大的 Scripting 块，往往是其后一系列渲染活动的前兆。

场景分析：

场景一：纯 Scripting 瓶颈

• 现象：Flamechart 中 Scripting 块非常宽，但其后的 Layout 和 Painting 块相对较窄或缺失。
• 原因：JavaScript 代码执行了大量耗时的计算，但这些计算并没有导致 DOM 结构或样式发生显著变化。例如，在一个大型数组上进行复杂的排序或过滤操作，结果只更新了一个小部分的文本内容。
• 优化方向：优化 JavaScript 算法、使用 useMemo、Web Workers。

场景二：Scripting 导致过度 DOM 更新，进而引发高 Layout 和 Painting

• 现象：Flamechart 中 Scripting 块很宽，紧接着是同样宽大的 Layout 和 Painting 块。
• 原因：React 组件因为 Scripting 耗时（如父组件更新导致子组件不必要地重新渲染）而生成了大量的虚拟 DOM 差异，导致真实 DOM 进行了大量的增删改操作。这些 DOM 操作又进一步触发了浏览器的 Layout 和 Painting 过程。
• 优化方向：使用 React.memo、useCallback 减少不必要的组件重新渲染，虚拟化大型列表，减少 DOM 节点数量。

场景三：Scripting 导致 CSS 属性变化，引发高 Painting (可能不伴随高 Layout)

• 现象：Flamechart 中 Scripting 块可能不是特别宽，但紧接着是宽大的 Painting 块，而 Layout 块可能较窄。
• 原因：JavaScript 代码（例如通过 setState）改变了组件的某个状态，这个状态导致某个元素的 CSS 属性发生变化，而这个 CSS 属性只触发 Paint 不触发 Layout（如 background-color, box-shadow）。如果这些 Paint 区域很大或非常复杂，就会导致高 Painting 耗时。
• 优化方向：优化 CSS 样式、使用 transform 和 opacity 进行动画，谨慎使用 will-change。

关键点： 很多时候，Painting 耗时高是 Scripting 阶段“埋下祸根”的结果。优化 Scripting 往往能间接降低 Layout 和 Painting 的成本。

六、实战：使用 Chrome DevTools 进行性能分析

现在，让我们结合 Chrome DevTools 的 Performance 面板，看看如何实际地定位这些问题。

1. 打开 DevTools：在 Chrome 浏览器中，右键点击页面，选择“检查”，然后切换到“Performance”标签页。
2. 录制性能会话：点击录制按钮（圆点图标），然后在页面上执行你想要分析的操作（例如滚动、点击、输入）。执行几秒钟后，再次点击录制按钮停止。
3. 分析 Flamechart：
   • 总览图 (Overview)：在最上方，你会看到 CPU 使用率、网络活动等概览。寻找 CPU 峰值，这些通常是性能瓶颈所在。
   • 帧 (Frames)：在 Frames 区域，你可以看到每一帧的渲染情况。红色的帧表示掉帧，绿色表示流畅。
   • 主线程 (Main Thread) Flamechart：这是最重要的部分。
     • 放大/缩小：通过拖拽总览图或滚动鼠标滚轮来放大或缩小 Flamechart，聚焦到 CPU 峰值区域。
     • 识别颜色：寻找黄色的 Scripting 块、紫色的 Recalculate Style、绿色的 Layout 和蓝色的 Paint。
     • 从上到下查看调用栈：点击一个宽大的矩形，可以查看其详细信息。往上层看，可以看到是哪个子函数在执行；往下层看，可以看到是哪个父函数调用了它。
     • 关联事件：观察 Scripting 块之后是否紧跟着 Layout 和 Paint 块。如果 Scripting 导致了这些后续活动，那么就找到了因果关系。
     • 查找 React 组件：在 Scripting 块中，你会看到许多 (anonymous) 函数，但也会看到 React 内部的函数（如 performSyncWorkOnRoot、scheduleUpdateOnFiber）以及你的组件名称（如 App, ChildComponent, ExpensiveComponent）。通过这些名称，你可以定位到是哪个组件的 render 过程或生命周期方法耗时过长。
4. Bottom-Up / Call Tree / Event Log：
   • Bottom-Up：按活动耗时从高到低排序，显示每个函数的总耗时和自耗时。这有助于快速找出最耗时的函数，无论它在调用栈的哪个位置。
   • Call Tree：以树状结构显示函数调用链，可以看到每个父函数调用子函数所花费的时间。
   • Event Log：按时间顺序显示所有事件，可以精确地查看事件发生的时间和耗时。

结合 React DevTools Profiler

Chrome DevTools 的 Performance 面板提供了宏观的浏览器级别性能数据，而 React DevTools 的 Profiler 则专注于 React 内部的性能。两者结合使用效果更佳。

1. 安装 React DevTools 扩展。
2. 打开 DevTools，切换到“Profiler”标签页。
3. 点击录制按钮，执行操作。
4. 分析结果：
   • Ranked：按渲染耗时对组件进行排序，快速找出“性能罪魁祸首”。
   • Component Chart：可视化组件的渲染时间，可以看到哪些组件在每个更新周期中被渲染。
   • Flamegraph：与 Chrome DevTools 类似，但专注于 React 组件的渲染树。
   • Interaction：可以追踪用户交互到渲染完成的整个过程。
   • 通过这些视图，你可以知道：哪些组件重新渲染了？为什么它们重新渲染了？渲染耗时多少？哪些 props 变化导致了重新渲染？

七、总结思考

性能优化是一个持续的过程，没有一劳永逸的解决方案。理解 Scripting 和 Painting 等核心性能指标的含义，掌握 Flamechart 这一强大的分析工具，并理解它们之间的因果关系，是进行有效优化的基石。

从减少不必要的 JavaScript 执行到优化浏览器像素绘制，每一步的努力都能提升用户体验。通过持续的监控、分析和迭代，我们可以构建出既功能强大又流畅响应的 React 应用。记住，性能不仅仅是速度，更是用户与应用之间无缝、愉悦的交互体验。