js三座大山
一：函数式编程
js三座大山之函数1
js三座大山之函数2-作用域与动态this
二：面向对象编程
js三座大山之对象,继承,类,原型链
三：异步编程：
js三座大山之异步一单线程,event loope,宏任务&微任务
js三座大山之异步二异步方案
js三座大山之异步三promise本质
js三座大山之异步四-Promise的同步调用消除异步的传染性
js三座大山之异步五基于异步的js性能优化
背景
在js三座大山之异步一单线程,event loope,宏任务&微任务这篇文章中 我们留了一个问题， 
通过异步api 例如定时器,http,promise,i/o等将其当做异步任务，等待异步事件完成 在触发回调将函数推入到任务队列中 等待主线程去执行。避免了异步任务阻塞后续代码执行，影响用户体验。如果任务本身依然比较重，那么执行依然会造成UI卡顿，导致页面无法响应，这个问题又该如何解决？
本文主要是利用异步编程+event loop来优化js的运行性能，解决上面的问题，避免页面卡顿。要解决这个问题首先我们需要了解一些浏览器渲染的基础知识。
浏览器的一帧:执行&渲染
渲染进程的主线程负责执行js和渲染UI，不断的将变化渲染为新的UI，浏览器每秒渲染60帧，如果低于这个频率就会失帧，页面不会发生变化，造成的现象就是卡了~。fps指每秒钟页面呈现的帧数,通常用于衡量页面的流畅程度。
-
理想的渲染
case1：fps=60左右
js&render都在一帧内完成 浏览器可以正确的读取变化的UI 页面非常流畅。 -
js异常的渲染
case2:fps<60
因为js执行任务过重 导致执行时间过长 这时浏览器来渲染新的UI时 无法获取到最新的UI 所以不会重新渲染 屏幕还是上一次的UI 界面不发生变化 导致界面卡住了。 -
渲染异常的
case3:fps<60
出现这个情况大多数是因为同一时间渲染了大量的dom，因为render流程 执行时间过长 这时浏览器来渲染新的UI时 无法获取到最新的UI 所以不会重新渲染 屏幕还是上一次的UI 界面不发生变化 导致界面卡住了。我们可以采用分帧渲染的方式来优化这场景, 例如分帧组件。 vue-frame-render。 -
过渡回流重绘的
case4:
代码中有对DOM的修改操作，并且紧接着有对样式的读取操作。例如，如果你先修改了元素的宽度，然后立即读取元素的宽度，浏览器为了获取正确的宽度值，会立即进行一次回流和重绘。
关于渲染方面的优化case3&case4 可以使用的手段有很多，这里不展开讨论 本文主要针对case2 做js运行时优化。
事件循环与一帧的关系
有很多同学会认为浏览器的一帧只会执行一次js渲染一次页面，实际上并不是这样。
在一帧的时间内，浏览器会尽可能地执行JavaScript代码并进行页面渲染。
但是，通常情况下，浏览器会在一帧的结束时进行一次页面渲染，而不是在执行每段JavaScript代码后都进行渲染。这是因为页面渲染（包括回流&重绘）是一个相对昂贵的操作，频繁地进行页面渲染会消耗大量的CPU和GPU资源，降低页面的性能。
优化js运行性能：主要针对上面的case2
- 通过将长任务拆分，然后分帧去执行任务。将case2转化为case1。
- 如果是一些计算性质的任务，可以通过webworker执行，避免阻塞主线程
- 利用浏览器空闲执行
- 为了避免js执行时间过长 可以通过主动让出主线的方式 避免长时间占用 造成卡顿。
封装的任务库。具体api可以看这里 js防卡顿指北：分帧,并行,空闲执行,延迟执行~
手机的高刷新与浏览器刷新率的关系
手机的刷新率和浏览器的刷新率是两个不同的概念，但它们都与屏幕的显示效果有关。
手机的刷新率，通常指的是屏幕硬件的刷新率，也就是屏幕每秒钟刷新图像的次数。一般来说，刷新率越高，屏幕显示的动画效果就越流畅。例如，一部180Hz刷新率的手机，意味着它的屏幕每秒钟可以刷新180次。
浏览器的刷新率，览器的刷新率，也被称为帧率，通常是由浏览器内核控制的, 指是每秒钟页面呈现的帧数，用于衡量页面的流畅程度
这两者的关系在于，如果手机的刷新率高于浏览器的刷新率，那么浏览器的动画效果可能无法充分利用手机屏幕的高刷新率。例如，即使手机的刷新率是180Hz，但如果浏览器的刷新率只有60Hz，那么在浏览器中播放的动画，每秒钟也只能刷新60次，而无法达到180次。
然而，需要注意的是，提高浏览器的刷新率并不一定能提高动画的流畅度，因为动画的流畅度还取决于JavaScript的运行速度、页面的复杂度等因素。此外，提高浏览器的刷新率可能会增加CPU和GPU的负载，导致电池电量更快地消耗。因此，在实际使用中，需要根据具体情况来权衡。