標籤: 如何寫文案

熟悉React的朋友都知道，React支持jsx語法，我們可以直接將HTML代碼寫到JS中間，然後渲染到頁面上，我們寫的HTML如果有更新的話，React還有虛擬DOM的對比，只更新變化的部分，而不重新渲染整個頁面，大大提高渲染效率。到了16.x，React更是使用了一個被稱為Fiber的架構，提升了用戶體驗，同時還引入了hooks等特性。那隱藏在React背後的原理是怎樣的呢，Fiber和hooks又是怎麼實現的呢？本文會從jsx入手，手寫一個簡易版的React，從而深入理解React的原理。

本文主要實現了這些功能:

簡易版Fiber架構

簡易版DIFF算法

簡易版函數組件

簡易版Hook: useState

娛樂版Class組件

本文代碼地址：https://github.com/dennis-jiang/Front-End-Knowledges/tree/master/Examples/React/fiber-and-hooks

本文程序跑起來效果如下：

JSX和creatElement

以前我們寫React要支持JSX還需要一個庫叫JSXTransformer.js，後來JSX的轉換工作都集成到了babel裏面了，babel還提供了在線預覽的功能，可以看到轉換后的效果，比如下面這段簡單的代碼:

const App =
(
  <div>
    <h1 id="title">Title</h1>
    <a href="xxx">Jump</a>
    <section>
      <p>
        Article
      </p>
    </section>
  </div>
);

經過babel轉換后就變成了這樣：

上面的截圖可以看出我們寫的HTML被轉換成了React.createElement，我們將上面代碼稍微格式化來看下：

var App = React.createElement(
  'div',
  null,
  React.createElement(
    'h1',
    {
      id: 'title',
    },
    'Title',
  ),
  React.createElement(
    'a',
    {
      href: 'xxx',
    },
    'Jump',
  ),
  React.createElement(
    'section',
    null,
    React.createElement('p', null, 'Article'),
  ),
);

從轉換后的代碼我們可以看出React.createElement支持多個參數:

1. type，也就是節點類型
2. config, 這是節點上的屬性，比如id和href
3. children, 從第三個參數開始就全部是children也就是子元素了，子元素可以有多個，類型可以是簡單的文本，也可以還是React.createElement，如果是React.createElement，其實就是子節點了，子節點下面還可以有子節點。這樣就用React.createElement的嵌套關係實現了HTML節點的樹形結構。

讓我們來完整看下這個簡單的React頁面代碼：

渲染在頁面上是這樣：

這裏面用到了React的地方其實就兩個，一個是JSX，也就是React.createElement，另一個就是ReactDOM.render，所以我們手寫的第一個目標就有了，就是createElement和render這兩個方法。

手寫createElement

對於<h1 id="title">Title</h1>這樣一個簡單的節點，原生DOM也會附加一大堆屬性和方法在上面，所以我們在createElement的時候最好能將它轉換為一種比較簡單的數據結構，只包含我們需要的元素，比如這樣：

{
  type: 'h1',
  props: {
    id: 'title',
    children: 'Title'
  }
}

有了這個數據結構后，我們對於DOM的操作其實可以轉化為對這個數據結構的操作，新老DOM的對比其實也可以轉化為這個數據結構的對比，這樣我們就不需要每次操作都去渲染頁面，而是等到需要渲染的時候才將這個數據結構渲染到頁面上。這其實就是虛擬DOM！而我們createElement就是負責來構建這個虛擬DOM的方法，下面我們來實現下：

function createElement(type, props, ...children) {
  // 核心邏輯不複雜，將參數都塞到一個對象上返回就行
  // children也要放到props裏面去，這樣我們在組件裏面就能通過this.props.children拿到子元素
  return {
    type,
    props: {
      ...props,
      children
    }
  }
}

上述代碼是React的createElement簡化版，對源碼感興趣的朋友可以看這裏：https://github.com/facebook/react/blob/60016c448bb7d19fc989acd05dda5aca2e124381/packages/react/src/ReactElement.js#L348

手寫render

上述代碼我們用createElement將JSX代碼轉換成了虛擬DOM，那真正將它渲染到頁面的函數是render，所以我們還需要實現下這個方法，通過我們一般的用法ReactDOM.render( <App />,document.getElementById('root'));可以知道他接收兩個參數：

1. 根組件，其實是一個JSX組件，也就是一個createElement返回的虛擬DOM
2. 父節點，也就是我們要將這個虛擬DOM渲染的位置

有了這兩個參數，我們來實現下render方法：

function render(vDom, container) {
  let dom;
  // 檢查當前節點是文本還是對象
  if(typeof vDom !== 'object') {
    dom = document.createTextNode(vDom)
  } else {
    dom = document.createElement(vDom.type);
  }

  // 將vDom上除了children外的屬性都掛載到真正的DOM上去
  if(vDom.props) {
    Object.keys(vDom.props)
      .filter(key => key != 'children')
      .forEach(item => {
        dom[item] = vDom.props[item];
      })
  }
  
  // 如果還有子元素，遞歸調用
  if(vDom.props && vDom.props.children && vDom.props.children.length) {
    vDom.props.children.forEach(child => render(child, dom));
  }

  container.appendChild(dom);
}

上述代碼是簡化版的render方法，對源碼感興趣的朋友可以看這裏：https://github.com/facebook/react/blob/3e94bce765d355d74f6a60feb4addb6d196e3482/packages/react-dom/src/client/ReactDOMLegacy.js#L287

現在我們可以用自己寫的createElement和render來替換原生的方法了：

可以得到一樣的渲染結果：

為什麼需要Fiber

上面我們簡單的實現了虛擬DOM渲染到頁面上的代碼，這部分工作被React官方稱為renderer，renderer是第三方可以自己實現的一個模塊，還有個核心模塊叫做reconsiler，reconsiler的一大功能就是大家熟知的diff，他會計算出應該更新哪些頁面節點，然後將需要更新的節點虛擬DOM傳遞給renderer，renderer負責將這些節點渲染到頁面上。但是這個流程有個問題，雖然React的diff算法是經過優化的，但是他卻是同步的，renderer負責操作DOM的appendChild等API也是同步的，也就是說如果有大量節點需要更新，JS線程的運行時間可能會比較長，在這段時間瀏覽器是不會響應其他事件的，因為JS線程和GUI線程是互斥的，JS運行時頁面就不會響應，這個時間太長了，用戶就可能看到卡頓，特別是動畫的卡頓會很明顯。在React的官方演講中有個例子，可以很明顯的看到這種同步計算造成的卡頓：

而Fiber就是用來解決這個問題的，Fiber可以將長時間的同步任務拆分成多個小任務，從而讓瀏覽器能夠抽身去響應其他事件，等他空了再回來繼續計算，這樣整個計算流程就顯得平滑很多。下面是使用Fiber后的效果：

怎麼來拆分

上面我們自己實現的render方法直接遞歸遍歷了整個vDom樹，如果我們在中途某一步停下來，下次再調用時其實並不知道上次在哪裡停下來的，不知道從哪裡開始，即使你將上次的結束節點記下來了，你也不知道下一個該執行哪個，所以vDom的樹形結構並不滿足中途暫停，下次繼續的需求，需要改造數據結構。另一個需要解決的問題是，拆分下來的小任務什麼時候執行？我們的目的是讓用戶有更流暢的體驗，所以我們最好不要阻塞高優先級的任務，比如用戶輸入，動畫之類，等他們執行完了我們再計算。那我怎麼知道現在有沒有高優先級任務，瀏覽器是不是空閑呢？總結下來，Fiber要想達到目的，需要解決兩個問題：

1. 新的任務調度，有高優先級任務的時候將瀏覽器讓出來，等瀏覽器空了再繼續執行
2. 新的數據結構，可以隨時中斷，下次進來可以接着執行

requestIdleCallback

requestIdleCallback是一個實驗中的新API，這個API調用方式如下:

// 開啟調用
var handle = window.requestIdleCallback(callback[, options])

// 結束調用
Window.cancelIdleCallback(handle) 

requestIdleCallback接收一個回調，這個回調會在瀏覽器空閑時調用，每次調用會傳入一個IdleDeadline，可以拿到當前還空餘多久，options可以傳入參數最多等多久，等到了時間瀏覽器還不空就強制執行了。使用這個API可以解決任務調度的問題，讓瀏覽器在空閑時才計算diff並渲染。更多關於requestIdleCallback的使用可以查看MDN的文檔。但是這個API還在實驗中，兼容性不好，所以React官方自己實現了一套。本文會繼續使用requestIdleCallback來進行任務調度，我們進行任務調度的思想是將任務拆分成多個小任務，requestIdleCallback裏面不斷的把小任務拿出來執行，當所有任務都執行完或者超時了就結束本次執行，同時要註冊下次執行，代碼架子就是這樣：

function workLoop(deadline) {
  while(nextUnitOfWork && deadline.timeRemaining() > 1) {
    // 這個while循環會在任務執行完或者時間到了的時候結束
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }

  // 如果任務還沒完，但是時間到了，我們需要繼續註冊requestIdleCallback
  requestIdleCallback(workLoop);
}

// performUnitOfWork用來執行任務，參數是我們的當前fiber任務，返回值是下一個任務
function performUnitOfWork(fiber) {
  
}
requestIdleCallback(workLoop);

上述workLoop對應React源碼看這裏。

Fiber可中斷數據結構

上面我們的performUnitOfWork並沒有實現，但是從上面的結構可以看出來，他接收的參數是一個小任務，同時通過這個小任務還可以找到他的下一個小任務，Fiber構建的就是這樣一個數據結構。Fiber之前的數據結構是一棵樹，父節點的children指向了子節點，但是只有這一個指針是不能實現中斷繼續的。比如我現在有一個父節點A，A有三個子節點B,C,D，當我遍歷到C的時候中斷了，重新開始的時候，其實我是不知道C下面該執行哪個的，因為只知道C，並沒有指針指向他的父節點，也沒有指針指向他的兄弟。Fiber就是改造了這樣一個結構，加上了指向父節點和兄弟節點的指針：

上面的圖片還是來自於官方的演講，可以看到和之前父節點指向所有子節點不同，這裡有三個指針：

1. child: 父節點指向第一個子元素的指針。
2. sibling：從第一個子元素往後，指向下一個兄弟元素。
3. return：所有子元素都有的指向父元素的指針。

有了這幾個指針后，我們可以在任意一個元素中斷遍歷並恢復，比如在上圖List處中斷了，恢復的時候可以通過child找到他的子元素，也可以通過return找到他的父元素，如果他還有兄弟節點也可以用sibling找到。Fiber這個結構外形看着還是棵樹，但是沒有了指向所有子元素的指針，父節點只指向第一個子節點，然後子節點有指向其他子節點的指針，這其實是個鏈表。

實現Fiber

現在我們可以自己來實現一下Fiber了，我們需要將之前的vDom結構轉換為Fiber的數據結構，同時需要能夠通過其中任意一個節點返回下一個節點，其實就是遍歷這個鏈表。遍歷的時候從根節點出發，先找子元素，如果子元素存在，直接返回，如果沒有子元素了就找兄弟元素，找完所有的兄弟元素后再返回父元素，然後再找這個父元素的兄弟元素。整個遍歷過程其實是個深度優先遍歷，從上到下，然後最後一行開始從左到右遍歷。比如下圖從div1開始遍歷的話，遍歷的順序就應該是div1 -> div2 -> h1 -> a -> div2 -> p -> div1。可以看到這個序列中，當我們return父節點時，這些父節點會被第二次遍歷，所以我們寫代碼時，return的父節點不會作為下一個任務返回，只有sibling和child才會作為下一個任務返回。

// performUnitOfWork用來執行任務，參數是我們的當前fiber任務，返回值是下一個任務
function performUnitOfWork(fiber) {
  // 根節點的dom就是container，如果沒有這個屬性，說明當前fiber不是根節點
  if(!fiber.dom) {
    fiber.dom = createDom(fiber);   // 創建一個DOM掛載上去
  } 

  // 如果有父節點，將當前節點掛載到父節點上
  if(fiber.return) {
    fiber.return.dom.appendChild(fiber.dom);
  }

  // 將我們前面的vDom結構轉換為fiber結構
  const elements = fiber.children;
  let prevSibling = null;
  if(elements && elements.length) {
    for(let i = 0; i < elements.length; i++) {
      const element = elements[i];
      const newFiber = {
        type: element.type,
        props: element.props,
        return: fiber,
        dom: null
      }

      // 父級的child指向第一個子元素
      if(i === 0) {
        fiber.child = newFiber;
      } else {
        // 每個子元素擁有指向下一個子元素的指針
        prevSibling.sibling = newFiber;
      }

      prevSibling = newFiber;
    }
  }

  // 這個函數的返回值是下一個任務，這其實是一個深度優先遍歷
  // 先找子元素，沒有子元素了就找兄弟元素
  // 兄弟元素也沒有了就返回父元素
  // 然後再找這個父元素的兄弟元素
  // 最後到根節點結束
  // 這個遍歷的順序其實就是從上到下，從左到右
  if(fiber.child) {
    return fiber.child;
  }

  let nextFiber = fiber;
  while(nextFiber) {
    if(nextFiber.sibling) {
      return nextFiber.sibling;
    }

    nextFiber = nextFiber.return;
  }
}

React源碼中的performUnitOfWork看這裏，當然比我們這個複雜很多。

統一commit DOM操作

上面我們的performUnitOfWork一邊構建Fiber結構一邊操作DOMappendChild，這樣如果某次更新好幾個節點，操作了第一個節點之後就中斷了，那我們可能只看到第一個節點渲染到了頁面，後續幾個節點等瀏覽器空了才陸續渲染。為了避免這種情況，我們應該將DOM操作都搜集起來，最後統一執行，這就是commit。為了能夠記錄位置，我們還需要一個全局變量workInProgressRoot來記錄根節點，然後在workLoop檢測如果任務執行完了，就commit:

function workLoop(deadline) {
  while(nextUnitOfWork && deadline.timeRemaining() > 1) {
    // 這個while循環會在任務執行完或者時間到了的時候結束
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }

  // 任務做完后統一渲染
  if(!nextUnitOfWork && workInProgressRoot) {
    commitRoot();
  }

  // 如果任務還沒完，但是時間到了，我們需要繼續註冊requestIdleCallback
  requestIdleCallback(workLoop);
}

因為我們是在Fiber樹完全構建后再執行的commit，而且有一個變量workInProgressRoot指向了Fiber的根節點，所以我們可以直接把workInProgressRoot拿過來遞歸渲染就行了：

// 統一操作DOM
function commitRoot() {
  commitRootImpl(workInProgressRoot.child);    // 開啟遞歸
  workInProgressRoot = null;     // 操作完后將workInProgressRoot重置
}

function commitRootImpl(fiber) {
  if(!fiber) {
    return;
  }

  const parentDom = fiber.return.dom;
  parentDom.appendChild(fiber.dom);

  // 遞歸操作子元素和兄弟元素
  commitRootImpl(fiber.child);
  commitRootImpl(fiber.sibling);
}

reconcile調和

reconcile其實就是虛擬DOM樹的diff操作，需要刪除不需要的節點，更新修改過的節點，添加新的節點。為了在中斷後能回到工作位置，我們還需要一個變量currentRoot，然後在fiber節點裏面添加一個屬性alternate，這個屬性指向上一次運行的根節點，也就是currentRoot。currentRoot會在第一次render后的commit階段賦值，也就是每次計算完后都會把當次狀態記錄在alternate上，後面更新了就可以把alternate拿出來跟新的狀態做diff。然後performUnitOfWork裏面需要添加調和子元素的代碼，可以新增一個函數reconcileChildren。這個函數裏面不能簡單的創建新節點了，而是要將老節點跟新節點拿來對比，對比邏輯如下:

1. 如果新老節點類型一樣，復用老節點DOM，更新props
2. 如果類型不一樣，而且新的節點存在，創建新節點替換老節點
3. 如果類型不一樣，沒有新節點，有老節點，刪除老節點

注意刪除老節點的操作是直接將oldFiber加上一個刪除標記就行，同時用一個全局變量deletions記錄所有需要刪除的節點：

      // 對比oldFiber和當前element
      const sameType = oldFiber && element && oldFiber.type === element.type;  //檢測類型是不是一樣
      // 先比較元素類型
      if(sameType) {
        // 如果類型一樣，復用節點，更新props
        newFiber = {
          type: oldFiber.type,
          props: element.props,
          dom: oldFiber.dom,
          return: workInProgressFiber,
          alternate: oldFiber,          // 記錄下上次狀態
          effectTag: 'UPDATE'           // 添加一個操作標記
        }
      } else if(!sameType && element) {
        // 如果類型不一樣，有新的節點，創建新節點替換老節點
        newFiber = {
          type: element.type,
          props: element.props,
          dom: null,                    // 構建fiber時沒有dom，下次perform這個節點是才創建dom
          return: workInProgressFiber,
          alternate: null,              // 新增的沒有老狀態
          effectTag: 'REPLACEMENT'      // 添加一個操作標記
        }
      } else if(!sameType && oldFiber) {
        // 如果類型不一樣，沒有新節點，有老節點，刪除老節點
        oldFiber.effectTag = 'DELETION';   // 添加刪除標記
        deletions.push(oldFiber);          // 一個數組收集所有需要刪除的節點
      }

然後就是在commit階段處理真正的DOM操作，具體的操作是根據我們的effectTag來判斷的:

function commitRootImpl(fiber) {
  if(!fiber) {
    return;
  }

  const parentDom = fiber.return.dom;
  if(fiber.effectTag === 'REPLACEMENT' && fiber.dom) {
    parentDom.appendChild(fiber.dom);
  } else if(fiber.effectTag === 'DELETION') {
    parentDom.removeChild(fiber.dom);
  } else if(fiber.effectTag === 'UPDATE' && fiber.dom) {
    // 更新DOM屬性
    updateDom(fiber.dom, fiber.alternate.props, fiber.props);
  }

  // 遞歸操作子元素和兄弟元素
  commitRootImpl(fiber.child);
  commitRootImpl(fiber.sibling);
}

替換和刪除的DOM操作都比較簡單，更新屬性的會稍微麻煩點，需要再寫一個輔助函數updateDom來實現:

// 更新DOM的操作
function updateDom(dom, prevProps, nextProps) {
  // 1. 過濾children屬性
  // 2. 老的存在，新的沒了，取消
  // 3. 新的存在，老的沒有，新增
  Object.keys(prevProps)
    .filter(name => name !== 'children')
    .filter(name => !(name in nextProps))
    .forEach(name => {
      if(name.indexOf('on') === 0) {
        dom.removeEventListener(name.substr(2).toLowerCase(), prevProps[name], false);
      } else {
        dom[name] = '';
      }
    });

  Object.keys(nextProps)
    .filter(name => name !== 'children')
    .forEach(name => {
      if(name.indexOf('on') === 0) {
        dom.addEventListener(name.substr(2).toLowerCase(), nextProps[name], false);
      } else {
        dom[name] = nextProps[name];
      }
    });
}

updateDom的代碼寫的比較簡單，事件只處理了簡單的on開頭的，兼容性也有問題，prevProps和nextProps可能會遍歷到相同的屬性，有重複賦值，但是總體原理還是沒錯的。要想把這個處理寫全，代碼量還是不少的。

函數組件

函數組件是React裏面很常見的一種組件，我們前面的React架構其實已經寫好了，我們這裏來支持下函數組件。我們之前的fiber節點上的type都是DOM節點的類型，比如h1什麼的，但是函數組件的節點type其實就是一個函數了，我們需要對這種節點進行單獨處理。

首先需要在更新的時候檢測當前節點是不是函數組件，如果是，children的處理邏輯會稍微不一樣:

// performUnitOfWork裏面
// 檢測函數組件
function performUnitOfWork(fiber) {
  const isFunctionComponent = fiber.type instanceof Function;
  if(isFunctionComponent) {
    updateFunctionComponent(fiber);
  } else {
    updateHostComponent(fiber);
  }
  
  // ...下面省略n行代碼...
}

function updateFunctionComponent(fiber) {
  // 函數組件的type就是個函數，直接拿來執行可以獲得DOM元素
  const children = [fiber.type(fiber.props)];

  reconcileChildren(fiber, children);
}

// updateHostComponent就是之前的操作，只是單獨抽取了一個方法
function updateHostComponent(fiber) {
  if(!fiber.dom) {
    fiber.dom = createDom(fiber);   // 創建一個DOM掛載上去
  } 

  // 將我們前面的vDom結構轉換為fiber結構
  const elements = fiber.props.children;

  // 調和子元素
  reconcileChildren(fiber, elements);
}

然後在我們提交DOM操作的時候因為函數組件沒有DOM元素，所以需要注意兩點：

1. 獲取父級DOM元素的時候需要遞歸網上找真正的DOM
2. 刪除節點的時候需要遞歸往下找真正的節點

我們來修改下commitRootImpl:

function commitRootImpl() {
  // const parentDom = fiber.return.dom;
  // 向上查找真正的DOM
  let parentFiber = fiber.return;
  while(!parentFiber.dom) {
    parentFiber = parentFiber.return;
  }
  const parentDom = parentFiber.dom;
  
  // ...這裏省略n行代碼...
  
  if{fiber.effectTag === 'DELETION'} {
    commitDeletion(fiber, parentDom);
  }
}

function commitDeletion(fiber, domParent) {
  if(fiber.dom) {
    // dom存在，是普通節點
    domParent.removeChild(fiber.dom);
  } else {
    // dom不存在，是函數組件,向下遞歸查找真實DOM
    commitDeletion(fiber.child, domParent);
  }
}

現在我們可以傳入函數組件了:

import React from './myReact';
const ReactDOM = React;

function App(props) {
  return (
    <div>
      <h1 id="title">{props.title}</h1>
      <a href="xxx">Jump</a>
      <section>
        <p>
          Article
        </p>
      </section>
    </div>
  );
}

ReactDOM.render(
  <App title="Fiber Demo"/>,
  document.getElementById('root')
);

實現useState

useState是React Hooks裏面的一個API，相當於之前Class Component裏面的state，用來管理組件內部狀態，現在我們已經有一個簡化版的React了，我們也可以嘗試下來實現這個API。

簡單版

我們還是從用法入手來實現最簡單的功能，我們一般使用useState是這樣的：

function App(props) {
  const [count, setCount] = React.useState(1);
  const onClickHandler = () => {
    setCount(count + 1);
  }
  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={onClickHandler}>Count+1</button>
    </div>
  );
}

ReactDOM.render(
  <App title="Fiber Demo"/>,
  document.getElementById('root')
);

上述代碼可以看出，我們的useState接收一個初始值，返回一個數組，裏面有這個state的當前值和改變state的方法，需要注意的是App作為一個函數組件，每次render的時候都會運行，也就是說裏面的局部變量每次render的時候都會重置，那我們的state就不能作為一個局部變量，而是應該作為一個全部變量存儲：

let state = null;
function useState(init) {

  state = state === null ? init : state;

  // 修改state的方法
  const setState = value => {
    state = value;

    // 只要修改了state，我們就需要重新處理節點
    workInProgressRoot = {
      dom: currentRoot.dom,
      props: currentRoot.props,
      alternate: currentRoot
    }

    // 修改nextUnitOfWork指向workInProgressRoot，這樣下次就會處理這個節點了
    nextUnitOfWork = workInProgressRoot;
    deletions = [];
  }

  return [state, setState]
}

這樣其實我們就可以使用了：

支持多個state

上面的代碼只有一個state變量，如果我們有多個useState怎麼辦呢？為了能支持多個useState，我們的state就不能是一個簡單的值了，我們可以考慮把他改成一個數組，多個useState按照調用順序放進這個數組裡面，訪問的時候通過下標來訪問:

let state = [];
let hookIndex = 0;
function useState(init) {
  const currentIndex = hookIndex;
  state[currentIndex] = state[currentIndex] === undefined ? init : state[currentIndex];

  // 修改state的方法
  const setState = value => {
    state[currentIndex] = value;

    // 只要修改了state，我們就需要重新處理這個節點
    workInProgressRoot = {
      dom: currentRoot.dom,
      props: currentRoot.props,
      alternate: currentRoot
    }

    // 修改nextUnitOfWork指向workInProgressRoot，這樣下次就會處理這個節點了
    nextUnitOfWork = workInProgressRoot;
    deletions = [];
  }

  hookIndex++;

  return [state[currentIndex], setState]
}

來看看多個useState的效果：

支持多個組件

上面的代碼雖然我們支持了多個useState，但是仍然只有一套全局變量，如果有多個函數組件，每個組件都來操作這個全局變量，那相互之間不就是污染了數據了嗎？所以我們數據還不能都存在全局變量上面，而是應該存在每個fiber節點上，處理這個節點的時候再將狀態放到全局變量用來通訊:

// 申明兩個全局變量，用來處理useState
// wipFiber是當前的函數組件fiber節點
// hookIndex是當前函數組件內部useState狀態計數
let wipFiber = null;
let hookIndex = null;

因為useState只在函數組件裏面可以用，所以我們之前的updateFunctionComponent裏面需要初始化處理useState變量:

function updateFunctionComponent(fiber) {
  // 支持useState，初始化變量
  wipFiber = fiber;
  hookIndex = 0;
  wipFiber.hooks = [];        // hooks用來存儲具體的state序列
  
  // ......下面代碼省略......
}

因為hooks隊列放到fiber節點上去了，所以我們在useState取之前的值時需要從fiber.alternate上取，完整代碼如下：

function useState(init) {
  // 取出上次的Hook
  const oldHook = wipFiber.alternate && wipFiber.alternate.hooks && wipFiber.alternate.hooks[hookIndex];

  // hook數據結構
  const hook = {
    state: oldHook ? oldHook.state : init      // state是每個具體的值
  }

  // 將所有useState調用按照順序存到fiber節點上
  wipFiber.hooks.push(hook);
  hookIndex++;

  // 修改state的方法
  const setState = value => {
    hook.state = value;

    // 只要修改了state，我們就需要重新處理這個節點
    workInProgressRoot = {
      dom: currentRoot.dom,
      props: currentRoot.props,
      alternate: currentRoot
    }

    // 修改nextUnitOfWork指向workInProgressRoot，這樣下次requestIdleCallback就會處理這個節點了
    nextUnitOfWork = workInProgressRoot;
    deletions = [];
  }

  return [hook.state, setState]
}

上面代碼可以看出我們在將useState和存儲的state進行匹配的時候是用的useState的調用順序匹配state的下標，如果這個下標匹配不上了，state就錯了，所以React裏面不能出現這樣的代碼:

if (something) {
    const [state, setState] = useState(1);
}

上述代碼不能保證每次something都滿足，可能導致useState這次render執行了，下次又沒執行，這樣新老節點的下標就匹配不上了，對於這種代碼，React會直接報錯：

用Hooks模擬Class組件

這個功能純粹是娛樂性功能，通過前面實現的Hooks來模擬實現Class組件，這個並不是React官方的實現方式哈~我們可以寫一個方法將Class組件轉化為前面的函數組件:

function transfer(Component) {
  return function(props) {
    const component = new Component(props);
    let [state, setState] = useState(component.state);
    component.props = props;
    component.state = state;
    component.setState = setState;

    return component.render();
  }
}

然後就可以寫Class了，這個Class長得很像我們在React裏面寫的Class，有state,setState和render：

import React from './myReact';

class Count4 {
  constructor(props) {
    this.props = props;
    this.state = {
      count: 1
    }
  }

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

  render() {
    return (
      <div>
        <h3>Class component Count: {this.state.count}</h3>
        <button onClick={this.onClickHandler}>Count+1</button>
      </div>
    ); 
  }
}

// export的時候用transfer包裝下
export default React.transfer(Count4);

然後使用的時候直接:

<div>
  <Count4></Count4>
</div>

當然你也可以在React裏面建一個空的class Component，讓Count4繼承他，這樣就更像了。

好了，到這裏我們代碼就寫完了，完整代碼可以看我GitHub。

總結

1. 我們寫的JSX代碼被babel轉化成了React.createElement。
2. React.createElement返回的其實就是虛擬DOM結構。
3. ReactDOM.render方法是將虛擬DOM渲染到頁面的。
4. 虛擬DOM的調和和渲染可以簡單粗暴的遞歸，但是這個過程是同步的，如果需要處理的節點過多，可能會阻塞用戶輸入和動畫播放，造成卡頓。
5. Fiber是16.x引入的新特性，用處是將同步的調和變成異步的。
6. Fiber改造了虛擬DOM的結構，具有父 -> 第一個子，子 -> 兄，子 -> 父這幾個指針，有了這幾個指針，可以從任意一個Fiber節點找到其他節點。
7. Fiber將整棵樹的同步任務拆分成了每個節點可以單獨執行的異步執行結構。
8. Fiber可以從任意一個節點開始遍歷，遍歷是深度優先遍歷，順序是父 -> 子 -> 兄 -> 父，也就是從上往下，從左往右。
9. Fiber的調和階段可以是異步的小任務，但是提交階段(commit)必須是同步的。因為異步的commit可能讓用戶看到節點一個一個接連出現，體驗不好。
10. 函數組件其實就是這個節點的type是個函數，直接將type拿來運行就可以得到虛擬DOM。
11. useState是在Fiber節點上添加了一個數組，數組裡面的每個值對應了一個useState，useState調用順序必須和這個數組下標匹配，不然會報錯。

參考資料

A Cartoon Intro to Fiber

妙味課堂大聖老師：手寫react的fiber和hooks架構

React Fiber

這可能是最通俗的 React Fiber(時間分片) 打開方式

淺析 React Fiber

React Fiber架構

文章的最後，感謝你花費寶貴的時間閱讀本文，如果本文給了你一點點幫助或者啟發，請不要吝嗇你的贊和GitHub小星星，你的支持是作者持續創作的動力。

作者博文GitHub項目地址： https://github.com/dennis-jiang/Front-End-Knowledges

作者掘金文章匯總：https://juejin.im/post/5e3ffc85518825494e2772fd

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

前言

.NET 中GC管理你服務的內存分配和釋放,GC是運行公共語言運行時(CLR Common Language Runtime)中,GC可以幫助開發人員有效的分配內存和和釋放內存,大多數情況下是不需要去擔心的,但是有時候服務總是是出現莫名的問題，所以還是有必要了解一下GC的基礎知識的。這裏就不介紹內存方面的知識了。

GC回收過程

GC將對象分為大對象和小對象，如果對象的大小大於或者等於85000byte將被視為大對象，大對象會被分配到到(LOH) Large Object Heap中去。

GC有一個代數的概念Generation,分為三代

• Generation 0: 0代，這裏面都是生命周期很短的對象，比如臨時變量，當你new一個對象的時候該對象都會在Generation 0中，這裏的對象將很快的被GC回收，但是當你new的是一個大對象的時候它會直接進去大對象堆(LOH)

• Generation 1: 1代，這一代包含的也基本是生命周期很短的對象。它是短期對象和長期對象之間的緩衝區。

• Generation 2: 2代，這一代包含的都是生命周期長的對象，它們都是從1代和2代中選拔出來的，LOH屬於2代。

當分配的對象使用的內存超出了GC的閾值時回收就會開始。閾值是隨着服務的運行GC自己調整的。或者直接調用GC.Collect方法也可以開始回收。

回收開始時GC會開始循環遍歷Generation 0中的所有對象並標記所有對象是活動對象還是非活動對象，標記完成後會更新活動對象的引用。最後會回收非活動對象佔用的內存，並把活動對象壓縮后移動到Generation 1中，Generation 1中的或對象在移動到Generation 2是默認不會被壓縮的，因為複製大的對象會導致性能的下降。可以通過GCSettings.LargeObjectHeapCompactionMode來配置壓縮LOH。

GC的回收類型

GC 回收有兩種類型，WorkStation GC(工作站)和Server GC(服務器)，.Net Core服務默認情況下時使用WorkStation GC工作站模式來回收。

• Server GC會擁有更大的內存，Server GC會為每個處理器創建一個用於執行垃圾回收的堆和專用線程，每個堆都擁有一個小對象堆和大對象堆，並且所有的堆都可以訪問。 不同堆上的對象可以相互引用。因為多個垃圾回收線程一起工作，所以對於相同大小的堆Server GC垃圾回收比WorkStation GC垃圾回收更快一些。但是Server GC回收會佔用大量資源，這種模式的特點是初始分配的內存較大，並且盡可能不回收內存,進行回收用時會很耗時,並進行內存碎片整理工作。

• Workstation GC的內存相對於Server GC就很小啦，且它的回收線程就是服務的線程且有較高的優先級，因為必須與其他線程競爭 CPU 時間來進行回收。

不同模式下的內存分配

GC的回收模式

GC有三種回收模式

• Non-Concurrent GC 非并行回收模式：在非并行模式下,回收時候會掛起所有其他的線程影響服務的性能。

• Concurrent GC 并行回收模式： 并行會後可以解決非并行回收引起的線程掛起，讓其他線程和回收線程一起運行，使服務可以更快的響應，并行回收只會發生在Generation 2中，Generation 0/1始終都是非併發的，因為他們都是小對象回收的速度很快。在并行回收的時候我們依舊可以分配對象到Generation 0/1中。

• Background GC 後台回收模式：Background GC 是 Concurrent GC的增強版本。 區別在Background GC回收Generation 2的時允許了Generation 0/1 進行清理。在WorkStation GC下會使用一個專用的後台垃圾回收線程,而Server GC下會使用多個線程來進行回收。且Server GC下回收線程不會超時。

非并行回收:

并行回收

WorkStation GC 後台回收

Server GC 後台回收

GC回收類型配置

推薦使用runtimeconfig.json文件和環境變量COMPlus_gcServer來配置。

COMPlus_gcServer 0 = WorkStation GC
COMPlus_gcServer 1 = Server GC

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.Server": true 
         //true - Server GC  false - WorkStation GC
      }
   }
}

GC回收模式配置

推薦使用runtimeconfig.json文件和環境變量COMPlus_gcConcurrent來配置。

COMPlus_gcConcurrent 0 =Non-Concurrent GC
COMPlus_gcConcurrent 1 =Background GC

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.Concurrent": true 
         //true- Background GC false -Non-Concurrent GC
      }
   }
}

強制回收

在一些特殊的情況下強制回收是可以提高服務的性能的，可以向GC.Collect()提供GCCollectionMode枚舉值觸發強制回收。

• Default ：默認的回收設置。
• Forced ：立即強制進行垃圾回收。
• Optimized ： GC來判斷時間是否是回收對象的最佳時間，如GC判定回收效率不高因此回收不合理的情況下將返回不回收對象。

 GC.Collect( (int) GCCollectionMode.Forced);

延遲回收

在我們的服務在檢索數據或者處理邏輯的時候可能會發生垃圾回收，從而妨礙性能，可以通過System.Runtime.GCLatencyMode來配置延遲回收

• GCLatencyMode.LowLatency：禁止Generation 2回收，只回收Generation 0/1,這個只能在短時間內使用，如果長時間使用內存處於壓力下GC還是會觸發回收，這個配置只對WorkStation GC可用。

• GCLatencyMode.SustainedLowLatency ：禁止Generation 2的 Foreground GC (前台回收)，只回收Generation 0/1和Generation 2後台回收。WorkStation GC和Server GC都可以使用，且可以長時間使用，但是如果禁用Background GC，將無法使用。

GC.Collect( (int) GCLatencyMode.SustainedLowLatency);

參考文章

從ASP.NET Core 3.0 preview 特性，了解CLR的Garbage Collection

微軟文檔

總結

參考了一些大佬和官方的文檔簡單的去了解了一下GC的工作原理，方便在開發中有效區分配使用內存資源，文中如有錯誤大佬們可以在評論區指出。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

中國國際汽車商品交易會（CIAPE）將於2014年10月19日至21日在上海虹橋國家會展中心（上海）隆重舉行。作為該會展中心的開館第一展，作為傳播汽車產品和品牌的先鋒陣地，中國國際汽車商品交易會令各界充滿期待。

中國連續五年成為全球汽車產銷大國，需要一個與此相適應的、全產業鏈構建的、滿足國內外汽車市場日益增長需求的、自主的國際化平臺，中國國際汽車商品交易會應運而生。中國國際汽車商品交易會既是出口的橋樑，也是引進消化吸收再創新的平臺；既展示中國汽車產品的實力，也展示國外先進技術、產品、管理模式和商業模式。通過交流與合作，創造更多的機會。它是中國汽車產業整體水準提高和汽車售後市場規範化發展的助推器。

中國國際汽車商品交易會是由原中國國際汽車零部件博覽會轉型而來，在展會內容上，從單一的零部件領域展示平臺轉型升級為覆蓋汽車全產業鏈的展示、貿易平臺；辦展地點，由北京遷移至上海虹橋國家會展中心（上海）舉辦。據交易會負責人介紹，中國國際汽車商品交易會之所以最終選擇上海，主要考慮到上海獨特的戰略優勢和交通條件。上海是中國最大的經濟中心城市，所處的長江經濟帶和長三角核心區域，是中國經濟最為活躍和發達的地區，也是中國汽車及相關產業的聚集地。

國家會展中心（上海）是目前世界規模最大的會展綜合體，由展覽場館、配套商業中心、辦公樓和酒店四大部分構成。綜合體位居上海虹橋商務區核心，盡享虹橋交通樞紐八種交通模式（空港、高鐵、城鐵、公路、地鐵、公交、出租、磁懸浮），地理位置優越，交通便捷，內有地鐵2號線直達（徐涇東站），與虹橋機場、虹橋高鐵站、上海市區、陸家嘴、上海自貿區、浦東國際機場一線相連，為汽車行業企業立足上海、輻射長三角、全國及走向世界提供最佳支點。

中國的汽車行業面對資源消耗、環境污染、能源緊張、交通擁堵的挑戰，面對國內外車企在國內市場份額上的激烈競爭，面對零部件行業壟斷等一系列問題，特別是面對移動互聯對汽車這一傳統工業的衝擊，倒逼政府、行業、企業必須創新政策與機制，轉換思維方式，轉變管理模式，創新商業模式。

中國國際汽車商品交易會作為全產業鏈構建的汽車商品展示、貿易平臺，設置整車、零部件、電子與資訊化、技術裝備、維修檢測設備、清潔燃料、服務用品、輪胎、改裝車、摩托車十大展區，內容覆蓋面之廣在目前的汽車行業展會中是絕無僅有的，其目的十分明確，就是要促進汽車全產業鏈的協同發展。我國汽車產業創新能力不足不僅在於汽車產業本身，還制約於裝備、材料、電子工業等的落後。蘋果和特斯拉公司的成功證明，產業的創新與突破不是其中幾個企業單打獨鬥可以完成的，而是產業的上中下游即整個產業鏈的協同突破，企業的價值創造取決於產業鏈生態關係的整合，即企業的核心資產和外部的互補資產共同創造企業的市場地位、創新地位和競爭地位。基於對這種發展理念的認同，中國國際汽車商品交易會為全產業生態鏈企業間的合作互補創造機遇。也為一站式參觀、洽談、採購提供可能與便捷。

當今，以新一代互聯網技術、新能源技術為標誌的新一輪科技革命及產業變革正在向縱深發展。未來汽車產品將成為移動互聯網終端、移動電子商務終端、移動智慧電網終端。這個趨勢必將引發產業發展形態和發展方式的巨變，移動互聯將改變汽車產業的傳統商業模式和競爭環境，汽車產業將由傳統製造業轉變成製造服務型和創新型產業，市場和用戶價值將成為汽車產業組織生產和銷售的出發點。特斯拉顛覆了無數傳統觀念，其資源的整合力、商業模式的創新實踐對於整個汽車行業的借鑒意義在哪兒？中國的新能源汽車應該選擇什麼樣的技術方向，如何走向商業化？為新能源汽車配套的零部件企業在哪裡？什麼是互聯網思維？什麼叫車聯網？汽車產業如何應對IT行業和互聯網公司的挑戰？移動互聯時代的技術進步如何促進網路資訊技術的創新基因與汽車技術的產業基因跨界融合？中國汽車行業在高度同質化競爭的成熟產業中如何掌握互聯網思維之能力實現數位化創新？企業內部管理平臺、外部車聯網服務平臺和電子商務平臺如何走向融合？如何將設計、製造能力和資源服務化，通過雲平臺實現交易、對接、協同及全產業鏈優化，以提高效率？如何打造一個相容的、能吸引海量服務商一起為使用者提供服務的盈利的開放平臺？車聯網平臺和介面的標準如何建立？汽車互聯生活如何保證車主的資訊安全？在汽車是機械裝置的觀點被汽車是架在四個車輪上電腦的認知所替代的年代，造車、賣車將如何被重新定義？售後流通領域經銷商如何轉型？如何由賣產品延伸到賣服務？電商和傳統經銷商如何合作？線上線下怎樣融合以讓終端消費者獲得一個優質完整的服務？如何以標準化、透明化之利器規範市場秩序、促進充分競爭、打造管道品牌以構建適合中國汽車售後市場發展的商業模式？如何推動實施汽車檢測/維修（I/M）制度，宣導“綠色汽修”、“科技汽修”等現代維修模式，促進全行業的專業化、標準化、品牌化轉型？在國際化方面，中國汽車如何由產品輸出為主轉向資本、技術、產品共同輸出？中國汽車如何參與到全球汽車市場中去？等等。

以上這些問題都是汽車及相關行業從業者和汽車商品消費者關注的熱點，所有答案將在今年十月舉辦的中國國際汽車商品交易會現場，由國內外參展企業、專家、學者及他們所帶來的技術、產品、模式、思維予以揭曉。

縱觀汽車產業的價值鏈，無論是產品還是技術，是思維還是服務，最終都將以商品的形態面對市場的檢驗，只有創造效益才能體現價值。中國國際汽車商品交易會將順應這場科技革命和產業變革，以新的思維和模式去促進百年積澱的傳統行業與朝氣蓬勃的新型產業的融合，以創造更多的商業契機推進汽車產品的商品化。

中國國際汽車商品交易會將緊貼政策導向和市場需求，在展會同期舉辦一系列峰會、政策法規宣講會、新技術及專業研討會、采供對接大會等活動，為參展企業和參觀者服務。 

中國國際汽車商品交易會將伴隨國家會展中心（上海）這一全新平臺在四個月後以其恢弘的氣勢和嶄新的服務體驗展現在世人面前。屆時將有國內外3000餘家汽車及相關產業鏈上的企業和來自中、美、英、法、德、意、日、韓、墨西哥、土耳其、伊朗、印度、泰國、新加坡、臺灣等100多個國家和地區的觀眾、整車廠研發及採購人員、合資公司高管及市場專員、國際汽配連鎖企業駐華代表、IT及跨界精英、互聯網公司、通訊運營商、應用軟體供應商、4S店經理、電商經理、獨立售後市場經銷商、管道商、獨立售後修理廠管理者到會，還有汽車業相關商會、協會、院校領導，政府官員，媒體及國內外的會展界人士蒞臨。

展會期間，組委會特邀請世界頂級義大利摩托車特技表演隊，每天在會展中心北門十萬平米廣場為大家奉獻精彩絕倫、血脈僨張的摩托車特技表演，同場連袂的還有魅力無窮的改裝車漂移表演。

中國國際汽車商品交易會將依託全新的國家會展中心展館為今後的規模化發展奠定基礎。中國國際汽車商品交易會將致力於打造一個中國自主的、覆蓋汽車全產業鏈、新型高效的展示貿易平臺、努力成為中國實現汽車強國夢助推器的發展定位，與上海市服務經濟開發、建設國際金融中心、航運中心和國際貿易中心的發展定位相契合，與汽車產業向製造服務型和創新型產業的轉型發展相契合。我們相信，中國國際汽車商品交易會落戶上海並健康可持續發展，必將推動長三角地區乃至中國汽車及相關產業和汽車商品貿易的發展。

在此，我們誠邀國內外汽車全產業鏈的企業、實體及相關產業的企業積極參展，展示和分享最新科技、產品與商業模式，在移動互聯時代，共同面對機遇與挑戰，為中國進入節能、環保、安全、便捷、舒適的汽車社會努力。同時也歡迎中外媒體、汽車及相關各界觀眾和消費者關注這一跨汽車業的盛會。

中國國際汽車商品交易會組委會
2014年6月18日

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

※別再煩惱如何寫文案,掌握八大原則!