这篇文章主要介绍“怎么从Context源码实现React性能优化”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“怎么从Context源码实现React性能优化”文章能帮助大家解决问题。组件render的时机Context的实现与组件的render息息相关。在讲解其实现前，我们先来了解render的时机。换句话说，组件在什么时候render?这个问题的答案，已经在React组件到底什么时候render啊聊过。在这里再概括下：在React中，每当触发更新(比如调用this.setState、useState)，会为组件创建对应的fiber节点。fiber节点互相链接形成一棵Fiber树。有2种方式创建fiber节点：bailout，即复用前一次更新该组件对应的fiber节点作为本次更新的fiber节点。render，经过diff算法后生成一个新fiber节点。组件的render(比如ClassComponent的render方法调用、FunctionComponent的执行)就发生在这一步。经常有同学问：React每次更新都会重新生成一棵Fiber树，性能不会差么?React性能确实不算很棒。但如你所见，Fiber树生成过程中并不是所有组件都会render，有些满足优化条件的组件会走bailout逻辑。比如，对于如下Demo：在线Demo地址[2]点击Parent组件的div子组件，触发更新，但是child render!并不会打印。这是因为Son组件会进入bailout逻辑。bailout的条件要进入bailout逻辑，需同时满足4个条件：1.oldProps === newProps即本次更新的props全等于上次更新的props。注意这里是全等比较。我们知道组件render会返回JSX，JSX是React.createElement的语法糖。所以render的返回结果实际上是React.createElement的执行结果，即一个包含props属性的对象。即使本次更新与上次更新props中每一项参数都没有变化，但是本次更新是React.createElement的执行结果，是一个全新的props引用，所以oldProps !== newProps。2.context value没有变化我们知道在当前React版本中，同时存在新老两种context，这里指老版本context。3.workInProgress.type === current.type更新前后fiber.type不变，比如div没变为p。4.!includesSomeLane(renderLanes, updateLanes) ?当前fiber上是否存在更新，如果存在那么更新的优先级是否和本次整棵Fiber树调度的优先级一致?如果一致代表该组件上存在更新，需要走render逻辑。bailout的优化还不止如此。如果一棵fiber子树所有节点都没有更新，即使所有子孙fiber都走bailout逻辑，还是有遍历的成本。所以，在bailout中，会检查该fiber的所有子孙fiber是否满足条件4(该检查时间复杂度O(1))。如果所有子孙fiber本次都没有更新需要执行，则bailout会直接返回null。整棵子树都被跳过。不会bailout也不会render，就像不存在一样。对应的DOM不会产生任何变化。老Context API的实现现在我们大体了解了render的时机。有了这个概念，就能理解ContextAPI是如何实现的，以及为什么被重构。我们先看被废弃的老ContextAPI的实现。Fiber树的生成过程是通过遍历实现的可中断递归，所以分为递和归2个阶段。Context对应数据会保存在栈中。在递阶段，Context不断入栈。所以Concumer可以通过Context栈向上找到对应的context value。在归阶段，Context不断出栈。那么老ContextAPI为什么被废弃呢?因为他没法和shouldComponentUpdate或Memo等性能优化手段配合。shouldComponentUpdate的实现要探究更深层的原因，我们需要了解shouldComponentUpdate的原理，后文简称其为SCU。使用SCU是为了减少不必要的render，换句话说：让本该render的组件走bailout逻辑。刚才我们介绍了bailout需要满足的条件。那么SCU是作用于这4个条件的哪个呢?显然是第一条：oldProps === newProps当使用shouldComponentUpdate，这个组件bailout的条件会产生变化：– old 香港云主机Props === newProps++ SCU === false同理，使用PureComponenet和React.memo时，bailout的条件也会产生变化：– oldProps === newProps++ 浅比较oldProps与newsProps相等回到老ContextAPI。当这些性能优化手段：使组件命中bailout逻辑同时如果组件的子树都满足bailout的条件4那么该fiber子树不会再继续遍历生成。换言之，不会再经历Context的入栈、出栈。这种情况下，即使context value变化，子孙组件也没法检测到。新Context API的实现知道老ContextAPI的缺陷，我们再来看新ContextAPI是如何实现的。当通过：创建context实例后，需要使用Provider提供value，使用Consumer或useContext订阅value。如：使用：{num}当遍历组件生成对应fiber时，遍历到Ctx.Provider组件，Ctx.Provider内部会判断context value是否变化。如果context value变化，Ctx.Provider内部会执行一次向下深度优先遍历子树的操作，寻找与该Provider配套的Consumer。在上文的例子中会最终找到useContext(Ctx)的Child组件对应的fiber，并为该fiber触发一次更新。注意这里的实现非常巧妙：一般更新是由组件调用触发更新的方法产生。比如上文的NumProvider组件，点击button调用add会触发一次更新。触发更新的本质是为了让组件创建对应fiber时不满足bailout条件4：!includesSomeLane(renderLanes, updateLanes) ?从而进入render逻辑。在这里，Ctx.Provider中context value变化，Ctx.Provider向下找到消费context value的组件Child，为其fiber触发一次更新。则Child对应fiber就不满足条件4。这就解决了老ContextAPI的问题：由于Child对应fiber不满足条件4，所以从Ctx.Provider到Child，这棵子树没法满足：!! 子树中所有子孙节点都满足条件4所以即使遍历中途有组件进入bailout逻辑，也不会返回null，即不会无视这棵子树的遍历。最终遍历进行到Child，由于其不满足条件4，会进入render逻辑，调用组件对应函数。{num}在函数调用中会调用useContext从Context栈中找到对应更新后的context value并返回。关于“怎么从Context源码实现React性能优化”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注开发云行业资讯频道，小编每天都会为大家更新不同的知识点。
这篇文章主要介绍了win10怎么设置双系统启动顺序的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇win10怎么设置双系统启动顺序文章都会有所收获，下面我们一起来看看吧。1，登录你的Win10系统，找到“此电脑”（“我的电脑”在Wi…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
