React移动web极致优化

[lcxfs1991]

React移动web极致优化

[yeatszhang]

先根据render的逻辑生成虚拟dom，再与旧的虚拟dom进行对比，求出最小dom更新操作，这是React做的事情。shouldComponentUpdate解决的是react的树形结构大了之后，虚拟dom的生成非常卡的问题，因为render方法不加限制的话每次都会执行，而shouldComponentUpdate正是为了避免不必要的render，从而提高虚拟dom的生成速度。 老实说如果不使用shouldComponentUpdate进行限制的话，react的性能是非常差的。 @lcxfs1991

[dickeylth]

慎用太新的es6语法。 Object.assign等较新的类库避免在移动端上使用，会报错。 Object.assign目前使用object-assign包

准确地说这是 ES6 引入的新的 API，http://kangax.github.io/compat-table/es6/#test-Object_static_methods_Object.assign 用之前查查兼容性，babel 配置默认只是解决 ES6 的语法翻译，这种新引入 API 得自己引入 polyfill 解决：https://babeljs.io/docs/usage/polyfill/。

[leehomeok]

nice ，干货

谢谢 @yeatszhang @lcxfs1991 指点。

@lcxfs1991 我看 react 文档里写到，render 是包含两部分的，首先是 diff 数据，然后判断是否更新 dom，在 shouldComponentUpdate 里 diff 数据相当于把 render 做的第一步动作改成了自己做。

在 compmonents 的 render 里打出了一堆 console 并不意味着走到了 render 的第二步（更新 dom），所以我说 render 执行了并不一定意味着「渲染」，因为大部分时候，diff 数据后 react 是不会更新 dom 的。

[kocokolo]

👍

[FuGardenia]

/zan

[marlonfan]

赞！

[FuGardenia]

是得慎用 Object.assign， 微信内部浏览器就不支持这语法

[small-tou]

棒

[stonewl897]

赞

[lcxfs1991]

@dickeylth like
我们现在使用的是object-assign库

[quirkyshop]

赞

[chenwery]

有一个疑问，执行了render就说明重新渲染了吗？

[marlonfan]

@chenwery render都重新执行了 肯定是重新渲染了呀...

[wadezhan]

👍

[shinken008]

赞

[youwenda]

第一次看到这么详细的React优化心得，作者很深入了解了，赞一个

[yeatszhang]

基本上所有的点都覆盖到了，十分感谢分享。 实际用起来react + redux+imutable 的架构显得有些重和繁琐，mobx更加适合轻量一点的项目？

render 并不意味着页面重新 render 吧。
ReactDOM.render() controls the contents of the container node you pass in. Any existing DOM elements inside are replaced when first called. Later calls use React’s DOM diffing algorithm for efficient updates.

在 shouldComponentUpdate 里 diff props，和在 render 的时候 diff dom 有那么大的性能差距么？

[lcxfs1991]

@yeatszhang 后面有更新。现在开始改用lodash.merge了，性能还不错，能减包不少。

[lcxfs1991]

@yeatszhang 这个解释比较清楚哈。不使用shouldComponentUpdate，在移动端性能确实不好。PC端还可以。我更正一下。

[sniperyan]

Object.assign用polyfill不就解决了吗

[yangshengdong]

immutable的toJS方法，用多了会引起性能问题吗？想用 ES6的解构语法糖？

[lcxfs1991]

@yangshengdong 会消耗呀。用了immutable尽量用它自身的api

[tao12345666333]

[LeeJim]

我挺好奇楼主如何获取性能数据的

[lcxfs1991]

@LeeJim 加载速度，我们有上报的平台，打好点上报就行了。渲染的话，mac和android各自己用对应的app就好了。

[Pines-Cheng]

请问性能数据上报平台是自己实现的还是有什么解决方案？ @lcxfs1991

[liyatang]

@Pines-Cheng 大厂肯定有部门在做数据收集平台

[tao12345666333]

@Pines-Cheng 一般都是公司内部的数据平台吧

[monkindey]

您好，这篇文章写得真好，不过我有一些疑问请教下

用户进行交互的时候，有可能会比原生的响应快一些，前提是你做了一些优化避免了浪费性能的重复渲染

这个感觉很容易误解，React其实到最后都是用到原生的DOM API，何来比原生的响应快一点呢

请尽量使用const element

const element 是不是等同于function component ?

[lcxfs1991]

@monkindey 恩，第一点可能说得再清楚点好些。

const element就是function component。

[monkindey]

@lcxfs1991 谢谢你的答疑，不过我觉得如果是function component的话，性能也不一定有更好的提升，因为它是不会被缓存和shouldcomponentupdate的，也就是说一有state改变的话，它不管什么都会执行render方法。详情可以看下这篇issue

Dan Abromov 的原话

There are currently no special optimizations done for functions, although we might add such optimizations in the future. But for now, they perform exactly as classes.

[lcxfs1991]

写的这篇文章蛮早了，具体也可以参考这篇文章：
https://medium.com/modus-create-front-end-development/component-rendering-performance-in-react-df859b474adc#.fot8umq7w
@monkindey

[monkindey]

@lcxfs1991 非常感谢

[tangkunyin]

@lcxfs1991 很赞，不知是否在rn使用过，应该也是一样的吧

[myhirra]

首屏可交互时间 是怎么计算的呢？

[lcxfs1991]

@tangkunyin 原理应该是差不多的

[lcxfs1991]

@myhirra webview打开开始计算。如果webview没提供这个，就从进入页面开始打点，到可交互的时候就打点结束，再上报这个时间。

[myhirra]

@lcxfs1991 可交互，这个是否强依赖于业务逻辑呢？ 我理解可交互是用户能点击或者看到页面具体细节的时间

[MinJieLiu]

@lcxfs1991 在 react 中有 immutable 的依赖，webpack 打包后会自带 immutable，就算不引入也自带50 kb 的大小，对吗

[lcxfs1991]

@myhirra 有一定有依赖。一般可交互主要就是可操作，例如点击，滚动等等。

[lcxfs1991]

@MinJieLiu react哪里依赖了immutable?

[MinJieLiu]

@lcxfs1991 看错了，当我没说😊

[SnowFlowers]

现在redux是使用了immutable，那么state是直接赋值的时候直接state吗。比如 this.state=fromJS({list: [1,2,3]})?. 可不可以在this.state的set方法和get方法上加钩子，直接使用fromJS和toJS？

[SnowFlowers]

频繁的fromJs(). toJS().会不会造成很大的性能消耗？

[MinJieLiu]

会，所以尽量在入口处用。

[DevinXian]

好东西，说的实在、有理有据！component 当做props 传入，主要是数据不能深层次比较，所以一般情况下都会re-render

[WangYang-Rex]

棒

[zhongjie-chen]

@yeatszhang function component 是不是性能会存在问题？

[SunXinFei]

文章很好，我正好误打误撞做了文章前半部分的，找到影响性能的原因，我现在PC端的react+redux 涉及到大量元素拖拽，产生了性能问题，我现在在维护redux中的一个数组对象，用的就是深拷贝，而且对象叶子节点改变，就会导致全部的叶子节点dom全部重新渲染，大概就是对虚拟Dom一知半解的缘故，只略知虚拟dom做了优化，可以只渲染需要重新渲染的dom节点，但是没想到我实际实验出来所有的叶子节点会走render中的console.log, 然后误打误撞感觉优化点在深拷贝和shouldUpdateReactComponent（人为控制哪些时候dom需要渲染，哪些不需要），配合immutable，应该可以解决我的拖拽效率问题，明天准备进行优化

[SunXinFei]

@lcxfs1991

你可以在每个component的render里，放一个console.log("xxx component")。然后触发一个action，在优化之前，几乎全部的component都打出这个log，表明都重复渲染了。

这里的表述好像有问题，render方法走，但是不一定去渲染，render走了之后，虚拟dom会去判断哪些需要渲染，当然大量不必要的重复render肯定会有效率问题，这确实需要优化

[fytriht]

请教下 lodash.merge 的使用场景是什么？

从直觉上看， lodash.merge 似乎不是一个好的实践， 因为它做的是 deep copy，更新深层级对象时有可能会做不必要的更新。