去哪儿网迷你React的研发心得

 阅读约 14 分钟

去哪儿网迷你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……

clipboard.png

但问题不是简单到直接从github找一个迷你React库替换上就能搞定。之所以称为迷你,肯定有所欠缺,如果是内部实现的改良也罢,如果阉割了功能可不是闹着玩。恰恰他们就好这口,因此现有方案不能满足我们。我们需要一个能直接替换,或至少95%的业务代码不用动。这意味着这迷你框架,需要与React的接口完全一致,并且全面支持它的全家桶。当然细化一下来的需来就更多了,早期说只要支持移动,因此取名为react-mobile,后来连iE8也要支持,因此这活不能指望别人,我们自己动手撸了。

clipboard.png

我们先来一趟竞品分析。为了加快产出速度,能借鉴的尽可能借鉴。React推出以后,针对其性能研究衍生出不少库,针对其体积也诞生出大量仿品。它比jQuery更加缤纷多采。市面上竟然拥有100多个虚拟DOM库。虚拟DOM库,就是React出来后的一种新式库,以虚拟DOM与diff算法为核心,屏蔽DOM操作,操作数据即操作视图。这听起来有点像MVVM,MVVM也是屏蔽DOM操作,操作数据即操作视图,但它是以VM为核心。

clipboard.png

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库是分为两大派系:算法派与拟态派。

clipboard.png

下面将从这两大派系进行扼要的描述。

将前端回归到算法上的探索是前端框架史上的一个巨大进步。之前是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的性能优化了。这个我后面会详细。

clipboard.png

再看拟态派。React的接口并不多,但是其组件的实现是相当有难度。它的生命周期是如何运作,需要对源码有深刻的理解,因此它们出来得比较晚。我们的学习对象也就是它们几个。

clipboard.png

先说虚拟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对应注释节点。

clipboard.png

一个组件虚拟DOM实例化为组件后,会返回原子虚拟DOM或另一个组件虚拟DOM。这就形成函数式编程上的高阶函数的机制,因此进行出无状态函数组件,就是虚拟DOM的type属性就是一个函数,不继承其他东西了。

组件虚拟DOM的实例化过程是非常复杂,如果能简化这过程,简化其结构,这性能就上去了。

clipboard.png

此外组件的实例本身就巨耗性能,因此官方推荐页面的结构如下,通过最少量的有状态组件(smart component)控制无状态组件(dumb component)的变化,所有状态通过redux在路由进行分发。

clipboard.png

经过一番比较后,我们着手开发自己的迷你React。这个过程也比较坎坷,这还是有前人参照物的情况下,可想而知,当初facebook开发出React这样一个独行特立的框架时,是多么艰辛。我们在这半年总共搞了三个东西,第一还孵化失败。

clipboard.png

最初是基于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。

clipboard.png

从体积上,是官方react的1/4至1/5之间。

clipboard.png

这里透露一下React性能爆表的秘密,除了diff算法外,setState的合并操作也是一个关键。当组件没有插入到DOM树前,用户在componentWillMount方法多次执行setState,这些state是不会触发更新,而是存放到一个数组中,然后在render方法里进行合并与应用。当一个组件进行更新,可能是用户在componentDidMount或者事件回调执行setState,这时更新是即时的,同步的,但这之次再setState,它就不会更新了,它的state会进入列队。此外,如果用户在componentWillReceiveProps多次执行setState,也会产生延迟。React这种行为是保证页面的更新次数最少,同时用户不会察觉它没有更新。它只是将state进行了合并。Qreact1.0是完全遵循了这些规则,从而实现了高性能。

而在体积上,则通过删除一些对线上没用的代码实现迷你化效果。

clipboard.png

但仅是这样不足以大吹特吹了。为了超越React的性能,从inferno与preact借签了不少手段。

clipboard.png

最值得一提的是hydrate机制,通过合并相邻字符串,从而减少文本节点的生成,从而减少diff次数。

clipboard.png

最后还有一个压轴大戏,不做测试不知道,原来高级API是如何耗性能。通过去掉Object.freeze, Object.defineProperty这些es5方法, 框架就有10帧的提升!

clipboard.png

说了这么多,来些实际可运行的例子吧。目前,Qreact跑通内部几套测试,已经在金融与大搜的项目使用。它的第二版也在机票一个拥有820个模块的大项目中试水,在IE8下良好运行。

clipboard.png

如果大家想在项目中使用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

阅读 15.3k更新于 2017-09-19
推荐阅读
javascript魔法师
用户专栏

涉及我的学习心得与经验

1286 人关注
70 篇文章
专栏主页
目录