无锡快速建设网站方法,湖南seo推广,石家庄工程官网,网站开发一般用的什么架构概述
React 的 Fiber 架构, 它的整个设计思想就是去参考CPU的调度策略CPU现在都是多核多进程的#xff0c;重点研究的是 CPU是单核单线程#xff0c;它是如何调度的?为什么要去研究单线程的CPU#xff1f; 浏览器中的JS它是单线程的JS 的执行线程和浏览器的渲染GUI 是互斥…概述
React 的 Fiber 架构, 它的整个设计思想就是去参考CPU的调度策略CPU现在都是多核多进程的重点研究的是 CPU是单核单线程它是如何调度的?为什么要去研究单线程的CPU 浏览器中的JS它是单线程的JS 的执行线程和浏览器的渲染GUI 是互斥的渲染和JS的执行都用同一个线程因为一次只能做一件事情所以互斥所以React整个架构的整个调度都是去参考 CPU 的
单线程CPU调度策略 单处理器进程调度策略 1 ) 先到先得(First-Come-First-Served,FCFS) 可以把 CPU 理解为一个办事窗口, 比如说排队有的人办的慢有的人办的快比如有人办事只需要一分钟有的人却很墨迹办事要半个小时办事墨迹的人后面的人都一直在等着所以这个先到先得的策略对于CPU来讲其实就是不合理的不能谁先来就先执行因为有的人比较着急(优先级高)放在后面不适合这是最简单的调度策略简单说就是没有调度谁先来谁就先执行执行完毕后就执行下一个不过如果中间某些进程因为I/O阻塞了这些进程可能会重新排队了需要留意的事FCFS对短进程不利 短进程即执行时间非常短的进程可以用饭堂排队来比喻 在饭堂排队打饭的时候一个人打包好几份这些人就像长进程一样霸占着CPU资源后面排队只打一份的人会觉得很吃亏打一份的人会觉得它们优先级应该更高毕竟它们花的时间很短反正你打包那么多份再等一会也是可以的何必让后面那么多人等这么久… FCFS对I/0密集不利 I/O密集型进程这里特指同步I/O)在进行I/O操作时会阻塞休眠这会导致进程重新被放入就绪队列等待下一次可以类比银行部门办业务假设CPU一个窗口、I/O一个窗口在CPU窗口好不容易排到你了这时候发现一个不符合条件或者漏办了需要去 I/O 搞一下要去I/O窗口排队I/O执行完了到CPU窗口又得重新排队这样似乎也是不合理的 所以FCFS这种原始的策略在单处理器进程调度中并不受欢迎 2 轮转调度 轮转调度它是基于时钟的一种抢占策略CPU的时钟其实就是根据它的这个帧幅周期这个就跟吃大锅饭一样也没有体现一种权重最后, 比如说有人有急事那这个时候搞轮转也是不合适的它属于抢占策略中最简单的一种 公平地给每一个进程一定的执行时间当时间消耗完毕或阻塞操作系统就会调度其他进程将执行权抢占过来 决策模式 抢占策略相对应的有非抢占策略非抢占策略指的是让进程运行直到结束、阻塞如I/O或睡眠或者主动让出控制权抢占策略支持中断正在运行的进程将主动权掌握在操作系统这里不过通常开销会比较大 这种调度策略的要点是 确定合适的时间片长度太长了长进程霸占太久资源其他进程会得不到响应等待执行时间过长)这时候就跟上述的FCFS没什么区别了太短了也不好因为进程抢占和切换都是需要成本的而且成本不低时间片太短时间可能都浪费在上下文切换上了导致进程干不了什么实事 因此时间片的长度最好符合大部分进程完成一次典型交互所需的时间轮转策略非常容易理解只不过确定时间片长度需要伤点脑筋另外和FCFS一样轮转策略对I/O进程还是不公平 3 最短进程优先(Shortest Process Next,SPN) 什么是短进程呢短进程就跟排队一样比如我办事一分钟我就是短进程你墨迹半个小时你就是长进程所以可以设计一种调度策略叫短进程优先如果说我办的快我就优先那慢的一直在后面等着这样好像也有点不对劲所以这个也有缺陷长进程就会饥饿可能永远得不到响应没法去执行, 所以这个也不行上面说了先到先得策略对短进程不公平最短进程优先索性就让最短的进程优先执行也就是说按照进程的预估执行时间对进程进行优先级排序先执行完短进程后执行长进程这是一种非抢占策略这样可以让短进程能得到较快的响应但怎么获取或者评估进程执行时间呢 一是让程序的提供者提供这不太靠谱二是由操作系统来收集进程运行数据并对它们进程统计分析 例如最简单的是计算它们的平均运行时间不管怎么说都比上面两种策略要复杂一点SPN的缺陷是 如果系统有大量的短进程那么长进程可能会饥饿得不到响应另外因为它不是抢占性策略尽管现在短进程可以得到更多的执行机会但是还是没有解决FCFS的问题一旦长进程得到CPU资源得等它执行完导致后面的进程得不到响应 其他策略 最短余(Shortest Remaining Time,SRT)最高响应比优先(HRRN)反馈法这里不再举例
前端框架解决上述问题的方向
对于前端框架来说解决这种问题有三个方向 1 优化每个任务让它有多快就多快。挤压CPU运算量 Vue 选择的是这一种对于Vue来说使用模板让它有了很多优化的空间Vue使用依赖收集基于Proxy来监听数据的变化在get时收集依赖在set时触发依赖渲染页面配合响应式机制可以让Vue精确地进行节点更新 2 快速响应用户让用户觉得够快不能阻塞用户的交互(React分片) React选择了这一种一个任务假如说要运行1秒钟那React通过分片之后可能用了1.2秒但是它却让你感觉很快实际上它的执行时间是没有降低的但是它会让你感觉快React 的 Reconcilatin 是 CPU 密集型的操作它就相当于我们上面讲的长进程所以初衷和进程调度一样要让高优先级的进程或短进程优先运行不能让长进程长期霸占资源 3 尝试Worker多线程 要保证状态和视图的一致性相当麻烦这里不再赘述
React 不同模式的效果对比
1 同步模式下的 React, 可以看到阻塞比较严重 2 ) 异步 Concurrent 模式下的 React, 可以看到非常流畅 React是怎么优化的
为了给用户制造一种应用很快的假象不能让一个程序长期霸占着资源可以将浏览器的渲染、布局、绘制、资源加载例如HTML解析、事件响应、脚本执行视作操作系统的进程需要通过某些调度策略合理地分配CPU资源从而提高浏览器的用户响应速率同时兼顾任务执行效率所以React通过Fiber架构让 Reconcilation 过程变成可被中断适时地让出CPU执行权让浏览器及时地响应用户的交互
