摘要：市面上竟然擁有多個虛擬庫。虛擬庫，就是出來后的一種新式庫，以虛擬與算法為核心，屏蔽操作，操作數據即操作視圖。及其他虛擬庫已經將虛擬的生成交由與處理了，因此不同點是，虛擬的結構與算法。因此虛擬庫是分為兩大派系算法派與擬態派。

去哪兒網迷你React是年初立項的新作品，在這前，去哪兒網已經深耕多年，擁有QRN（react-native的公司制定版），HY（基于React的hybird方案）， yo(基于React的移動UI庫)，QRN-web(基于React的三端合一移植方案)，此外，像機票等部門也大規模將React用于前臺頁面，后臺頁面就更不在話下。

如此廣泛地應用React，我們熟曉其優缺點。優點是代碼的可維護性大大提高，性能卓然！但缺點也明顯，由于體積太大，React.js+React-DOM.js超過3萬行，體量過3MB，已經加上immutable.js , redux, redux-react, react-router等全家桶，工程師一行代碼沒有寫，已經好幾MB了。這在過去絕對不可想象，要知道，體積意味著流量，流量代表著金錢，越大越燒錢，越大下載速度越慢，用戶體驗越差，用戶就會流失。現在問題擺在我們面前，我們就得解決。雖然webpack官網有各種瘦身方案，但瘦死的大象也比馬大。這是一個如此普遍存在的問題，因此外國人肯定也遇到過，思考過，提出什么新點子——所有這一切，都指向一個名詞，“迷你React”。

作為一個生態圈成熟的標志，一個庫出名了，就各種偏門補丁，閃光效果往上加，庫難免會膨脹，不爽的人就會推出迷你化方案。上一個世代是jQuery與zepto。React的迷你方案也有不少，preact, inferno, react-lite, dio, rax……

但問題不是簡單到直接從github找一個迷你React庫替換上就能搞定。之所以稱為迷你，肯定有所欠缺，如果是內部實現的改良也罷，如果閹割了功能可不是鬧著玩。恰恰他們就好這口，因此現有方案不能滿足我們。我們需要一個能直接替換，或至少95％的業務代碼不用動。這意味著這迷你框架，需要與React的接口完全一致，并且全面支持它的全家桶。當然細化一下來的需來就更多了，早期說只要支持移動，因此取名為react-mobile，后來連iE8也要支持，因此這活不能指望別人，我們自己動手擼了。

我們先來一趟競品分析。為了加快產出速度，能借鑒的盡可能借鑒。React推出以后，針對其性能研究衍生出不少庫，針對其體積也誕生出大量仿品。它比jQuery更加繽紛多采。市面上竟然擁有100多個虛擬DOM庫。虛擬DOM庫，就是React出來后的一種新式庫，以虛擬DOM與diff算法為核心，屏蔽DOM操作，操作數據即操作視圖。這聽起來有點像MVVM，MVVM也是屏蔽DOM操作，操作數據即操作視圖，但它是以VM為核心。

React及其他虛擬DOM庫已經將虛擬DOM的生成交由JSX與babel處理了，因此不同點是，虛擬DOM的結構與diff算法。虛擬DOM萬宗不離其變是三大屬性，type, props, children，當然也可以改一下別名，babel可以做相應配置。此外，虛擬DOM可以加入更多冗余標識，以幫diff算法的改良。

React最初推出時也不火，那時的招牌與現在性能不什么兩樣，也是高性能。但是JSX離經背道，與業界宣揚了多年的前后端分離，數據結構樣式分離等教條差太遠了，一直默默在角落里畫圈。直到RN出來，解決原生編寫界面的痛苦才一炮而紅。大家才留意它的性能，它的性能背后的diff算法。最早研究React的diff算法是virtual-dom這個庫，是基于經典的DFS算法。后來相應的算法就多起來。最后才是從接口進行模擬，就是所謂的React-like框架。因此虛擬DOM庫是分為兩大派系：算法派與擬態派。

下面將從這兩大派系進行扼要的描述。

將前端回歸到算法上的探索是前端框架史上的一個巨大進步。之前是MVVM將數據從繁復的DOM操作分離出來。正因為有了純數據，并且數據結構可控，那么算法才有發揮的余地。

最開始出現的是 virtual-dom這個庫，是大家好奇React為什么這么快而搞鼓出來的。它的實現是非常學院風格，通過深度優先搜索與in-order tree來實現高效的diff。它與React后來公開出來的算法是很不一樣。

然后是cito.js的橫空出世，它對今后所有虛擬DOM的算法都有重大影響。它采用兩端同時進行比較的算法，將diff速度拉高到幾個層次。

緊隨其后的是kivi.js，在cito.js的基出提出兩項優化方案，使用key實現移動追蹤及基于key的編輯長度矩離算法應用（算法復雜度 為O(n^2)）。

但這樣的diff算法太過復雜了，于是后來者snabbdom將kivi.js進行簡化，去掉編輯長度矩離算法，調整兩端比較算法。速度略有損失，但可讀性大大提高。再之后，就是著名的vue2.0 把sanbbdom整個庫整合掉了。

當然算法派的老大是inferno，它使用多種優化方案將性能提至最高，因此其作者便邀請進react core team，負責react的性能優化了。這個我后面會詳細。

再看擬態派。React的接口并不多，但是其組件的實現是相當有難度。它的生命周期是如何運作，需要對源碼有深刻的理解，因此它們出來得比較晚。我們的學習對象也就是它們幾個。

先說虛擬DOM。虛擬DOM就是一個普通的JS對象，通常擁有三個屬性，type, props, children。但無狀態組件出來后，children改放到props中。此外，有些元素還有ref屬性，可以是字符串與函數。在數組里，為了提高diff速度，又多出了key屬性。bable會將JSX這些屬性轉換為一個VNode對象。這是虛擬DOM的最小單元。所有虛擬DOM會組成一棵樹，叫虛擬DOM樹。

為了防止每次都是整個樹進行diff，需要形成子樹的概念，于是出現組件了。組件有render方法，會返回一個虛擬DOM，這個虛擬DOM及其子孫，就形成一棵子樹。但render方法不是虛擬DOM的東西，于是我們規定當虛擬DOM為一個函數時，如果這個函數繼承于React.Component，這個方法的實例必須有render方法。于是我們就像虛擬DOM與組件統合起來了。或者衍生這兩個稱呼，原子虛擬DOM與組件虛擬DOM。原子虛擬DOM對應元素節點，而組件則是用來產出原子虛擬DOM。此外，原子虛擬DOM還能包含一些東西，字符串與數字與null。字符串與數字對應文本節點，null對應注釋節點。

一個組件虛擬DOM實例化為組件后，會返回原子虛擬DOM或另一個組件虛擬DOM。這就形成函數式編程上的高階函數的機制，因此進行出無狀態函數組件，就是虛擬DOM的type屬性就是一個函數，不繼承其他東西了。

組件虛擬DOM的實例化過程是非常復雜，如果能簡化這過程，簡化其結構，這性能就上去了。

此外組件的實例本身就巨耗性能，因此官方推薦頁面的結構如下，通過最少量的有狀態組件（smart component）控制無狀態組件(dumb component)的變化，所有狀態通過redux在路由進行分發。

經過一番比較后，我們著手開發自己的迷你React。這個過程也比較坎坷，這還是有前人參照物的情況下，可想而知，當初facebook開發出React這樣一個獨行特立的框架時，是多么艱辛。我們在這半年總共搞了三個東西，第一還孵化失敗。

最初是基于react-lite，考慮時當時是我們母公司的人搞的，方便交流。但后來發現它的事件系統太雞肋，難以擴展，最后放棄了。

第二代是基于preact，代號qreact， 國內也有許多公司基于它做自己的迷你化方案，因為官方提供了一個preact-compat的模塊。但是preact-compat是使用Object.defineProperty來實現一些屬性名映射與同步的，因此不支持IE8，并且使用了Object.defineProperty會嚴重拖慢速度。preact本身也有不少BUG，最著名的有三個，生命周期的unmount鉤子不能保證在mount之前執行，元素節點的重復利用沒有清理樣式會導致出錯，同一組孩子下可能存在同名的key導致排序失敗。這些我們都為官方提issue，并且在我們的版本中進行修復了。第二代也公司內部幾個項目中試水落地，反映不錯。

第三代是我們團隊獨力開發，a內部代號anu，正式名稱仍然是 QReact，不過演進到了 QReact 1.0 了 （現在的版本使用了 1.0 大版本，因為之前這個版本沒被占用，所以沒跳到 2.0）。在對preact縫縫補補的過程，掌握不少核心知識，新的框架是使用全新的算法，全新的結構。由于不使用高級API，理論上能支持到IE6，但我們公司只需支持到IE8。

Qreact1.0使用requestAnimationFrame來穩定它的運行幀數，保證在60幀每秒的流暢速度。由于bable會對type進行打補丁，內部統一用typeNumber代替type進行類型判定。使用列隊保證生命周期鉤子按順序執行。使用__rerender標識一個組件在一次大的更新只會被render一次。凡此種種，經過大量測試，它們的接口與React別無二致，甚至React廢棄的接口createClass, PropTypes，我們都有相應的polyfill。

下面是Qreact1.0的測試數據。
從性能上，直追preact。

從體積上，是官方react的1/4至1/5之間。

這里透露一下React性能爆表的秘密，除了diff算法外，setState的合并操作也是一個關鍵。當組件沒有插入到DOM樹前，用戶在componentWillMount方法多次執行setState，這些state是不會觸發更新，而是存放到一個數組中，然后在render方法里進行合并與應用。當一個組件進行更新，可能是用戶在componentDidMount或者事件回調執行setState，這時更新是即時的，同步的，但這之次再setState，它就不會更新了，它的state會進入列隊。此外，如果用戶在componentWillReceiveProps多次執行setState，也會產生延遲。React這種行為是保證頁面的更新次數最少，同時用戶不會察覺它沒有更新。它只是將state進行了合并。Qreact1.0是完全遵循了這些規則，從而實現了高性能。

而在體積上，則通過刪除一些對線上沒用的代碼實現迷你化效果。

但僅是這樣不足以大吹特吹了。為了超越React的性能，從inferno與preact借簽了不少手段。

最值得一提的是hydrate機制，通過合并相鄰字符串，從而減少文本節點的生成，從而減少diff次數。

最后還有一個壓軸大戲，不做測試不知道，原來高級API是如何耗性能。通過去掉Object.freeze, Object.defineProperty這些es5方法, 框架就有10幀的提升！

說了這么多，來些實際可運行的例子吧。目前，Qreact跑通內部幾套測試，已經在金融與大搜的項目使用。它的第二版也在機票一個擁有820個模塊的大項目中試水，在IE8下良好運行。

如果大家想在項目中使用qreact,可以在webpack或ykit的config中如下配置：

resolve: {
   alias: {
      "react": "anujs",
      "react-dom": "anujs",
        // 若要兼容 IE 請使用以下配置
        // "react": "anujs/dist/ReactIE",
        // "react-dom": "anujs/dist/ReactIE",
    
        // 如果引用了 prop-types 或 create-react-class
        // 需要添加如下別名
        "prop-types": "anujs/lib/ReactPropTypes",
        "create-react-class": "anujs/lib/createClass"
        //如果你在移動端用到了onTouchTap事件
        "react-tap-event-plugin": "anujs/lib/injectTapEventPlugin",  
   }
},

如果大家對qreact在感興趣，歡迎與我聯系，也歡迎大家為我的框架加星。

https://github.com/RubyLouvre/anu/
https://github.com/YMFE/qreact