摘要：現(xiàn)在關于最新版本新特性的宣傳講解已經(jīng)鋪天蓋地了。測試場景是反復操作數(shù)組，這個反復操作有所講究，我們計劃持續(xù)不斷地改變數(shù)組的某一項而不是整個數(shù)組的大范圍變動。代碼和性能測試在使用開發(fā)時，相信很多開發(fā)者在搭配函數(shù)式的狀態(tài)管理框架使用。

現(xiàn)在關于 React 最新 v16 版本新特性的宣傳、講解已經(jīng)“鋪天蓋地”了。你最喜歡哪一個 new feature？
截至目前，組件構(gòu)建方式已經(jīng)琳瑯滿目。那么，你考慮過他們的性能對比嗎？這篇文章，聚焦其中一個小細節(jié)，進行對比，望讀者參考的同時，期待大神斧正。

先上結(jié)論：在我們的測試當中，使用 React.PureComponent 能夠提升 30% JavaScript 執(zhí)行效率。測試場景是反復操作數(shù)組，這個“反復操作”有所講究，我們計劃持續(xù)不斷地改變數(shù)組的某一項（而不是整個數(shù)組的大范圍變動）。

線上參考地址： 請點擊這里

那么這樣的場景，作為開發(fā)者有必要研究嗎？如果你的應用并不涉及到高頻率的更新數(shù)組某幾項，那么大可不必在意這些性能的微妙差別。但是如果存在一些“實時更新”的場景，比如：

用戶輸入改變數(shù)組（點贊者顯示）；

輪詢（股票實時）；

推更新（比賽比分實時播報）；

那么就需要進行考慮。我們定義：changedItems.length / array.length 比例越小，本文所涉及的性能優(yōu)化越應該實施，即越有必要使用 React.PureComponent。

在使用 React 開發(fā)時，相信很多開發(fā)者在搭配函數(shù)式的狀態(tài)管理框架 Redux 使用。Redux reducers 作為純函數(shù)的同時，也要保證 state 的不可變性，在我們的場景中，也就是說在相關 action 被觸發(fā)時，需要返回一個新的數(shù)組。

const users = (state, action) => {
  if (action.type === "CHANGE_USER_1") {
    return [action.payload, ...state.slice(1)]
  }
  return state
}

如上代碼，當 CHANGE_USER_1 時，我們對數(shù)組的第一項進行更新，使用 slice 方法，不改變原數(shù)組的同時返回新的數(shù)組。

我們設想所有的 users 數(shù)組被 Users 函數(shù)式組件渲染：

import User from "./User"
const Users = ({users}) =>
  

    {
      users.map(user => 
    }
  

問題的關鍵在于：users 數(shù)組作為 props 出現(xiàn)，當數(shù)組中的第 K 項改變時，所有的 組件都會進行 reconciliation 的過程，即使非 K 項并沒有發(fā)生變化。

這時候，我們可以引入 React.PureComponent，它通過淺對比規(guī)避了不必要的更新過程。即使淺對比自身也有計算成本，但是一般情況下這都不值一提。

以上內(nèi)容其實已經(jīng)“老生常談”了，下面直接進入代碼和性能測試環(huán)節(jié)。

我們渲染了一個有 200 項的數(shù)組：

const arraySize = 200;
const getUsers = () =>
  Array(arraySize)
    .fill(1)
    .map((_, index) => ({
      name: "John Doe",
      hobby: "Painting",
      age: index === 0 ? Math.random() * 100 : 50
    }));
    

注意在 getUsers 方法中，關于 age 屬性我們做了判斷，保證每次調(diào)用時，getUsers 返回的數(shù)組只有第一項的 age 屬性不同。
這個數(shù)組將會觸發(fā) 400 次 re-renders 過程，并且每一次只改變數(shù)組第一項的一個屬性(age):

  const repeats = 400;
  componentDidUpdate() {
    ++this.renderCount;
    this.dt += performance.now() - this.startTime;
    if (this.renderCount % repeats === 0) {
      if (this.componentUnderTestIndex > -1) {
        this.dts[componentsToTest[this.componentUnderTestIndex]] = this.dt;
        console.log(
          "dt",
          componentsToTest[this.componentUnderTestIndex],
          this.dt
        );
      }
      ++this.componentUnderTestIndex;
      this.dt = 0;
      this.componentUnderTest = componentsToTest[this.componentUnderTestIndex];
    }
    if (this.componentUnderTest) {
      setTimeout(() => {
        this.startTime = performance.now();
        this.setState({ users: getUsers() });
      }, 0);
    } else {
      alert(`
        Render Performance ArraySize: ${arraySize} Repeats: ${repeats}
        Functional: ${Math.round(this.dts.Functional)} ms
        PureComponent: ${Math.round(this.dts.PureComponent)} ms
        Component: ${Math.round(this.dts.Component)} ms
      `);
    }
  }

為此，我們采用三種方式設計 組件。

export const Functional = ({ name, age, hobby }) => (
  

    {name}
    {age}
    {hobby}
  
);

export class PureComponent extends React.PureComponent {
  render() {
    const { name, age, hobby } = this.props;
    return (
      

        {name}
        {age}
        {hobby}
      
    );
  }
}

export class Component extends React.Component {
  render() {
    const { name, age, hobby } = this.props;
    return (
      

        {name}
        {age}
        {hobby}
      
    );
  }
}

同時，在不同的瀏覽器環(huán)境下，我得出：

Firefox 下，PureComponent 收益 30%；

Safari 下，PureComponent 收益 6%；

Chrome 下，PureComponent 收益 15%；

測試硬件環(huán)境：

最終結(jié)果：

最后，送給大家魯迅先生的一句話：

“Early optimization is the root of all evil”?- 魯迅

Happy Coding!
PS: 作者?Github倉庫?和?知乎問答鏈接?歡迎各種形式交流。

我的其他幾篇關于React技術棧的文章：
React Redux 中間件思想遇見 Web Worker 的靈感（附demo）
了解 Twitter 前端架構(gòu) 學習復雜場景數(shù)據(jù)設計
React 探秘 - React Component 和 Element（文末附彩蛋demo和源碼）
從setState promise化的探討 體會React團隊設計思想
通過實例，學習編寫 React 組件的“最佳實踐”
React 組件設計和分解思考
從 React 綁定 this，看 JS 語言發(fā)展和框架設計
React 服務端渲染如此輕松 從零開始構(gòu)建前后端應用
做出Uber移動網(wǎng)頁版還不夠 極致性能打造才見真章**
React+Redux打造“NEWS EARLY”單頁應用 一個項目理解最前沿技術棧真諦**