react源码分析之-setState是异步仍是同步?

本文转载自:微信公众号 方凳雅集

写在前面的话


setState是React很重要的模块, 社区中也有不少分析文章,大多强调setState是异步更新,但有些文章分析又说某些状况下是同步更新,那究竟是同步仍是异步呢,这篇文章仍是基于15.x进行的分析,16.x的分析等后面用机会再分享。html

咱们看一下React官网对setState的说明:react


官网也没说setState究竟是同步仍是异步,只是说React不保证setState以后可以当即拿到改变后的结果。算法


咱们先看一个经典例子数组


Demo


// demo.js
class Demo extends PureComponent {
  state={
    count: 0,
  }
  componentDidMount() {
    console.log('pre state', this.state.count);
    this.setState({
      count: this.state.count + 1
    });
    console.log('next state', this.state.count);

    //测试setTimeout
    setTimeout(() => {
      console.log('setTimeout pre state', this.state.count);
      this.setState({
        count: this.state.count + 1
      });
      console.log('setTimeout next state', this.state.count);
    }, 0);
  }

  onClick = (event) => {
    // 测试合成函数中setState
    console.log(`${event.type} pre state`, this.state.count);
    this.setState({
      count: this.state.count + 1
    });
    console.log(`${event.type} next state`, this.state.count);
  }

  render() {
    return <button onClick={this.onClick}>count+1</button>
  }
}复制代码


这里有三种方法调用setState:浏览器


  • 在componentDidMount中直接调用setState;
  • 在componentDidMount的setTimeout方法里调用setState;
  • 在dom中绑定onClick(React的合成函数:抹平不一样浏览器和端的差别)直接调用setState;


从控制台打印出来的结果看,方法1和3直接调用setState是异步的,而方法2中setTimeout调用setState证实了同步,到底为何呢?这两种调用方式有什么区别嘛?接下来咱们从源码进行分析。bash


源码分析


setState入口函数


//ReactComponent.js
ReactComponent.prototype.setState = function (partialState, callback) {
  !(typeof partialState === 'object' || typeof partialState === 'function' || partialState == null) ? "development" !== 'production' ? invariant(false, 'setState(...): takes an object of state variables to update or a ' + 'function which returns an object of state variables.') : invariant(false) : undefined;
  if ("development" !== 'production') {
    "development" !== 'production' ? warning(partialState != null, 'setState(...): You passed an undefined or null state object; ' + 'instead, use forceUpdate().') : undefined;
  }
  
  this.updater.enqueueSetState(this, partialState);
  if (callback) {
    this.updater.enqueueCallback(this, callback);
  }
};

//ReactUpdateQueue.js
enqueueSetState: function(publicInstance, partialState) {
  // 根据 this.setState 中的 this 拿到内部实例, 也就是组件实例
  var internalInstance = getInternalInstanceReadyForUpdate(
    publicInstance,
    'setState'
  );

  if (!internalInstance) {
    return;
  }

  //取得组件实例的_pendingStateQueue
  var queue =
    internalInstance._pendingStateQueue ||
    (internalInstance._pendingStateQueue = []);
  //将partial state存到_pendingStateQueue
  queue.push(partialState);
  //唤起enqueueUpdate
  enqueueUpdate(internalInstance);
};
...

function enqueueUpdate(internalInstance) {
  ReactUpdates.enqueueUpdate(internalInstance);
}复制代码


在setState函数中调用enqueueSetState, 拿到内部组件实例, 而后把要更新的partial state存到其_pendingStateQueue中,至此,setState调用方法执行结束,接下来是setState调用以后的动做。微信


调用 setState 后发生了什么?


setState调用以后执行方法enqueueUpdateapp


//ReactUpdates.js
function enqueueUpdate(component) {
  //注入默认策略,开启ReactReconcileTransaction事务
  ensureInjected();
  
  // 若是没有开启batch(或当前batch已结束)就开启一次batch再执行, 这一般发生在异步回调中调用 setState
  //batchingStrategy:批量更新策略,经过事务的方式实现state的批量更新
  if (!batchingStrategy.isBatchingUpdates) {
    batchingStrategy.batchedUpdates(enqueueUpdate, component);
    return;
  }
  // 若是batch已经开启,则将该组件保存在 dirtyComponents 中存储更新
  dirtyComponents.push(component);
}复制代码


上面demo对setState三次调用结果之因此不一样,应该是这里的判断逻辑致使的:dom


  • 1和3的调用走的是isBatchingUpdates === true分支,没有执行更新操做;
  • 2的setTimeout走的是isBatchingUpdates === false分支,执行更新;


isBatchingUpdates是事务batchingStrategy的一个标记,若是为true,把当前调用setState的组件放入dirtyComponents数组中,作存储处理,不会当即更新,若是为false,将enqueueUpdate做为参数传入batchedUpdates方法中,在batchedUpdates中执行更新操做。异步

但是事务batchingStrategy究竟是作什么的呢?batchedUpdates又作了什么处理?咱们看一下它的源码


//ReactDefaultBatchingStrategy.js
var transaction = new ReactDefaultBatchingStrategyTransaction();// 实例化事务

var ReactDefaultBatchingStrategy = {
  isBatchingUpdates: false,

  batchedUpdates: function(callback, a, b, c, d, e) {
    var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates;
    // 开启一次batch
    ReactDefaultBatchingStrategy.isBatchingUpdates = true;

    if (alreadyBatchingUpdates) {
      callback(a, b, c, d, e);
    } else {
      // 启动事务, 将callback放进事务里执行
      transaction.perform(callback, null, a, b, c, d, e);
    } 
  },
};
//说明:这里使用到了事务transaction,简单来讲,transaction就是将须要执行的方法使用 wrapper 封装起来,
//再经过事务提供的 perform 方法执行。而在 perform 以前,先执行全部 wrapper 中的 initialize 方法,
//执行完 perform 以后(即执行method 方法后)再执行全部的 close 方法。
//一组 initialize 及 close 方法称为一个 wrapper。事务支持多个 wrapper 叠加,嵌套,
//若是当前事务中引入了另外一个事务B,则会在事务B完成以后再回到当前事务中执行close方法。复制代码


(上面涉及到了事务,事务的具体分析有兴趣能够看文章最后)

ReactDefaultBatchingStrategy就是一个批量更新策略事务, isBatchingUpdates默认是false,而batchedUpdates方法被调用时才会将属性isBatchingUpdates设置为true,代表目前处于批量更新流中;但是上面demo中1和3执行到判断逻辑以前源码分析中没见到有batchedUpdates方法调用,那batchedUpdates何时被调用的呢?

全局搜索React中调用batchedUpdates的地方不少,分析后发现与更新流程相关的只有两个地方:


// ReactMount.js
  _renderNewRootComponent: function(nextElement,container,shouldReuseMarkup,context) {
    ...
    // 实例化组件
    var componentInstance = instantiateReactComponent(nextElement, null);
    //初始渲染是同步的,但在渲染期间发生的任何更新,在componentWillMount或componentDidMount中,将根据当前的批处理策略进行批处理
    ReactUpdates.batchedUpdates(
      batchedMountComponentIntoNode,
      componentInstance,
      container,
      shouldReuseMarkup,
      context
    );
   ...
  },
// ReactEventListener.js
dispatchEvent: function (topLevelType, nativeEvent) {
    ...
    try {
      // 处理事件
      ReactUpdates.batchedUpdates(handleTopLevelImpl, bookKeeping);
    } finally {
      TopLevelCallbackBookKeeping.release(bookKeeping);
    }
  }复制代码


  • 第一种状况,是在首次渲染组件时调用batchedUpdates,开启一次batch。由于组件在渲染的过程当中, 会依顺序调用各类生命周期函数, 开发者极可能在生命周期函数中(如componentWillMount或者componentDidMount)调用setState. 所以, 开启一次batch就是要存储更新(放入dirtyComponents), 而后在事务结束时批量更新. 这样以来, 在初始渲染流程中, 任何setState都会生效, 用户看到的始终是最新的状态
  • 第二种状况,若是在组件上绑定了事件,在绑定事件中颇有可能触发setState,因此为了存储更新(dirtyComponents),须要开启批量更新策略。在回调函数被调用以前, React事件系统中的dispatchEvent函数负责事件的分发, 在dispatchEvent中启动了事务, 开启了一次batch, 随后调用了回调函数. 这样一来, 在事件的监听函数中调用的setState就会生效.
    这里借用《深刻REACT技术栈》文章里的一个在componentDidMount中setState的调用栈图例


图例中代表,ReactDefaultBatchingStrategy.batchedUpdates在ReactMount.

renderNewRootComponent中被调用,依次倒推,最后发如今组件首次渲染时就会经过injectBatchingStrategy()方法注入ReactDefaultBatchingStrategy(这部分有兴趣能够看一下ReactDefaultInjection.js源码),而且在ReactMount.render中触发

renderNewRootComponent函数,调用batchedUpdates将isBatchingUpdates设置为了true,因此componentDidMount的执行都是在一个大的事务ReactDefaultBatchingStrategyTransaction中。


这就解释了在componentDidMount中调用setState并不会当即更新state,由于正处于一个这个大的事务中,isBatchingUpdates此时为true,因此只会放入dirtyComponents中等待稍后更新。


state何时批量更新呢?


追踪代码后我画了一个组件初次渲染和setState后简单的事务启动和执行的顺序:


从上面的图中能够看到,ReactDefaultBatchingStrategy就是一个批量更新策略事务,控制了批量策略的生命周期。看一下ReactDefaultBatchingStrategy源码分析一下事务中执行了什么:


// ReactDefaultBatchingStrategy.js
var RESET_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: function() {
    ReactDefaultBatchingStrategy.isBatchingUpdates = false;
  },
};

var FLUSH_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates),
};

var TRANSACTION_WRAPPERS = [FLUSH_BATCHED_UPDATES, RESET_BATCHED_UPDATES];复制代码


  • 在事务的close阶段执行了flushBatchedUpdates函数,flushBatchedUpdates执行完以后再将ReactDefaultBatchingStrategy.isBatchingUpdates重置为false,表示此次batch更新结束。
  • flushBatchedUpdates函数启动ReactUpdatesFlushTransaction事务,这个事务开启了批量更新,执行runBatchedUpdates对dirtyComponents循环处理。


怎么批量更新的呢?


批量更新flushBatchedUpdates中,看一下源码


// ReactUpdates.js
var flushBatchedUpdates = function() {
  // 开启批量更新
  while (dirtyComponents.length || asapEnqueued) {
    if (dirtyComponents.length) {
      var transaction = ReactUpdatesFlushTransaction.getPooled();
      transaction.perform(runBatchedUpdates, null, transaction);
      ReactUpdatesFlushTransaction.release(transaction);
    }
    // 批量处理callback
    if (asapEnqueued) {
      asapEnqueued = false;
      var queue = asapCallbackQueue;
      asapCallbackQueue = CallbackQueue.getPooled();
      queue.notifyAll();
      CallbackQueue.release(queue);
    }
  }
};复制代码


flushBatchedUpdates开启事务ReactUpdatesFlushTransaction, 执行runBatchedUpdates,


// ReactUpdates.js
function runBatchedUpdates(transaction) {
  var len = transaction.dirtyComponentsLength;
  // 排序保证父组件优于子组件更新
  dirtyComponents.sort(mountOrderComparator);
  // 遍历dirtyComponents
  for (var i = 0; i < len; i++) {
    var component = dirtyComponents[i];
    var callbacks = component._pendingCallbacks;
    component._pendingCallbacks = null;
    // 执行更新操做
    ReactReconciler.performUpdateIfNecessary(
      component,
      transaction.reconcileTransaction
    );
    // 存储callbacks
    if (callbacks) {
      for (var j = 0; j < callbacks.length; j++) {
        transaction.callbackQueue.enqueue(
          callbacks[j],
          component.getPublicInstance()
        );
      }
    }
  }
}复制代码


接下来就是ReactReconciler调用组件实例的performUpdateIfNecessary方法,这里只分析ReacrCompositeComponent实例,若是接收了props,就会调用receiveComponent方法,在该方法里调用updateComponent方法;若是有新的要更新的状态(_pendingStateQueue不为空)也会直接调用updateComponent来更新


// ReactCompositeComponent.js
performUpdateIfNecessary: function(transaction) {
    if (this._pendingElement != null) {
      ReactReconciler.receiveComponent(
        this,
        this._pendingElement || this._currentElement,
        transaction,
        this._context
      );
    }
    // 待更新state队列不为空或者_pendingForceUpdate为true
    if (this._pendingStateQueue !== null || this._pendingForceUpdate) {
      this.updateComponent(
        transaction,
        this._currentElement,
        this._currentElement,
        this._context,
        this._context
      );
    }
  },复制代码


调用组件实例中的updateComponent,这块代码是组件更新机制的核心,负责管理生命周期中的componentWillReceiveProps、shouldComponentUpdate、componentWillUpdate、render 和 componentDidUpdate;

这段代码比较多,集中在ReactCompositeComponent.js文件中,


若是不想看源码能够直接看后面的代码流程图


//ReactCompositeComponent.js
updateComponent: function(
    transaction,
    prevParentElement,
    nextParentElement,
    prevUnmaskedContext,
    nextUnmaskedContext
  ) {
    var inst = this._instance;

    var nextContext = this._context === nextUnmaskedContext ?
      inst.context :
      this._processContext(nextUnmaskedContext);
    var nextProps;

    // Distinguish between a props update versus a simple state update
    if (prevParentElement === nextParentElement) {
      // Skip checking prop types again -- we don't read inst.props to avoid // warning for DOM component props in this upgrade nextProps = nextParentElement.props; } else { nextProps = this._processProps(nextParentElement.props); // 若是有接收新的props,执行componentWillReceiveProps 方法, if (inst.componentWillReceiveProps) { inst.componentWillReceiveProps(nextProps, nextContext); } } // 合并props var nextState = this._processPendingState(nextProps, nextContext); // 执行shouldComponentUpdate判断是否须要更新 var shouldUpdate = this._pendingForceUpdate || !inst.shouldComponentUpdate || inst.shouldComponentUpdate(nextProps, nextState, nextContext); ... // 若是须要更新执行_performComponentUpdate,不然只将当前的props和state保存下来,不作更新 if (shouldUpdate) { this._pendingForceUpdate = false; // Will set `this.props`, `this.state` and `this.context`. this._performComponentUpdate( nextParentElement, nextProps, nextState, nextContext, transaction, nextUnmaskedContext ); } else { this._currentElement = nextParentElement; this._context = nextUnmaskedContext; inst.props = nextProps; inst.state = nextState; inst.context = nextContext; } }, ... // 执行componentWillUpdate _performComponentUpdate: function( nextElement, nextProps, nextState, nextContext, transaction, unmaskedContext ) { var inst = this._instance; var hasComponentDidUpdate = Boolean(inst.componentDidUpdate); var prevProps; var prevState; var prevContext; if (hasComponentDidUpdate) { prevProps = inst.props; prevState = inst.state; prevContext = inst.context; } if (inst.componentWillUpdate) { inst.componentWillUpdate(nextProps, nextState, nextContext); } this._currentElement = nextElement; this._context = unmaskedContext; inst.props = nextProps; inst.state = nextState; inst.context = nextContext; this._updateRenderedComponent(transaction, unmaskedContext); if (hasComponentDidUpdate) { transaction.getReactMountReady().enqueue( inst.componentDidUpdate.bind(inst, prevProps, prevState, prevContext), inst ); } } // 执行unmountComponent,_instantiateReactComponent, mountComponent、render _updateRenderedComponent: function(transaction, context) { var prevComponentInstance = this._renderedComponent; var prevRenderedElement = prevComponentInstance._currentElement; var nextRenderedElement = this._renderValidatedComponent(); // 若是prevRenderedElement, nextRenderedElement相等只执行receiveComponent if (shouldUpdateReactComponent(prevRenderedElement, nextRenderedElement)) { ReactReconciler.receiveComponent( prevComponentInstance, nextRenderedElement, transaction, this._processChildContext(context) ); } else { // prevRenderedElement, nextRenderedElement不相等,则执行旧组件的unmountComponent var oldNativeNode = ReactReconciler.getNativeNode(prevComponentInstance); ReactReconciler.unmountComponent(prevComponentInstance); this._renderedNodeType = ReactNodeTypes.getType(nextRenderedElement); // 组件实例化_instantiateReactComponent this._renderedComponent = this._instantiateReactComponent( nextRenderedElement ); // 组件挂载 var nextMarkup = ReactReconciler.mountComponent( this._renderedComponent, transaction, this._nativeParent, this._nativeContainerInfo, this._processChildContext(context) ); // 新组件替换旧组件 this._replaceNodeWithMarkup(oldNativeNode, nextMarkup); } },复制代码


updateComponent流程图




demo扩展


上面分析了一个很经典的demo,下面看一下原生事件和async事件中setState调用后的表现。


绑定原生事件,调用setState


class Button extends PureComponent {
  state={
    count: 0,
    val: 0
  }
  componentDidMount() {
    // 测试原生方法:手动绑定mousedown事件
    console.log('mousedown pre state', this.state.count);
    ReactDOM.findDOMNode(this).addEventListener(
      "mousedown",
      this.onClick.bind(this)
    );
    console.log('mousedown pre state', this.state.count);
  }

 onClick(event) {
    console.log(`${event.type} pre state`, this.state.count);
    this.setState({
      count: this.state.count + 1
    });
    console.log(`${event.type} next state`, this.state.count);
  }

  render() {
    return <button onClick={this.onClick.bind(this)}>count+1</button>
  }
}复制代码


控制台



async函数和sleep函数


class Button extends PureComponent {
  state={
    count: 0,
    val: 0
  }
  async componentDidMount() {
    // 测试async函数中setState
    for(let i = 0; i < 1; i++){
      console.log('sleep pre state', this.state.count);
      await sleep(0);
      this.setState({
        count: this.state.count + 1
      });
      console.log('sleep next state', this.state.count);
    }
  }

  asyncClick = () => {
    this.setState({
      count: this.state.count + 1
    });
  }

  async onClick(event) {
    const type = event.type;
    console.log(`${type} pre state`, this.state.count);
    await this.asyncClick();
    console.log(`${type} next state`, this.state.count);
  }

  render() {
    return <button onClick={this.onClick.bind(this)}>count+1</button>
  }
}复制代码


控制台



结论


  • setState在生命周期函数和合成函数中都是异步更新。
  • setState在steTimeout、原生事件和async函数中都是同步更新。
    每次更新不表明都会触发render,若是render内容与newState有关联,则会触发,不然即使setState屡次也不会render
  • 若是newState内容与render有依赖关系,就不建议同步更新,由于每次render都会完整的执行一次批量更新流程(只是dirtyComponets长度为1,stateQueue也只有该组件的newState),调用一次diff算法,这样会影响React性能。
  • 若是没有必须同步渲染的理由,不建议使用同步,会影响react渲染性能


总结


React整个更新机制到处包含着事务,总的来讲,组件的更新机制依靠事务进行批量更新;


  • 一次batch(批量)的生命周期就是从ReactDefaultBatchingStrategy事务perform以前(调用ReactUpdates.batchUpdates)到这个事务的最后一个close方法调用后结束;
  • 事务启动后, 遇到 setState 则将 partial state 存到组件实例的_pendingStateQueue上, 而后将这个组件存到dirtyComponents 数组中, 等到 ReactDefaultBatchingStrategy事务结束时调用runBatchedUpdates批量更新全部组件;
  • 组件的更新是递归的, 三种不一样类型的组件都有本身的updateComponent方法来决定本身的组件如何更新, 其中 ReactDOMComponent 会采用diff算法对比子元素中最小的变化, 再批量处理.
  • 生命周期函数和合成函数中调用setState表现异步更新,是由于组件初始化和调用合成函数时都会触发ReactDefaultBatchingStrategy事务的batchUpdates方法,将批量更新标记设置为true,因此后面的setState都会存储到dirtyComponents中,执行批量更新以后再将标志设置为false;
  • setTimeout、原生事件和async函数中调用setState表现同步更新,是由于遇到这些函数时不会触发
    ReactDefaultBatchingStrategy事务的batchUpdates方法,因此批量更新标记依旧时false,因此表现为同步。


补充:transaction事务介绍


React 的事务机制比较简单,包括三个阶段,initialize、perform和close,而且事务之间支持叠加。

事务提供了一个 mixin 方法供其余模块实现本身须要的事务。而要使用事务的模块,除了须要把 mixin 混入本身的事务实现中外,还要额外实现一个抽象的 getTransactionWrappers 接口。这个接口用来获取全部须要封装的前置方法(initialize)和收尾方法(close),

所以它须要返回一个数组的对象,每一个对象分别有 key 为 initialize 和 close 的方法。


这里看一个《深刻React技术栈》文章中的例子就比较好理解了


var Transaction = require('./Transaction');
// 咱们本身定义的事务
var MyTransaction = function() {
// ... };
Object.assign(MyTransaction.prototype, Transaction.Mixin, { getTransactionWrappers: function() {
  return [{
    initialize: function() {
    console.log('before method perform'); },
    close: function() {
    console.log('after method perform');
    } 
  }];
 }; 
});
var transaction = new MyTransaction(); var testMethod = function() {
console.log('test'); }
transaction.perform(testMethod);
  
// 打印的结果以下:
// before method perform // test
// after method perform复制代码
相关文章
相关标签/搜索