这篇文章介绍了 react 中 context 的实现原理，以及 context 变化时，React 如何查找所有订阅了 context 的组件并跳过 shouldComponentUpdate 强制更新。可以让我们更加充分认识到 context 的性能瓶颈并能够合理设计全局状态管理。

学习目标

React Context 的实现原理
订阅了 context 的组件是如何跳过shouldComponentUpdate强制 render 的
React 是如何使用堆栈来存储 Provider 的 value 以支持嵌套 Provider 的
context 的存取发生在 React 渲染的哪些阶段
fiber.dependencies 用于保存当前组件订阅的 context 依赖，一般情况下组件只有一个 context 依赖。但是通过 useContext 订阅多个 context 时，fiber.dependencies 就是一个链表

前言

先来简单回顾一下，React 的渲染分为两大阶段，五小阶段：

render 阶段
- beginWork
- completeUnitOfWork
commit 阶段。
- commitBeforeMutationEffects
- commitMutationEffects
- commitLayoutEffects

在 render 阶段，React 为每一个 fiber 节点调用 beginWork 开始执行工作，如果 fiber 没有子节点或者子节点都已经完成了工作，那么这个 fiber 就可以调用 completeUnitOfWork 完成自身的工作，这个过程就是深度优先遍历，具体可以看这篇文章深入概述 React 初次渲染及状态更新主流程。我们可以将进入节点的过程理解为 beginWork，离开节点的过程叫 completeUnitOfWork。

beginWork 阶段主要是协调子元素，也就是常说的 dom diff。在这个阶段，React 会调用类组件的 render 方法或者执行函数组件。**context 的存取就是作用于 beginWork 阶段。**在 beginWork 阶段，如果当前组件订阅了 context，则从 context 中读取 value 值。

context 提供了一种存取全局共享数据的方式

Context API 简介

React 提供的与 Context 相关的 API，按用途可以划分如下：

创建 context: React.createContext
提供 context 值: Context.Provider
订阅 context 值：
- Class.contextType。用于类组件订阅 Context
- Context.Consumer。用于函数组件订阅 Context，这种方式也可以间接的订阅多个 context
- useContext。用于函数组件订阅 Context，唯一的订阅多个 context 的 api。通过 useContext 订阅多个 context 时，函数组件的 fiber.dependencies 就是一个链表

下面逐一介绍每个 API 的原理

React.createContext

createContext 负责创建一个 context 对象，包含 Provider 和 Consumer 属性，其中 _currentValue 用于存储全局共享状态，订阅了 context 的组件都是从 context._currentValue 中读取最新值的

var symbolFor = Symbol.for;
const REACT_CONTEXT_TYPE = symbolFor("react.context");
const REACT_PROVIDER_TYPE = symbolFor("react.provider");
function createContext(defaultValue) {
  var context = {
    $$typeof: REACT_CONTEXT_TYPE,
    _currentValue: defaultValue,
    Provider: null,
    Consumer: null,
  };
  context.Provider = {
    $$typeof: REACT_PROVIDER_TYPE,
    _context: context,
  };
  context.Consumer = {
    $$typeof: REACT_CONTEXT_TYPE,
    _context: context,
  };

  return context;
}
const context = createContext({ count: 0 });
console.log("context....", context);

Context.Provider

Provider 有三个特性：

如果没有对应的 Provider，那么消费组件将读取 context 的默认值，即传递给 createContext 的 defaultValue
多个 Provider 可以嵌套使用，里层的会覆盖外层的数据
Provider 的 value 值发生变化时，它内部的所有消费组件都会跳过 shouldComponentUpdate 强制更新

在介绍 Provider 的源码实现前，我们思考一下，如果让我们设计一个类似 Provider 的 API，如何设计才能满足前面两个特性？（第三个特性机制较复杂，后面会详细介绍）

特性 1：Context 默认值的读取

如果没有对应的 Provider，那么消费组件将读取 context 的默认值，即传递给 createContext 的 defaultValue

注意，useContext(CounterContext)等价于 CounterContext._currentValue，为了减少干扰方便演示，这里我直接使用 CounterContext._currentValue 替代 useContext

const CounterContext = React.createContext(-1);

const Counter = () => {
  // const context = useContext(CounterContext);
  const context = CounterContext._currentValue;
  return <div>{context}</div>;
};
class Home extends React.Component {
  constructor(props) {
    super(props);
  }

  render() {
    return <Counter />;
  }
}

由于没有 Provider，Counter 将读取 context 的默认值，即页面显示-1。但如果我们用 Provider 包裹一下：

render() {
  return (
    <CounterContext.Provider value={1}>
      <Counter />
    </CounterContext.Provider>
  );
}

由于有 Provider，Counter 将读取 Provider 的 value 值，即页面显示 1。

在调用 React.createContext 创建 context 时，context._currentValue 的值保存的就是默认值。因此，如果没有 CounterContext.Provider 时，Counter 可以通过 context._currentValue 读取到默认值。

同理，如果有 CounterContext.Provider 包裹 Counter 组件时，我们只需要将 Provider 的 value 值保存到 context._currentValue 中就能让 Counter 读取到。

在 render 阶段，CounterContext.Provider 开始 beginWork 时，我们可以将 CounterContext._currentValue 设置为新的 value 值。这样在后续的渲染阶段，Counter 就能够通过 CounterContext._currentValue 读取到 Provider 最新的 value 值。我们似乎已经满足了第一个特性

function beginWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider:
      CounterContext._currentValue = workInProgress.pendingProps.value;
  }
}

但考虑到下面的案例

render() {
  return [
    <CounterContext.Provider value={1}>
      <Counter />
    </CounterContext.Provider>,
    <Counter />,
  ];
}

第二个 Counter 由于没有 Provider，理论上它要读取 context 的默认值。但是我们在 beginWork 时，已经将 CounterContext._currentValue 修改成最新的值了，第二个 Counter 读取到的也将是最新的值，而不是默认值。我们需要修改一下 beginWork 的逻辑

let valueCursor;
function beginWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider:
      valueCursor = CounterContext._currentValue; // 先将旧值保存起来
      CounterContext._currentValue = workInProgress.pendingProps.value; // pendingProps保存的是新值
  }
}

我们声明一个全局变量，将旧值保存起来，然后再将 CounterContext._currentValue 设置成新的 value 值。那么问题来了，我们应该在哪个阶段将 CounterContext._currentValue 的值恢复成旧值？

在前面介绍过，React 在遍历 fiber 树时，进入节点时会调用 beginWork 方法开始工作，离开节点时会调用 completeUnitOfWork 完成工作。因此我们可以在离开 fiber 节点时，将 context._currentValue 恢复成旧值

completeUnitOfWork 内部调用 completeWork 完成工作，大概如下：

function completeWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider:
      // 在离开Provider节点时，将context._currentValue恢复成旧值
      const oldValue = valueCursor;
      CounterContext._currentValue = oldValue;
      return null;
  }
}

特性 2：多个相同 Provider 可以嵌套使用，里层的会覆盖外层的数据

我们自己设计的 api 已经能够满足 Provider 的第一个特性了，我们在进入 Provider fiber 节点时，将当前的 context._currentValue 值保存起来，然后再将 Provider 新的 value 值保存在 context._currentValue 中，这样 Provider 内部的所有组件都能够通过 context._currentValue 读取到最新的值。然后在离开 Provider fiber 节点时，我们将 context._currentValue 恢复成旧值。

现在让我们考虑下面多个 Provider 嵌套的场景：

render() {
  return [
    <CounterContext.Provider id="provider1" value={1}>
      <CounterContext.Provider id="provider2" value={2}>
        <Counter id="counter1" />
      </CounterContext.Provider>
      <Counter id="counter2" />
    </CounterContext.Provider>,
    <Counter id="counter3" />,
  ];
}

根据 Provider 里层覆盖外层值的特性：

counter1读取的是provider2的 value 值，即 2
counter2读取的是provider1的 value 值，即 1
counter3由于没有 Provider 包裹，因此读取的是 context 的默认值，即-1

页面显示 2，1，-1。

同时，我们必须要理解的一点是，provider1和provider2虽然是两个组件，但他们的 context 是同一个引用，三个 Counter 组件都是从 context._currentValue 中读取的值

显然我们在前面设计的 api 满足不了这种场景，为了能实现嵌套的机制，我们遵循 React 遍历 fiber 节点的顺序，来看下这个思路：

在进入provider1时，将当前 context._currentValue 的值(记为oldValue1)保存起来，然后将provider1新的 value 值赋值给 context._currentValue
React 继续遍历provider2，进入provider2时，我们又需要将当前 context._currentValue 的值(记为oldValue2)保存起来，然后将provider2新的 value 值赋值给 context._currentValue
React 继续遍历counter1，counter1读取 context._currentValue 的值，就是provider2的 value 值。遍历完counter1后，就可以调用 completeUnitOfWork 完成工作
当为provider2完成工作时，即离开provider2时，我们需要将 context._currentValue 的值恢复成provider1的 value 值，即oldValue2
开始遍历 counter2，此时 counter2 通过 context._currentValue 读取到的就是 provider1 的 value 值
当为provider1完成工作时，即离开provider1时，我们需要将 context._currentValue 的值恢复成默认值，即oldValue1

看上去这个思路行得通，我们只需要多声明几个全局变量保存 context 的当前值就可以了

let valueCursor1; // 保存oldValue1
let valueCursor2; // 保存oldValue2
function beginWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider:
      if (workInProgress.id === "provider1") {
        valueCursor1 = CounterContext._currentValue; // 进入provider1时，将CounterContext的当前值保存起来，此时是默认值
        CounterContext._currentValue = workInProgress.pendingProps.value; //将provider1新的value值赋值给CounterContext._currentValue
      }
      if (workInProgress.id === "provider2") {
        valueCursor2 = CounterContext._currentValue; // 进入provider2时，将CounterContext的当前值保存起来，此时是provider1的value值
        CounterContext._currentValue = workInProgress.pendingProps.value; //将provider2新的value值赋值给CounterContext._currentValue
      }
  }
}
function completeWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider:
      if (workInProgress.id === "provider2") {
        CounterContext._currentValue = valueCursor2; // 离开provider2节点时，需要将context._currentValue恢复成provider1的value值
      }
      if (workInProgress.id === "provider1") {
        CounterContext._currentValue = valueCursor1; // 离开provider1节点时，需要将context._currentValue恢复成默认值
      }

      return null;
  }
}

似乎这个实现思路已经满足两个 provider 的嵌套，如果有代码洁癖的同学会发现，valueCursor1，valueCursor2，以及 if 判断不太友好。同时，最重要的是，我们无法满足更多层级的 provider 的嵌套：

  render() {
    return [
      <CounterContext.Provider id="provider1" value={1}>
        <CounterContext.Provider id="provider2" value={2}>
          <CounterContext.Provider id="provider3" value={3}>
            <CounterContext.Provider id="provider4" value={4}>
              <Counter id="counter1" />
            </CounterContext.Provider>
          </CounterContext.Provider>
        </CounterContext.Provider>
        <Counter id="counter2" />
      </CounterContext.Provider>,
      <Counter id="counter3" />,
    ];
  }

如果按照我们的做法，得声明好几个变量保存当前值，然后我们又无法确定有多少层级根本无法提前声明这些变量。看到这里，fiber 节点进进出出的很容易让我们想到堆栈，我们可以使用栈来保存当前的 context 值

let valueStack = [];
let index = -1;
function beginWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider: {
      var context = workInProgress.type._context;
      index++;
      valueStack[index] = context._currentValue; // 先将context当前的值保存起来
      context._currentValue = workInProgress.pendingProps.value; // 然后将provider新的value值赋值给context._currentValue
    }
  }
}
function completeWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider: {
      const preValue = valueStack[index];
      valueStack[index] = null;
      index--;
      var context = providerFiber.type._context;
      context._currentValue = preValue;
    }
  }
}

这个版本的实现已经可以满足嵌套任意层的 Provider 了，同时还能满足不同的 Provider 组件嵌套，比如：

render() {
  return [
    <CounterContext.Provider id="provider1" value={1}>
      <UserContext.Provider id="userprovider1" value={"mike"}>
        <Counter id="counter1" />
      </UserContext.Provider>
    </CounterContext.Provider>,
  ];
}

实际上，这正是 React 所采用的实现方式，这种方式既能满足读取默认值的特性，又能满足里层的 Provider 覆盖外层的 Provider 的场景(指的是相同的 Provider 的覆盖)

Context.Provider 源码实现

在 render 阶段，React 进入 Provider 类型的 fiber 节点时，beginWork 会调用updateContextProvider函数为 Provider 类型的节点执行工作，主要逻辑如下：

调用 pushProvider，将 context._currentValue 保存到 valueStack 栈中。然后将 context._currentValue 设置成 Provider 新的 value 值
使用浅比较判断 Context.Provider 的新旧 value 值是否发生了改变，如果发生了改变，则调用 propagateContextChange 找出所有订阅了这个 context 的组件，然后跳过 shouldComponenentUpdate 强制更新。查找算法放在后面单独一节介绍

在 completeWork 阶段，Provider 类型的 fiber 节点执行的主要工作有一点：

调用 popProvider 将 context._current 恢复成上一个值，即直接从 valueStack 取出第一项即可

function beginWork(current, workInProgress, renderLanes) {
  switch (workInProgress.tag) {
    case ContextProvider:
      return updateContextProvider(current, workInProgress, renderLanes);
  }
}
function completeWork(current, workInProgress, renderLanes) {
  var newProps = workInProgress.pendingProps;
  switch (workInProgress.tag) {
    case ContextProvider:
      popProvider(workInProgress);
      return null;
  }
}
var valueCursor = { current: null };
var valueStack = [];
var index = -1;
function pushProvider(providerFiber, nextValue) {
  var context = providerFiber.type._context;
  index++;
  valueStack[index] = valueCursor.current;
  valueCursor.current = context._currentValue;
  context._currentValue = nextValue;
}
function updateContextProvider(current, workInProgress, renderLanes) {
  var context = workInProgress.type._context; // React.createContext的返回值
  var newProps = workInProgress.pendingProps;
  var oldProps = workInProgress.memoizedProps;
  var newValue = newProps.value;

  pushProvider(workInProgress, newValue);

  if (oldProps !== null) {
    var oldValue = oldProps.value;
    var changedBits = newValue === oldValue;
    if (changedBits === 0) {
      if (oldProps.children === newProps.children && !hasContextChanged()) {
        // 没有改变
        return bailoutOnAlreadyFinishedWork(
          current,
          workInProgress,
          renderLanes
        );
      }
    } else {
      // context变了，遍历Provider所有的子孙fiber节点，查找订阅了该context的组件并标记为强制更新
      propagateContextChange(workInProgress, context, changedBits, renderLanes);
    }
  }

  var newChildren = newProps.children;
  reconcileChildren(current, workInProgress, newChildren, renderLanes);
  return workInProgress.child;
}

function popProvider(providerFiber) {
  var currentValue = valueCursor.current;
  pop(valueCursor);
  var context = providerFiber.type._context;
  context._currentValue = currentValue;
}

消费组件如何读取 Context 的值？

React 提供了三种方式读取 Context 的值：

Class.contextType。用于类组件订阅 Context
Context.Consumer。用于函数组件订阅 Context
useContext。用于函数组件订阅 Context

以上三种方式，都是需要手动传递 context 对象的，比如 useContext(context)，Class.contextType = context。

对于函数组件，useContext 本质上就是调的readContext函数，即我们可以直接认为useContext === readContext，readContext 返回 context._currentValue

对于类组件，React 会判断类组件上是否有静态属性 contextType，如果有，则调用 readContext 读取 context 值，并赋值给类实例的 context 属性

prepareToReadContext(workInProgress, renderLanes);
const ctor = workInProgress.type;
const instance = new ctor();
const contextType = ctor.contextType;
if (typeof contextType === "object" && contextType !== null) {
  instance.context = readContext(contextType);
}

对于 Context.Consumer，context 本身就存在 Consumer 里面

var context = workInProgress.type;
var newProps = workInProgress.pendingProps;
var render = newProps.children;
prepareToReadContext(workInProgress, renderLanes);
var newValue = readContext(context, newProps.unstable_observedBits);
var newChildren = render(newValue);

这三种方式在读取 context 时都要进行两个操作：

在读取 context 前，都需要先调用prepareToReadContext进行准备工作，重置几个和 contex 有关的全局变量，以及判断 context 的 value 是否变更了
都是调用 readContext 方法读取 context 值，readContext 方法返回 context._currentValue 的值

prepareToReadContext主要逻辑如下：

将全局变量 currentlyRenderingFiber 设置为当前正在工作的 fiber，在 readContext 时可以通过这个全局变量拿到正在工作中的 fiber
将全局变量 lastContextWithAllBitsObserved 重置为 null，这个变量在 readContext 函数中会被设置成 context 对象
全局变量 lastContextDependency 在通过 useContext 订阅多个不同的 context 时，用于构造 dependencies 列表
重置 fiber dependencies 列表

function prepareToReadContext(workInProgress, renderLanes) {
  currentlyRenderingFiber = workInProgress;
  lastContextDependency = null;
  lastContextWithAllBitsObserved = null; // 这个全局变量保存的是context对象
  var dependencies = workInProgress.dependencies;

  if (dependencies !== null) {
    var firstContext = dependencies.firstContext;

    if (firstContext !== null) {
      if (includesSomeLane(dependencies.lanes, renderLanes)) {
        // Context list has a pending update. Mark that this fiber performed work.
        didReceiveUpdate = true;
      } // Reset the work-in-progress list
      // 重置fiber context依赖
      dependencies.firstContext = null;
    }
  }
}

readContext 读取 context 最新值

context 本质上就是一个全局变量，我们完全可以在函数组件或者类组件中通过context._currentValue直接访问 context 值，比如：

const Counter = () => {
  return <div>{CounterContext._currentValue}</div>;
};

不信你可以在代码中试试。虽然我们可以直接读取值，但是直接读取值无法解决下面两个问题：

context 的值变了，如何通知所有读取 context 的组件强制刷新？
怎么知道哪些组件订阅了 context？

也正是为了解决全局变量的这两个问题，React 使用 Provider 显示声明全局状态，使用 useContext 或者 contextType 显示使用全局状态。React 通过在 useContext 或者 contextType 中读取全局状态时，会将 context 的信息存储在消费组件的 fiber.dependencies 中，然后 Provider 会判断 value 值是否改变，如果改变，则查找内部所有订阅了这个 context 的消费组件并强制更新

这也是为什么 React 会引入 Provider 和 useContext、contextType 的根本原理

下面我们看看 readContext 的逻辑，readContext 的一个主要目标就是收集组件依赖的所有不同的 context，如果组件订阅了 context，则将 context 添加到 fiber.dependencies 链表中，比如

const CounterContext = React.createContext(-1);
const UserContext = React.createContext("mike");

const Counter = () => {
  const context = useContext(CounterContext);
  const context2 = useContext(CounterContext);
  const usercontext = useContext(UserContext);

  return (
    <div>
      {context}
      {usercontext}
    </div>
  );
};

这个例子中，虽然我们调用了三次 useContext，但是 context 和 contex2 是同一个 context，React 认为 Counter 组件订阅了两个 context，而不是三个，因此将这两个 context 添加到 fiber 的 dependencies 依赖链表中，最终，fiber.dependencies 长这样：

fiber.dependencies = {
  lanes,
  firstContext: {
    context: CounterContext,
    next: {
      context: UserContext,
      next: null,
    },
  },
  responders,
};

readContext 收集依赖的算法如下，首先判断 lastContextWithAllBitsObserved === context，如果相等，说明是同一个 context，这种判断是为了防止重复添加依赖。如果不等，则将 lastContextWithAllBitsObserved 设置为 context，并将 context 添加到 fiber.dependencies 链表末尾

function readContext(context, observedBits) {
  if (lastContextWithAllBitsObserved === context) {
  } else {
    lastContextWithAllBitsObserved = context;
    var resolvedObservedBits = MAX_SIGNED_31_BIT_INT;

    var contextItem = {
      context: context,
      observedBits: resolvedObservedBits,
      next: null,
    };

    if (lastContextDependency === null) {
      // 这是第一个依赖
      lastContextDependency = contextItem;
      currentlyRenderingFiber.dependencies = {
        lanes: NoLanes,
        firstContext: contextItem,
        responders: null,
      };
    } else {
      // 添加到dependencies表尾
      lastContextDependency = lastContextDependency.next = contextItem;
    }
  }

  return context._currentValue;
}

以上面的例子为例介绍 context 的读取过程

render 阶段进入 Counter 节点时开始调用 beginWork 执行工作，在读取 context 前，调用 prepareToReadContext 进行一些准备工作，比如：

currentlyRenderingFiber = workInProgress;
lastContextDependency = null;
lastContextWithAllBitsObserved = null;

然后开始调用 readContext 读取 context 的_currentValue 值，步骤如下

首先调用 const context = useContext(CounterContext)，由于此时的 lastContextWithAllBitsObserved 为 null，lastContextWithAllBitsObserved !== context，因此将这个 context 添加到 fiber 的 dependencies 链表中。同时 lastContextDependency 指针指向表尾，目前链表只有一个 context 依赖
然后调用 const context2 = useContext(CounterContext)再次读取 CounterContext，由于此时的 lastContextWithAllBitsObserved === CounterContext，说明 CounterContext 已经被添加到 fiber.dependencies 链表中了，不必重复添加，直接返回 CounterContext._currentValue
最后调用 const usercontext = useContext(UserContext)，发现 lastContextWithAllBitsObserved !== UserContext，说明 UserContext 还没添加到 fiber.dependencies 链表中，因此添加进去即可

Context.Provider value 变化，React 如何强制更新？

Provider 的 value 值变化时，其内部所有订阅了这个 context 的组件都会强制更新。

<CounterContext.Provider id="provider1" value={this.state.count}>
  <CounterContext.Provider id="provider2" value="2">
    <Counter />
  </CounterContext.Provider>
</CounterContext.Provider>

比如在这个例子中，有两个嵌套的 CounterContext.Provider，但是 Counter 组件只会读取最里层的 Provider，即provider2的 value 值。即使provider1的 value 发生变化，也不会影响到 Counter 组件。provider2的 value 值发生变化时，才会强制 Counter 更新。

Provider 的 value 值变化时，React 会遍历 Provider 内部所有的 fiber 节点，然后查看其 fiber.dependencies，如果 dependencies 中存在一个 context 和当前 Provider 的 context 相等，那说明这个组件订阅了当前的 Provider 的 context，需要将其标记为强制更新

下面的 demo 演示了 React 跳过 sCU 更新消费组件的场景：

const CounterContext = React.createContext({
  count: 0,
  addCount: () => {},
});

class Counter extends React.Component {
  static contextType = CounterContext;
  shouldComponentUpdate() {
    return false;
  }
  render() {
    console.log("Counter render");
    return (
      <button id="counter" onClick={this.context.addCount}>
        {this.context.count}
      </button>
    );
  }
}

class CounterWrap extends React.Component {
  render() {
    console.log("CounterWrap render，控制台只会输出一次");
    return <Counter />;
  }
}

class NeverUpdate extends React.Component {
  render() {
    console.log("NeverUpdate render，控制台只会输出一次");
    return <div>永远不会更新</div>;
  }
}

class App extends React.Component {
  constructor(props) {
    super(props);
  }
  shouldComponentUpdate() {
    return false;
  }
  render() {
    console.log("App render，控制台只会输出一次");
    return [<CounterWrap />, <NeverUpdate />];
  }
}

class Home extends React.Component {
  constructor(props) {
    super(props);
    this.addCount = () => {
      console.log("点击按钮触发更新", this.state.count + 1);
      this.setState({
        count: this.state.count + 1,
      });
    };
    this.state = {
      count: 0,
      addCount: this.addCount,
    };
  }

  render() {
    console.log("Home render");
    return (
      <CounterContext.Provider value={this.state}>
        <App />
      </CounterContext.Provider>
    );
  }
}
ReactDOM.render(<Home />, document.getElementById("root"));

App 组件的 shouldComponentUpdate 永远返回 false，理论上 App 组件以及它的所有子组件的 render 在更新的过程中都不会执行，即不会更新。
Counter 组件的 shouldComponentUpdate 永远返回 false，理论上 Counter 也不会更新

但是我们点击按钮，观察控制台可以发现：

第一次渲染时，所有组件都会更新，组件的 render 方法都被执行
在随后的点击过程中，只有 Home 组件以及订阅了 Context 的 Counter 组件更新了，它们对应的 render 方法执行

Home 的更新很容易理解，因为点击按钮触发了它的 state 更新，**那么 Counter 组件是如何跳过父组件 App 以及其自身的 shouldComponentUpdate 强制更新的？**我们稍后再回答这个问题

前面介绍过在updateContextProvider方法中，使用浅比较判断 Provider 的 value 是否变化，如果变化，则调用propagateContextChange查找所有订阅了这个 context 的组件

propagateContextChange 查找算法

以下面的代码为例：

class Home extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 1,
    };
  }

  render() {
    return [
      <CounterContext.Provider id="provider1" value={this.state.count + 1}>
        <div id="wrap">
          <CounterContext.Provider id="provider2" value={2}>
            <Counter id="counter1" />
          </CounterContext.Provider>
          <UserContext.Provider id="userprovider1" value="mike">
            <Counter id="counter2" />
          </UserContext.Provider>
        </div>
        <Counter id="counter3" />
      </CounterContext.Provider>,
      <button
        onClick={() => {
          this.setState({
            count: this.state.count + 1,
          });
        }}
      >
        click
      </button>,
    ];
  }
}

当点击按钮触发更新时，provider1的 value 发生变更，因此调用propagateContextChange开始查找所有订阅了provider1的 context 的 fiber 节点，按以下顺序：

首先是 div#wrap，由于它没有订阅了 CounterContext，因此没有任何操作，继续遍历它的子节点
由于 provider2 和 provider1 是同一个 context，因此不需要继续遍历provider2内部的子节点。

前面介绍过，在嵌套的相同的 Provider 中，里层的会覆盖外层的，因此外层的 Provider 的 value 变化，不会影响到消费组件。只有最里层的 Provider 的 value 变化才会强制消费组件更新。因此就没必要再继续遍历provider2内部的所有节点了。
继续遍历 userprovider1，没有订阅 CounterContext，因此继续遍历couter2，发现counter2订阅了 CounterContext，因此将其标记为更新
- 如果 counter2 是类组件，那么会创建一个更新对象 update，并将 update.tag 标记为强制更新
继续遍历 counter3，发现 counter3 也订阅了 CounterContext

如果找到订阅了 context 的消费组件，则将其 fiber.lane 标记为更新，然后合并到父节点。

比如在我们上面那个例子中，Counter 需要更新，但是 App、CounterWrap、NeverUpdate 都不需要更新，因此这三个 fiber 节点在 beginWork 阶段会直接跳过，然后更新 Counter 组件。

至于怎么标记更新，这涉及到 fiber lane 的知识，就不在本节的讨论范围

可以发现，当有 Provider 的 value 发生变化时，React 会遍历这个 Provider 内部所有的 fiber 节点，找出订阅了这个 Provider 的 context 的 fiber 节点。这个查找的过程也是挺耗时的，特别是组件层级很深时

最后，propagateContextChange 查找算法如下：

function propagateContextChange(
  workInProgress,
  context,
  changedBits,
  renderLanes
) {
  var fiber = workInProgress.child;

  while (fiber !== null) {
    var nextFiber = void 0; // Visit this fiber.

    var list = fiber.dependencies;
    // 首先判断这个fiber是否有dependencies，如果没有，说明这个fiber没有订阅任何context
    if (list !== null) {
      nextFiber = fiber.child;
      var dependency = list.firstContext;
      // 如果这个fiber有订阅context，则判断是否是当前Provider的context
      while (dependency !== null) {
        // 检查context是否匹配
        if (
          dependency.context === context &&
          (dependency.observedBits & changedBits) !== 0
        ) {
          // 匹配到了context，说明这个组件订阅了当前Provider的context，我们需要给这个fiber调度更新
          if (fiber.tag === ClassComponent) {
            // 如果是类组件，则创建一个更新对象update，并标记为强制更新
            var update = createUpdate(
              NoTimestamp,
              pickArbitraryLane(renderLanes)
            );
            update.tag = ForceUpdate;
            // 添加到更新队列
            enqueueUpdate(fiber, update);
          }

          fiber.lanes = mergeLanes(fiber.lanes, renderLanes);
          var alternate = fiber.alternate;

          if (alternate !== null) {
            alternate.lanes = mergeLanes(alternate.lanes, renderLanes);
          }

          scheduleWorkOnParentPath(fiber.return, renderLanes);

          list.lanes = mergeLanes(list.lanes, renderLanes);

          break;
        }

        dependency = dependency.next;
      }
    } else if (fiber.tag === ContextProvider) {
      // 如果是相同的Provider，则不用继续遍历了，因为相同的嵌套的Provider，内部的消费组件取最里层的，外层的Provider变化
      // 和里面的消费组件没啥关系
      nextFiber = fiber.type === workInProgress.type ? null : fiber.child;
    } else {
      // 继续遍历子节点
      nextFiber = fiber.child;
    }

    if (nextFiber === null) {
      // 没有子节点，则继续遍历兄弟节点
      nextFiber = fiber;

      while (nextFiber !== null) {
        if (nextFiber === workInProgress) {
          // 所有fiber节点已经遍历完成，退出
          nextFiber = null;
          break;
        }

        var sibling = nextFiber.sibling;

        if (sibling !== null) {
          nextFiber = sibling;
          break;
        }
        // 如果没有兄弟节点，则查找父节点的兄弟节点
        nextFiber = nextFiber.return;
      }
    }

    fiber = nextFiber;
  }
}

beginWork 强制更新消费组件

在 propagateContextChange 方法中已经找到并标记了消费组件强制更新，那在 beginWork 阶段，react 怎么判断组件要不要更新？

在更新阶段，React 会判断 workInProgress.lanes 和 renderLanes，如果两者不同，说明当前 fiber 不需要更新，调用bailoutOnAlreadyFinishedWork退出。如果两者相同，说明需要更新，则继续执行 beginWork 的逻辑。

beginWork 的判断逻辑如下：

function beginWork(current, workInProgress, renderLanes) {
  var updateLanes = workInProgress.lanes;
  // 在执行beginWork的逻辑前，需要判断当前fiber是否需要更新
  // current为null，说明这个fiber第一次渲染。如果不为null说明是更新阶段
  if (current !== null) {
    var oldProps = current.memoizedProps;
    var newProps = workInProgress.pendingProps;

    if (oldProps !== newProps) {
      // 如果props变更了，将fiber标记为需要更新，即设置didReceiveUpdate为true
      didReceiveUpdate = true;
    } else if (!includesSomeLane(renderLanes, updateLanes)) {
      didReceiveUpdate = false;
      // 当前fiber没有工作，因此提前退出，不需要进入beginWork阶段

      return bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes);
    } else {
      // 当前fiber需要被调度更新，但是props没有变化。设置为false。如果fiber的update queue或者context
      // consumer发生了变化，didReceiveUpdate将被设置为true
      didReceiveUpdate = false;
    }
  } else {
    didReceiveUpdate = false;
  }

  workInProgress.lanes = NoLanes;
  // 开始执行beginWork的逻辑
  switch (workInProgress.tag) {
  }
}

bailoutOnAlreadyFinishedWork 会通过 workInProgress.childLanes 判断当前 fiber 节点的子节点需不需要更新，如果不需要更新，则返回 null，即 beginWork 阶段返回 null，说明当前 fiber 节点可以完成工作了。

如果子节点需要更新，则调用 cloneChildFibers 复用旧的子节点，然后对子节点继续执行 beginWork 开始工作

function bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes) {
  if (!includesSomeLane(renderLanes, workInProgress.childLanes)) {
    // 通过childLanes判断子节点是否有工作，如果没有，则直接返回null
    return null;
  } else {
    // 这个fiber没有工作，但是它的子节点有工作，复制子节点并继续执行beginWork
    cloneChildFibers(current, workInProgress);
    return workInProgress.child;
  }
}

类组件强制更新流程

在 updateClassComponent 中会调用 updateClassInstance 判断组件是否应该更新。在 updateClassInstance 中会判断全局变量 hasForceUpdate 或者组件的 shouldComponentUpdate 的返回值。

这里最关键的是 hasForceUpdate 变量。前面 propagateContextChange 说过，如果类组件订阅了 context，那么会给类组件的 fiber 创建一个 update 对象，并将 update.tag 标记为 ForceUpdate，然后在 processUpdateQueue 处理 update 时，发现 tag 为 ForceUpdate，则将全局变量 hasForceUpdate 设置为 true。这就是 context 发生变化，订阅了 context 的类组件能够跳过 sCU 强制更新的原因

shouldUpdate 为 true，finishClassComponent 会调用类组件的 render 方法走强制更新逻辑

function updateClassComponent(
  current,
  workInProgress,
  Component,
  nextProps,
  renderLanes
) {
  prepareToReadContext(workInProgress, renderLanes);
  var instance = workInProgress.stateNode;
  var shouldUpdate;

  if (instance === null) {
    // 第一次渲染
    shouldUpdate = true;
  } else {
    // 更新阶段
    shouldUpdate = updateClassInstance(
      current,
      workInProgress,
      Component,
      nextProps,
      renderLanes
    );
  }

  var nextUnitOfWork = finishClassComponent(
    current,
    workInProgress,
    Component,
    shouldUpdate,
    hasContext,
    renderLanes
  );

  return nextUnitOfWork;
}

function updateClassInstance(
  current,
  workInProgress,
  ctor,
  newProps,
  renderLanes
) {
  // 省略前面一大段逻辑....
  processUpdateQueue(workInProgress, newProps, instance, renderLanes);
  // ...
  var shouldUpdate =
    hasForceUpdate ||
    instance.shouldComponentUpdate(newProps, newState, nextContext);

  // 省略后面一大段逻辑...
  return shouldUpdate;
}
function finishClassComponent(
  current,
  workInProgress,
  Component,
  shouldUpdate,
  hasContext,
  renderLanes
) {
  // ...
  if (!shouldUpdate) {
    return bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes);
  }
  // 省略后面的一大段逻辑：调用类组件的render方法，执行reconcileChildren协调子元素

  nextChildren = instance.render();
  // ...
  reconcileChildren(current, workInProgress, nextChildren, renderLanes);
  // ....
  return workInProgress.child;
}

函数组件强制更新流程

前面 propagateContextChange 说过，如果组件订阅了 context，不管是函数组件还是类组件，都会将 fiber.lanes 设置为 renderLanes。在 beginWork 阶段，发现 fiber.lanes 等于 renderLanes，则走 beginWork 的逻辑，强制组件更新

如何合理设计全局共享状态

从上面 Provider 的 value 变化，查找所有订阅组件的过程可以看出，每次 Provider 一变化，都要遍历一次，像下面的代码：

<CounterContext.Provider value={this.state.count}>
  <UserContext.Provider value={this.state.count + "mike"}>
    <App />
  </UserContext.Provider>
</CounterContext.Provider>

如果 this.state.count 发生变化，则导致在 beginWork 阶段：

CounterContext.Provider 的 value 发生了变化，则遍历内部所有的 fiber 节点找出消费组件
UserContext.Provider 的 value 也发生了变化，则遍历内部所有的 fiber 节点找出消费组件

如果页面很复杂，组件层级很深数量庞大，遍历树的开销也是很大的。

因此，我们应该尽量少的避免 Provider 的 value 发生变化。避免以下用法：

<Provider store={{ count: 1 }}>
  <ClientApp />
</Provider>

即使 count 值没变，但是每次 render，value 的引用都发生了变化。

React Redux 是如何设计 Provider 的？

React Redux 的 Provider 接收 store，而 store 在创建初期就保持不变，因此 Provider 的 store 在整个应用生命周期内都不会发生改变，也就不会触发订阅的组件重新渲染。

我们通过 dispatch 触发的状态变更，实际上改变的是 store.state，然后通过 useSelector 或者 connect 订阅了状态的组件会强制更新，有兴趣可以参考这里mini-react-redux

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

context源码解析.md

context源码解析.md

学习目标

前言

Context API 简介

React.createContext

Context.Provider

特性 1：Context 默认值的读取

特性 2：多个相同 Provider 可以嵌套使用，里层的会覆盖外层的数据

Context.Provider 源码实现

消费组件如何读取 Context 的值？

readContext 读取 context 最新值

Context.Provider value 变化，React 如何强制更新？

propagateContextChange 查找算法

beginWork 强制更新消费组件

类组件强制更新流程

函数组件强制更新流程

如何合理设计全局共享状态

React Redux 是如何设计 Provider 的？

Files

context源码解析.md

Latest commit

History

context源码解析.md

File metadata and controls

学习目标

前言

Context API 简介

React.createContext

Context.Provider

特性 1：Context 默认值的读取

特性 2：多个相同 Provider 可以嵌套使用，里层的会覆盖外层的数据

Context.Provider 源码实现

消费组件如何读取 Context 的值？

readContext 读取 context 最新值

Context.Provider value 变化，React 如何强制更新？

propagateContextChange 查找算法

beginWork 强制更新消费组件

类组件强制更新流程

函数组件强制更新流程

如何合理设计全局共享状态

React Redux 是如何设计 Provider 的？