點擊進入React源碼調試倉庫。

在React的concurrent模式下，低優(yōu)先級任務執(zhí)行過程中，一旦有更高優(yōu)先級的任務進來，那么這個低優(yōu)先級的任務會被取消，優(yōu)先執(zhí)行高優(yōu)先級任務。等高優(yōu)先級任務做完了，低優(yōu)先級任務會被重新做一遍。

我們用一個具體的例子來理解一下高優(yōu)先級任務插隊。

有這樣一個組件，state為0，進入頁面，會調用setState將state加1，這個作為低優(yōu)先級任務。React開始進行更新，在這個低優(yōu)先級任務尚未完成時，模擬按鈕點擊，state加2，這個作為高優(yōu)先級任務。可以看到，頁面上的數字變化為0 -> 2 -> 3，而不是0 -> 1 -> 3。這就說明，當低優(yōu)先級任務（加1）正在進行時，高優(yōu)先級任務進來了，而它會把state設置為2。由于高優(yōu)先級任務的插隊，設置state為1的低優(yōu)先級任務會被取消，先做高優(yōu)先級任務，所以數字從0變成了2。而高優(yōu)先級任務完成之后，低優(yōu)先級任務會被重做，所以state再從2加到了3。

現象如下：

利用chrome的性能分析工具捕捉更新過程，可以明顯看到優(yōu)先級插隊的過程

完整的profile文件我保存下來了，可以載入到chrome中詳細查看：高優(yōu)先級插隊.json 。

可以再看一下這個過程中兩個任務優(yōu)先級在調度過程中的信息

點擊查看 高優(yōu)先級插隊示例代碼文件。

點擊查看 低優(yōu)先級任務饑餓問題示例代碼文件。

接下來我們就來從setState開始，探討一下這種插隊行為的本質，內容涉及update對象的生成、發(fā)起調度、工作循環(huán)、高優(yōu)任務插隊、update對象的處理、低優(yōu)先級任務重做等內容。

產生更新

當調用setState時，意味著組件對應的fiber節(jié)點產生了一個更新。setState實際上是生成一個update對象，調用enqueueSetState，將這個update對象連接到fiber節(jié)點的updateQueue鏈表中. 

Component.prototype.setState = function(partialState, callback) {  
  this.updater.enqueueSetState(this, partialState, callback, 'setState');  
}; 

enqueueSetState的職責是創(chuàng)建update對象，將它入隊fiber節(jié)點的update鏈表（updateQueue），然后發(fā)起調度。 

enqueueSetState(inst, payload, callback) {  
    // 獲取當前觸發(fā)更新的fiber節(jié)點。inst是組件實例  
    const fiber = getInstance(inst);  
    // eventTime是當前觸發(fā)更新的時間戳  
    const eventTime = requestEventTime();  
    const suspenseConfig = requestCurrentSuspenseConfig();  
    // 獲取本次update的優(yōu)先級  
    const lane = requestUpdateLane(fiber, suspenseConfig);  
    // 創(chuàng)建update對象  
    const update = createUpdate(eventTime, lane, suspenseConfig);  
    // payload就是setState的參數，回調函數或者是對象的形式。  
    // 處理更新時參與計算新狀態(tài)的過程  
    update.payload = payload;  
    // 將update放入fiber的updateQueue  
    enqueueUpdate(fiber, update);  
    // 開始進行調度 
     scheduleUpdateOnFiber(fiber, lane, eventTime);  
  } 

梳理一下enqueueSetState中具體做的事情：

找到fiber

首先獲取產生更新的組件所對應的fiber節(jié)點，因為產生的update對象需要放到fiber節(jié)點的updateQueue上。然后獲取當前這個update產生的時間，這與更新的饑餓問題相關，我們暫且不考慮，而且下一步的suspenseConfig可以先忽略。

計算優(yōu)先級

之后比較重要的是計算當前這個更新它的優(yōu)先級lane： 

const lane = requestUpdateLane(fiber, suspenseConfig); 

計算這個優(yōu)先級的時候，是如何決定根據什么東西去計算呢？這還得從React的合成事件說起。

事件觸發(fā)時，合成事件機制調用scheduler中的runWithPriority函數，目的是以該交互事件對應的事件優(yōu)先級去派發(fā)真正的事件流程。runWithPriority會將事件優(yōu)先級轉化為scheduler內部的優(yōu)先級并記錄下來。當調用requestUpdateLane計算lane的時候，會去獲取scheduler中的優(yōu)先級，以此作為lane計算的依據。

這部分的源碼在這里

創(chuàng)建update對象， 入隊updateQueue

根據lane和eventTime還有suspenseConfig，去創(chuàng)建一個update對象，結構如下： 

const update: Update<*> = {  
  eventTime,  
  lane,  
  suspenseConfig,  
  tag: UpdateState,  
  payload: null,  
  callback: null,  
  next: null,  
}; 

•  eventTime：更新的產生時間
•  lane：表示優(yōu)先級
•  suspenseConfig：任務掛起相關
•  tag：表示更新是哪種類型（UpdateState，ReplaceState，ForceUpdate，CaptureUpdate）
•  payload：更新所攜帶的狀態(tài)。
  •  在類組件中，有兩種可能，對象（{}），和函數（(prevState, nextProps):newState => {}）
  •  根組件中，為React.element，即ReactDOM.render的第一個參數
•  callback：可理解為setState的回調
•  next：指向下一個update的指針

再之后就是去調用React任務執(zhí)行的入口函數：scheduleUpdateOnFiber去調度執(zhí)行更新任務了。

現在我們知道了，產生更新的fiber節(jié)點上會有一個updateQueue，它包含了剛剛產生的update。下面該進入scheduleUpdateOnFiber了，開始進入真正的調度流程。通過調用scheduleUpdateOnFiber，render階段的構建workInProgress樹的任務會被調度執(zhí)行，這個過程中，fiber上的updateQueue會被處理。

調度準備

React的更新入口是scheduleUpdateOnFiber，它區(qū)分update的lane，將同步更新和異步更新分流，讓二者進入各自的流程。但在此之前，它會做幾個比較重要的工作：

•  檢查是否是無限更新，例如在render函數中調用了setState。
•  從產生更新的節(jié)點開始，往上一直循環(huán)到root，目的是將fiber.lanes一直向上收集，收集到父級節(jié)點的childLanes中，childLanes是識別這個fiber子樹是否需要更新的關鍵。
•  在root上標記更新，也就是將update的lane放到root.pendingLanes中，每次渲染的優(yōu)先級基準：renderLanes就是取自root.pendingLanes中最緊急的那一部分lanes。

這三步可以視為更新執(zhí)行前的準備工作。

第1個可以防止死循環(huán)卡死的情況。

第2個，如果fiber.lanes不為空，則說明該fiber節(jié)點有更新，而fiber.childLanes是判斷當前子樹是否有更新的重要依據，若有更新，則繼續(xù)向下構建，否則直接復用已有的fiber樹，就不往下循環(huán)了，可以屏蔽掉那些無需更新的fiber節(jié)點。

第3個是將當前update對象的lane加入到root.pendingLanes中，保證真正開始做更新任務的時候，獲取到update的lane，從而作為本次更新的渲染優(yōu)先級（renderLanes），去更新。

實際上在更新時候獲取到的renderLanes，并不一定包含update對象的lane，因為有可能它只是一個較低優(yōu)先級的更新，有可能在它前面有高優(yōu)先級的更新

梳理完scheduleUpdateOnFiber的大致邏輯之后，我們來看一下它的源碼： 

export function scheduleUpdateOnFiber(  
  fiber: Fiber,  
  lane: Lane,  
  eventTime: number,  
) {  
  // 第一步，檢查是否有無限更新  
  checkForNestedUpdates();  
  ...  
  // 第二步，向上收集fiber.childLanes  
  const root = markUpdateLaneFromFiberToRoot(fiber, lane); 
  ...  
  // 第三步，在root上標記更新，將update的lane放到root.pendingLanes  
  markRootUpdated(root, lane, eventTime);  
  ...  
  // 根據Scheduler的優(yōu)先級獲取到對應的React優(yōu)先級  
  const priorityLevel = getCurrentPriorityLevel();  
  if (lane === SyncLane) {  
    // 本次更新是同步的，例如傳統(tǒng)的同步渲染模式  
    if (  
      (executionContext & LegacyUnbatchedContext) !== NoContext &&  
      (executionContext & (RenderContext | CommitContext)) === NoContext  
    ) {  
      // 如果是本次更新是同步的，并且當前還未渲染，意味著主線程空閑，并沒有React的  
      // 更新任務在執(zhí)行，那么調用performSyncWorkOnRoot開始執(zhí)行同步任務 
       ...  
      performSyncWorkOnRoot(root);  
    } else {  
      // 如果是本次更新是同步的，不過當前有React更新任務正在進行，  
      // 而且因為無法打斷，所以調用ensureRootIsScheduled 
      // 目的是去復用已經在更新的任務，讓這個已有的任務  
      // 把這次更新順便做了  
      ensureRootIsScheduled(root, eventTime); 
      ... 
     }  
  } else {  
    ...  
    // Schedule other updates after in case the callback is sync.  
    // 如果是更新是異步的，調用ensureRootIsScheduled去進入異步調度  
    ensureRootIsScheduled(root, eventTime);  
    schedulePendingInteractions(root, lane);  
  }  
  ...  
} 

    scheduleUpdateOnFiber 的完整源碼在這里，這里是第二步：markUpdateLaneFromFiberToRoot 和 第三步： markRootUpdated的完整源碼，我都做了注釋。

經過了前面的準備工作后，scheduleUpdateOnFiber最終會調用ensureRootIsScheduled，來讓React任務被調度，這是一個非常重要的函數，它關乎同等或較低任務的收斂、

高優(yōu)先級任務插隊和任務饑餓問題，下面詳細講解它。

開始調度

在開始講解ensureRootIsScheduled之前，我們有必要弄清楚React的更新任務的本質。

React任務的本質

一個update的產生最終會使React在內存中根據現有的fiber樹構建一棵新的fiber樹，新的state的計算、diff操作、以及一些生命周期的調用，都會在這個構建過程中進行。這個整體的構建工作被稱為render階段，這個render階段整體就是一個完整的React更新任務，更新任務可以看作執(zhí)行一個函數，這個函數在concurrent模式下就是performConcurrentWorkOnRoot，更新任務的調度可以看成是這個函數被scheduler按照任務優(yōu)先級安排它何時執(zhí)行。

Scheduler的調度和React的調度是兩個完全不同的概念，React的調度是協調任務進入哪種Scheduler的調度模式，它的調度并不涉及任務的執(zhí)行，而Scheduler是調度機制的真正核心，它是實打實地去執(zhí)行任務，沒有它，React的任務再重要也無法執(zhí)行，希望讀者加以區(qū)分這兩種概念。

當一個任務被調度之后，scheduler就會生成一個任務對象（task），它的結構如下所示，除了callback之外暫時不需要關心其他字段的含義。 

var newTask = {  
   id: taskIdCounter++,  
   // 任務函數，也就是 performConcurrentWorkOnRoot  
   callback,  
   // 任務調度優(yōu)先級，由即將講到的任務優(yōu)先級轉化而來  
   priorityLevel,  
   // 任務開始執(zhí)行的時間點  
   startTime,  
   // 任務的過期時間  
   expirationTime,  
   // 在小頂堆任務隊列中排序的依據  
   sortIndex: -1,  
 }; 

每當生成了一個這樣的任務，它就會被掛載到root節(jié)點的callbackNode屬性上，以表示當前已經有任務被調度了，同時會將任務優(yōu)先級存儲到root的callbackPriority上，

表示如果有新的任務進來，必須用它的任務優(yōu)先級和已有任務的優(yōu)先級（root.callbackPriority）比較，來決定是否有必要取消已經有的任務。

所以在調度任務的時候，任務優(yōu)先級是不可或缺的一個重要角色。

任務優(yōu)先級

任務本身是由更新產生的，因此任務優(yōu)先級本質上是和update的優(yōu)先級，即update.lane有關（只是有關，不一定是由它而來）。得出的任務優(yōu)先級屬于lanePriority，它不是update的lane，而且與scheduler內部的調度優(yōu)先級是兩個概念，React中的優(yōu)先級轉化關系可以看我總結過的一篇文章：React中的優(yōu)先級，我們這里只探討任務優(yōu)先級的生成過程。

在 調度準備 的最后提到過，update.lane會被放入root.pendingLanes，隨后會獲取root.pendingLanes中最優(yōu)先級的那些lanes作為renderLanes。任務優(yōu)先級的生成就發(fā)生在計算renderLanes的階段，任務優(yōu)先級其實就是renderLanes對應的lanePriority。因為renderLanes是本次更新的優(yōu)先級基準，所以它對應的lanePriority被作為任務優(yōu)先級來衡量本次更新任務的優(yōu)先級權重理所應當。

root.pendingLanes，包含了當前fiber樹中所有待處理的update的lane。

任務優(yōu)先級有三類：

•  同步優(yōu)先級：React傳統(tǒng)的同步渲染模式產生的更新任務所持有的優(yōu)先級
•  同步批量優(yōu)先級：同步模式到concurrent模式過渡模式：blocking模式（介紹）產生的更新任務所持有的優(yōu)先級
•  concurrent模式下的優(yōu)先級：concurrent模式產生的更新持有的優(yōu)先級

最右面的兩個lane分別為同步優(yōu)先級和同步批量優(yōu)先級，剩下左邊的lane幾乎所有都和concurrent模式有關。 

export const SyncLane: Lane = /*                        */ 0b0000000000000000000000000000001;  
export const SyncBatchedLane: Lane = /*                 */ 0b0000000000000000000000000000010;  
concurrent模式下的lanes：/*                               */ 0b1111111111111111111111111111100; 

計算renderLanes的函數是getNextLanes，生成任務優(yōu)先級的函數是getHighestPriorityLanes

任務優(yōu)先級決定著任務在React中被如何調度，而由任務優(yōu)先級轉化成的任務調度優(yōu)先級（上面給出的scheduler的task結構中的priorityLevel），

決定著Scheduler何時去處理這個任務。

任務調度協調 - ensureRootIsScheduled

目前為止我們了解了任務和任務優(yōu)先級的本質，下面正式進入任務的調度過程。React這邊對任務的調度本質上其實是以任務優(yōu)先級為基準，去操作多個或單個任務。

多個任務的情況，相對于新任務，會對現有任務進行或復用，或取消的操作，單個任務的情況，對任務進行或同步，或異步，或批量同步（暫時不需要關注） 的調度決策，

這種行為可以看成是一種任務調度協調機制，這種協調通過ensureRootIsScheduled去實現。

讓我們看一看ensureRootIsScheduled函數做的事情，先是準備本次任務調度協調所需要的lanes和任務優(yōu)先級，然后判斷是否真的需要調度

•  獲取root.callbackNode，即舊任務
•  檢查任務是否過期，將過期任務放入root.expiredLanes，目的是讓過期任務能夠以同步優(yōu)先級去進入調度（立即執(zhí)行）
•  獲取renderLanes（優(yōu)先從root.expiredLanes獲?。绻鹯enderLanes是空的，說明不需要調度，直接return掉
•  獲取本次任務，即新任務的優(yōu)先級：newCallbackPriority

接下來是協調任務調度的過程：

•  首先判斷是否有必要發(fā)起一次新調度，方法是通過比較新任務的優(yōu)先級和舊任務的優(yōu)先級是否相等：
  •  相等，則說明無需再次發(fā)起一次調度，直接復用舊任務即可，讓舊任務在處理更新的時候順便把新任務給做了。
  •  不相等，則說明新任務的優(yōu)先級一定高于舊任務，這種情況就是高優(yōu)先級任務插隊，需要把舊任務取消掉。
•  真正發(fā)起調度，看新任務的任務優(yōu)先級：
  •  同步優(yōu)先級：調用scheduleSyncCallback去同步執(zhí)行任務。
  •  同步批量執(zhí)行：調用scheduleCallback將任務以立即執(zhí)行的優(yōu)先級去加入調度。
  •  屬于concurrent模式的優(yōu)先級：調用scheduleCallback將任務以上面獲取到的新任務優(yōu)先級去加入調度。

這里有兩點需要說明：

    1.   為什么新舊任務的優(yōu)先級如果不相等，那么新任務的優(yōu)先級一定高于舊任務？

這是因為每次調度去獲取任務優(yōu)先級的時候，都只獲取root.pendingLanes中最緊急的那部分lanes對應的優(yōu)先級，低優(yōu)先級的update持有的lane對應的優(yōu)先級是無法被獲取到的。通過這種辦法，可以將來自同一事件中的多個更新收斂到一個任務中去執(zhí)行，言外之意就是同一個事件觸發(fā)的多次更新的優(yōu)先級是一樣的，沒必要發(fā)起多次任務調度。例如在一個事件中多次調用setState： 

class Demo extends React.Component {  
  state = {  
    count: 0  
  }  
  onClick = () => {  
    this.setState({ count: 1 })  
    this.setState({ count: 2 })  
  }  
  render() {  
    return <button onClick={onClick}>{this.state.count}</button>  
  }  
} 

頁面上會直接顯示出2，雖然onClick事件調用了兩次setState，但只會引起一次調度，設置count為2的那次調度被因為優(yōu)先級與設置count為1的那次任務的優(yōu)先級相同，

所以沒有去再次發(fā)起調度，而是復用了已有任務。這是React17對于多次setState優(yōu)化實現的改變，之前是通過batchingUpdate這種機制實現的。

    1.  三種任務優(yōu)先級的調度模式有何區(qū)別，行為表現上如何？

• 同步優(yōu)先級：傳統(tǒng)的React同步渲染模式和過期任務的調度。通過React提供的scheduleSyncCallback函數將任務函數performSyncWorkOnRoot加入到React自己的同步隊列（syncQueue）中，之后以ImmediateSchedulerPriority的優(yōu)先級將循環(huán)執(zhí)行syncQueue的函數加入到scheduler中，目的是讓任務在下一次事件循環(huán)中被執(zhí)行掉。但是因為React的控制，這種模式下的時間片會在任務都執(zhí)行完之后再去檢查，表現為沒有時間片。
• 同步批量執(zhí)行：同步渲染模式到concurrent渲染模式的過渡模式blocking模式，會將任務函數performSyncWorkOnRoot以ImmediateSchedulerPriority的優(yōu)先級加入到scheduler中，也是讓任務在下一次事件循環(huán)中被執(zhí)行掉，也不會有時間片的表現。
• 屬于concurrent模式的優(yōu)先級：將任務函數performConcurrentWorkOnRoot以任務自己的優(yōu)先級加入到scheduler中，scheduler內部的會通過這個優(yōu)先級控制該任務在scheduler內部任務隊列中的排序，從而決定任務合適被執(zhí)行，而且任務真正執(zhí)行時會有時間片的表現，可以發(fā)揮出scheduler異步可中斷調度的真正威力。

要注意一點，用來做新舊任務比較的優(yōu)先級與這里將任務加入到scheduler中傳入的優(yōu)先級不是一個，后者可由前者通過lanePriorityToSchedulerPriority轉化而來。

經過以上的分析，相信大家已經對ensureRootIsScheduled的運行機制比較清晰了，現在讓我們看一下它的實現： 

function ensureRootIsScheduled(root: FiberRoot, currentTime: number) {  
  // 獲取舊任務  
  const existingCallbackNode = root.callbackNode;  
  // 記錄任務的過期時間，檢查是否有過期任務，有則立即將它放到root.expiredLanes，  
  // 便于接下來將這個任務以同步模式立即調度  
  markStarvedLanesAsExpired(root, currentTime);  
  // 獲取renderLanes  
  const nextLanes = getNextLanes(  
    root,  
    root === workInProgressRoot ? workInProgressRootRenderLanes : NoLanes,  
  );  
  // 獲取renderLanes對應的任務優(yōu)先級  
  const newCallbackPriority = returnNextLanesPriority();  
  if (nextLanes === NoLanes) {  
    // 如果渲染優(yōu)先級為空，則不需要調度  
    if (existingCallbackNode !== null) {  
      cancelCallback(existingCallbackNode);  
      root.callbackNode = null;  
      root.callbackPriority = NoLanePriority;  
    }  
    return;  
  }  
  // 如果存在舊任務，那么看一下能否復用  
  if (existingCallbackNode !== null) {  
    // 獲取舊任務的優(yōu)先級  
    const existingCallbackPriority = root.callbackPriority;  
    // 如果新舊任務的優(yōu)先級相同，則無需調度  
    if (existingCallbackPriority === newCallbackPriority) {  
      return;  
    }  
    // 代碼執(zhí)行到這里說明新任務的優(yōu)先級高于舊任務的優(yōu)先級  
    // 取消掉舊任務，實現高優(yōu)先級任務插隊  
    cancelCallback(existingCallbackNode);  
  }  
  // 調度一個新任務  
  let newCallbackNode;  
  if (newCallbackPriority === SyncLanePriority) {  
    // 若新任務的優(yōu)先級為同步優(yōu)先級，則同步調度，傳統(tǒng)的同步渲染和過期任務會走這里  
    newCallbackNode = scheduleSyncCallback(  
      performSyncWorkOnRoot.bind(null, root),  
    );  
  } else if (newCallbackPriority === SyncBatchedLanePriority) {  
    // 同步模式到concurrent模式的過渡模式：blocking模式會走這里  
    newCallbackNode = scheduleCallback(  
      ImmediateSchedulerPriority,  
      performSyncWorkOnRoot.bind(null, root),  
    );  
  } else {  
    // concurrent模式的渲染會走這里  
    // 根據任務優(yōu)先級獲取Scheduler的調度優(yōu)先級  
    const schedulerPriorityLevel = lanePriorityToSchedulerPriority(  
      newCallbackPriority, 
    );  
    // 計算出調度優(yōu)先級之后，開始讓Scheduler調度React的更新任務  
    newCallbackNode = scheduleCallback(  
      schedulerPriorityLevel,  
      performConcurrentWorkOnRoot.bind(null, root),  
    );  
  }  
  // 更新root上的任務優(yōu)先級和任務，以便下次發(fā)起調度時候可以獲取到  
  root.callbackPriority = newCallbackPriority;  
  root.callbackNode = newCallbackNode;  
} 

ensureRootIsScheduled實際上是在任務調度層面整合了高優(yōu)先級任務的插隊和任務饑餓問題的關鍵邏輯，這只是宏觀層面的決策，決策背后的原因是React處理更新時

對于不同優(yōu)先級的update的取舍以及對root.pendingLanes的標記操作，這需要我們下沉到執(zhí)行更新任務的過程中。

處理更新

一旦有更新產生，update對象就會被放入updateQueue并掛載到fiber節(jié)點上。構建fiber樹時，會帶著renderLanes去處理updateQueue，在beginWork階段，對于類組件

會調用processUpdateQueue函數，逐個處理這個鏈表上的每個update對象，計算新的狀態(tài)，一旦update持有的優(yōu)先級不夠，那么就會跳過這個update的處理，并把這個被跳過的update的lane放到fiber.lanes中，好在completeWork階段收集起來。

循環(huán)updateQueue去計算狀態(tài)的過程實際上較為復雜，因為低優(yōu)先級update會被跳過并且會重做，所以這涉及到最終狀態(tài)統(tǒng)一的問題，關于這一過程的原理解讀在我的這篇文章里：扒一扒React計算狀態(tài)的原理，在本篇文章中只關注優(yōu)先級相關的部分。

關于優(yōu)先級的部分比較好理解，就是只處理優(yōu)先級足夠的update，跳過那些優(yōu)先級不足的update，并且將這些update的lane放到fiber.lanes中。我們直接來看一下實現： 

function processUpdateQueue<State>(  
  workInProgress: Fiber,  
  props: any,  
  instance: any,  
  renderLanes: Lanes,  
): void {  
  ...  
  if (firstBaseUpdate !== null) {  
    let update = firstBaseUpdate;  
    do {  
      const updateupdateLane = update.lane;  
      // isSubsetOfLanes函數的意義是，判斷當前更新的優(yōu)先級（updateLane）  
      // 是否在渲染優(yōu)先級（renderLanes）中如果不在，那么就說明優(yōu)先級不足  
      if (!isSubsetOfLanes(renderLanes, updateLane)) {  
        ...  
        /*  
        *  
        * newLanes會在最后被賦值到workInProgress.lanes上，而它又最終  
        * 會被收集到root.pendingLanes。  
        *  
        * 再次更新時會從root上的pendingLanes中找出應該在本次中更新的優(yōu)先  
        * 級（renderLanes），renderLanes含有本次跳過的優(yōu)先級，再次進入，  
        * processUpdateQueue wip的優(yōu)先級符合要求，被更新掉，低優(yōu)先級任務  
        * 因此被重做  
        * */  
        newLanes = mergeLanes(newLanes, updateLane);  
      } else {  
        // 優(yōu)先級足夠，去計算state  
        ... 
      }  
    } while (true);  
    // 將newLanes賦值給workInProgress.lanes，  
    // 就是將被跳過的update的lane放到fiber.lanes  
    workInProgress.lanes = newLanes; 
  }  
} 

只處理優(yōu)先級足夠的update是讓高優(yōu)先級任務被執(zhí)行掉的最本質原因，在循環(huán)了一次updateQueue之后，那些被跳過的update的lane又被放入了fiber.lanes，現在，只需要將它放到root.pendingLanes中，就能表示在本輪更新后，仍然有任務未被處理，從而實現低優(yōu)先級任務被重新調度。所以接下來的過程就是fiber節(jié)點的完成階段：completeWork階段去收集這些lanes。

收集未被處理的lane

在completeUnitOfWork的時候，fiber.lanes 和 childLanes被一層一層收集到父級fiber的childLanes中，該過程發(fā)生在completeUnitOfWork函數中調用的resetChildLanes，它循環(huán)fiber節(jié)點的子樹，將子節(jié)點及其兄弟節(jié)點中的lanes和childLanes收集到當前正在complete階段的fiber節(jié)點上的childLanes。

假設第3層中的<List/>和<Table/>組件都分別有update因為優(yōu)先級不夠而被跳過，那么在它們父級的div fiber節(jié)點completeUnitOfWork的時候，會調用resetChildLanes

把它倆的lanes收集到div fiber.childLanes中，最終把所有的lanes收集到root.pendingLanes.   

                               root（pendingLanes: 0b01110）  
                                   |  
1                                  App  
                                   |  
                                   |  
2 compeleteUnitOfWork-----------> div （childLanes: 0b01110）  
                                   /  
                                  /  
3                              <List/> ---------> <Table/> --------> p  
                          （lanes: 0b00010）   （lanes: 0b00100）  
                       （childLanes: 0b01000）       /  
                               /                   /  
                              /                   /  
4                            p                   ul  
                                                /  
                                               /  
                                              li ------> li 

在每一次往上循環(huán)的時候，都會調用resetChildLanes，目的是將fiber.childLanes層層收集。 

function completeUnitOfWork(unitOfWork: Fiber): void {  
  // 已經結束beginWork階段的fiber節(jié)點被稱為completedWork  
  let completedWork = unitOfWork;  
  do {  
    // 向上一直循環(huán)到root的過程  
    ...  
    // fiber節(jié)點的.flags上沒有Incomplete，說明是正常完成了工作  
    if ((completedWork.flags & Incomplete) === NoFlags) {  
      ...  
      // 調用resetChildLanes去收集lanes  
      resetChildLanes(completedWork);  
      ...  
    } else {/*...*/}  
    ...  
  } while (completedWork !== null);  
  ...  
} 

resetChildLanes中只收集當前正在complete的fiber節(jié)點的子節(jié)點和兄弟節(jié)點的lanes以及childLanes： 

function resetChildLanes(completedWork: Fiber) {  
  ...  
  let newChildLanes = NoLanes;  
  if (enableProfilerTimer && (completedWork.mode & ProfileMode) !== NoMode) {  
    // profile相關，無需關注  
  } else {  
    // 循環(huán)子節(jié)點和兄弟節(jié)點，收集lanes  
    let child = completedWork.child;  
    while (child !== null) {  
      // 收集過程  
      newChildLanes = mergeLanes(  
        newChildLanes,  
        mergeLanes(child.lanes, child.childLanes),  
      );  
      childchild = child.sibling;  
    }  
  }  
  // 將收集到的lanes放到該fiber節(jié)點的childLanes中  
  completedWork.childLanes = newChildLanes;  
} 

最后將這些收集到的childLanes放到root.pendingLanes的過程，是發(fā)生在本次更新的commit階段中，因為render階段的渲染優(yōu)先級來自root.pendingLanes，不能隨意地修改它。所以要在render階段之后的commit階段去修改。我們看一下commitRootImpl中這個過程的實現： 

function commitRootImpl(root, renderPriorityLevel) {  
  // 將收集到的childLanes，連同root自己的lanes，一并賦值給remainingLanes  
  let remainingLanes = mergeLanes(finishedWork.lanes, finishedWork.childLanes);  
  // markRootFinished中會將remainingLanes賦值給remainingLanes  
  markRootFinished(root, remainingLanes);  
  ...  
} 

重新發(fā)起調度

至此，我們將低優(yōu)先級任務的lane重新收集到了root.pendingLanes中，這時只需要再發(fā)起一次調度就可以了，通過在commit階段再次調用ensureRootIsScheduled去實現，這樣就又會走一遍調度的流程，低優(yōu)先級任務被執(zhí)行。 

function commitRootImpl(root, renderPriorityLevel) {  
  // 將收集到的childLanes，連同root自己的lanes，一并賦值給remainingLanes  
  let remainingLanes = mergeLanes(finishedWork.lanes, finishedWork.childLanes);  
  // markRootFinished中會將remainingLanes賦值給remainingLanes  
  markRootFinished(root, remainingLanes);  
  ...  
  // 在每次所有更新完成的時候都會調用這個ensureRootIsScheduled  
  // 以保證root上任何的pendingLanes都能被處理  
  ensureRootIsScheduled(root, now());  
} 

總結

高優(yōu)先級任務插隊，低優(yōu)先級任務重做的整個過程共有四個關鍵點：

•  ensureRootIsScheduled取消已有的低優(yōu)先級更新任務，重新調度一個任務去做高優(yōu)先級更新，并以root.pendingLanes中最重要的那部分lanes作為渲染優(yōu)先級
•  執(zhí)行更新任務時跳過updateQueue中的低優(yōu)先級update，并將它的lane標記到fiber.lanes中。
•  fiber節(jié)點的complete階段收集fiber.lanes到父級fiber的childLanes，一直到root。
•  commit階段將所有root.childLanes連同root.lanes一并賦值給root.pendingLanes。
•  commit階段的最后重新發(fā)起調度。

整個流程始終以高優(yōu)先級任務為重，顧全大局，最能夠體現React提升用戶體驗的決心。