浏览器的卡顿与react的解决思路

以下内容是阅读过程中结合自己的思考而诞生的产物，不一定准确，但相反的，可能个人对实际情况有很大的误解。
仅做参考，欢迎指正。

前面提到浏览器显示的其实是渲染流程最后渲染出来的一张图片，而一个行为引起的副作用需要生成的最终图片，可以以多个进度的快照图片逐渐渲染出最终图片来，也可以完全准备好再直接渲染出来。

当这种‘逐渐’过程中卡顿的时间或者完全准备好卡顿的时间低于人眼感知极限的时候，页面渲染流程对于人来说就是‘丝滑顺畅’的。

人眼感知极限在200多赫兹，即每秒200多张图片，但实际上当超过60hz时，人眼对其感知就不那么明显了，而要分别60hz以上的区别时，还容易让人产生疲劳，所以60hz仍是主流。

什么是卡顿

众所都周知，js是单线程，当react处理vdom相关工作的时候，会阻塞浏览器的渲染过程，阻塞了渲染过程，那么页面就卡着。

结合上面所述，1秒60hz，相当于16.67ms至少需要渲染出1张新图，才不会觉的卡顿。

我理解这里的卡顿，并不是说优化的怎么怎么好让总工作量少了，处理的快了，而是可能虽然每次渲染出来的新内容少，但是他仍然在生成，而不会在处理过程中一直不变，然后突然渲染出来，这种抖动的、掉帧的渲染方式，容易让人觉的他卡了，而一直在变化，虽然每次变化的不多，但总体是‘流畅的’

如何避免‘抖动型卡顿’

如何解决这个问题呢？每个人设备性能是不一样的，react处理vdom相关工作时速度不一样的，显然无法从设备硬件入手；那优化react，各种处理都使用最优方案，但工作量一多、设备性能一差，该卡照样卡。

其实由上面粗体字的叙述，我理解优化思路是，硬件差处理慢，OK没问题，处理的东西多，OK也没问题，那我每次都处理一丢丢，然后你去生成图片，然后我再处理一丢丢，而且每次都卡人眼感知极限，让你感觉不到抖动或者说掉帧，这不就完了吗？

于是便诞生了时间切片

时间切片

将vdom相关的处理工作，拆分为一个个单独的宏任务（参见事件循环），将这里的每个宏任务都限制在一定的范围内（react初始为5ms），而每个任务执行完后，将执行权限交给浏览器， 让浏览器生成当前的一张图片。
那么，如果一个长任务，即便在a主机上执行需要50ms，而在b主机上执行需要100ms，那么在这种硬件设备差距悬殊的情况下，这种思路依然有效。

思考

以下为个人思考：

分给react执行的时间还是相对较少，虽然规避了掉帧，但是这种行为效率并不是很高，为了执行5ms的react任务，需要花费十来毫秒去走一遍浏览器渲染流程。
我觉得是不是能把渲染流程与脚本行为分离，让脚本一直执行，而每次渲染流程执行完后，如果发现还有脚本任务在跑，则拿取当前dom结构的快照，继续去渲染。

但这其实就不是单线程了吧。不知道是否合理或者能否实现，还需要继续阅读 & 学习。