前言
可能很多人都听过防抖和节流,也是用过,但是还是有不少人不了解他们两个的,甚至有些不明白他们之间的区别,本篇文章就讲解一下他们的区别,还有实现过程
防抖:防止页面抖动抽搐的一个简称,意思是,当我们同时进行多个异步操作时,如果不加以处理,可能会出现多次请求处理,出现混乱或卡顿,因此为了避免这种现象,设置一个延迟,等待一定时间后才会执行,等待时间内会刷新等待时间,并更新执行函数
节流:防止一个功能调用频率过高,也是优化性能的一种手段,这也是服务器用的比较多的手段,能够降低服务器峰值,节省性能,也能一定程度减少人为攻击,具体操作时,执行前设置一个延迟,一定时间范围内,阻拦新到来的任务,时间结束后,开发任务执行,并设置拦截,以此往复
区别:他们都能够明显降低、减少函数执行次数,优化本地性能;不同的是防抖会忽略延时期间内的其他任务,只执行延时期间的最后一次任务,执行后,新任务到来继续延迟等待执行,更偏向于前端;节流,只执行第一个,间隔时间内的其他任务执行阻断,间隔时间后后,执行下一个新到来的任务,在阻断,更偏向于服务端
防抖函数 debounce
多次频繁执行一个操作时,为了避免卡顿和相互之间的干扰,所以出现了防抖操作,例如:搜索
防抖的操作,就是加入一个延迟,当新操作到来时,取消前面还未执行的操作,更新为最新的
//防抖
function debounce(fn, duration) {
let timeId = null
return function (...args) {
clearTimeout(timeId);
let self = this
timeId = setTimeout(() => {
fn.apply(self, args)
}, duration);
}
}
测试一下
function search(text) {
console.log('search:', text)
}
//测试很多search
function testMoreSearch() {
const debunceSearch = debounce(search, 100)
for (let idx = 0; idx < 100; idx++) {
search("第" + (idx + 1) + "个");
}
}
//执行返现打印了非常多次
testMoreSearch() //search: 第1~1000个
//优化一下
function testDebunceMoreSearch() {
const debunceSearch = debounce(search, 100)
for (let idx = 0; idx < 1000; idx++) {
debunceSearch("第" + (idx + 1) + "个");
}
}
//发现只打印了最后一次最新的
testDebunceMoreSearch() //search: 第1000个
节流函数 throttle
多次频繁执行一个操作时,为了避免一段时间内的操作频率过高,会在一段时间内屏蔽掉下一个操作,例如:服务端接口限流
节流的操作,当一个操作到来时,加入一个延时,并继续执行当前操作,当延时这段期间有新操作到来时,阻止其执行,直到延时开放即可
//节流
function throttle(fn, duration) {
let pre = Number.MIN_SAFE_INTEGER
return function (...args) {
const current = new Date().getTime()
//与上一次的时间间隔小于设定时间,直接结束
//pre默认为0,第一次间隔一定会大于duration,时间若设定时间大于这个基本没有意义(时间都溢出了难绷😂)
if (current - pre < duration) return;
pre = current
fn.apply(this, args);
}
}
测试一下
function search(text) {
console.log("search:", text);
}
function testThrottleMoreSearch() {
//对 search函数 加入节流
const debunceSearch = throttle(search, 100);
for (let idx = 0; idx < 1000; idx++) {
debunceSearch("第" + (idx + 1) + "个");
}
}
//这个案例只会打印第一个,当然要是中间等待时间超过了,函数执行完毕了,还会后续打印
testThrottleMoreSearch() // search: 第1个
最后
防抖和节流在我们平时开发中,还是会经常碰到的,算是普通开发者也会碰到的问题了,因此掌握也是有必要的
实际上根基好的同学,碰到类似场景,一说优化,基本上自然而然的会用到此类效果,只不过可能没那么在意,这只不过是总结出来的一些实现效果罢了
就比如设计模式那么多,老的开发者自然而然就用上了,甚至根本不需要参考什么设计模式,遇到场景自然而然就用上了,有些规范是实际开发过程中抽象出来的罢了😂