聊一下活动倒计时的一些实践方案与思考。方案总体来说分为两种:
当然不能简单粗暴的直接获取本地时间来倒计时,结果可能是每个用户的倒计时时间千差万别,而且用户可以恶意更改本地时间去绕过倒计时操作。
方案:接口获取到服务前当前时间以后,与本地时间做一个差值计算。循环中使用本地时间加时间差得出当前时间,来计算倒计时时间,并在一定频率内更新服务器、本地时间差值。
// 接口获取服务器当前时间,并计算与本地时间的时间差const timeDiff = serverTime - new Date().getTime()setTimeout(() => { // 当前时间 = 本地时间 + 时间差 const currTime = new Date().getTime() + timeDiff // 倒计时时间 = 截止时间 - 当前时间 const countDown = endTime - currTime // 显示倒计时信息 setCountDownInfo(countDown)}, 1000)
js
倒计时有延迟。如果单纯使用js
的setTimeout
倒计时,代码运行时间越长偏差越大,本地时间的准确性就很可以实时纠正js
倒计时的偏差。js
计时器会变慢;移动端应用进入后台运行,js计时器会直接停止,导致倒计时严重偏差。而依赖本地时间,就可以纠正这些偏差。用户也是可以修改本地时间绕过计时器的。需要一定的频率,获取服务器时间更新时间差值,防止用户修改本地时间。
js
倒计时方案:获取到服务器时间以后,js用
setTimeout
做倒计时,不依赖本地时间。
// 接口获取服务器当前时间let currTime = serverTimesetTimeout(() => { // 当前时间 = 服务器时间 循环累加 currTime = currTime + 1000 // 倒计时时间 = 截止时间 - 当前时间 const countDown = endTime - currTime // 显示倒计时信息 setCountDownInfo(countDown)}, 1000)
优点:解决了依赖本地时间的弊端
缺点:前边提过,js定时器有偏差;页面后台运行,定时器会变慢。需要一定的频率,获取服务器当前时间矫正这些偏差
无论上述哪种方案,无论矫正js
定时器偏差还是更新时间差值防止修改本地时间,频率的设定都很重要,可以根据场景区分
所以通常倒计时越接近结束时,准确性要求越高。可以根据倒计时时长,来动态设定更新频率,倒计时距离结束越近,更新的频率越高,并且设定频率最高阈值;反之同理。
比如倒计时为5分钟时,30s更新一次:(5 * 60 * 1000) / 30 = 当前时间差(ms) / 当前频率(s)
,就可以获取动态的更新频率
setTimeout
还是setInterval
setInterval
定时器间隔时间总是小于操作执行时间时,事件队列中就会排起队 :本次循环事件未执行完,下次循环的事件已经添加进队列中setInterval
时,仅当没有该定时器的任何其他代码实例时,才将定时器代码添加到队列中一定时间间隔重复做某些操作时,setInterval
可能会出现丢帧和操作之间无时间间隔的情况。所以尽量使用setTimeout,它可以保证事件在相同时间间隔内执行,并且不丢失事件。
思考三: 为什么setTimeout
时间间隔会有偏差
setTimeout
只是负责准时的把事件添加进事件队列中,但是如果js
线程在忙于执行其他任务 (处理用户交互、js
代码执行等),那么这个事件就需要等待线程空闲了才能被执行。
如果setTimeout
递归实现倒计时,上述等待js
线程产生的延迟就会在不停的循环中被叠加累计,延迟偏差就会越来越大,计时就会越来越不准。