场景
我们的产品需求中,经常会出现类似的正计时以及倒计时需求,现在我们分一些常见的场景case进行分析。
常见场景
1 验证码发送倒计时:比如我们一般发送短信验证码有一个点击之后的60s倒计时,主要是为了防止短时间内重发短信。
2 正计时:比如答题会有一个计时统计,来增加逼迫感,并会在用户用时中使用这个计时
3 倒计时:活动开始之前的倒计时
技术方案
计时器
一般情况下,在当前页面active的情况下,我们可以使用setTimeout,或者setInterval来进行相应时间段的计时。
客户端时间纠正
然而,在有些情况下我们的计时可能不准确,这取决于你的界面在移到后台时,其进程是否会被停止。
不管停止与否,我们都可以根据客户端时间进行一次纠正,当然这需要记录一个开始时间,然后用此时的系统时间减去开始时间,加一个计算时间差并格式化的工具函数即可
备注:一般情况下,app都可以监听到应用是否移动到前台,通知给前端即可,app可以提供一个sdk的状态变更方法;而浏览器也提供了一个方法可以用于监听当前页面是否在视图内(移动到视图的时候,重新获取系统时间即可)。
window.onblur = function () {
console.log("失去焦点");
}
document.addEventListener('visibilitychange',function(){
if(document.visibilityState==='hidden'){
console.log("选项卡切换");
}
});
服务端时间纠正
当然如果你的业务对时间特别敏感,那么可以发送一次接口请求,以得到的服务器此时时间为准。
备注:得到服务器时间之后,要清楚这个时间是有一定误差的,这个误差是指接口从请求到客户端请求的时间差,你在得到这个时间后需要减去其时间差,并考虑这个时间差对时间段的影响,有必要的话做请求时间的分布分析,得出一个可用于当做标准量的时间来做差值。
比如大促、购买截止时间、答题竞赛的计时等都建议可以进行服务端计时的纠正。
更多
是否具有开始时间
在知晓结束时间之后,我们还要考虑我们的程序中的开始时间是否准确,如果这个时间不准确或者已经被程序销毁,那么计时也是有问题的。
建议如下:
1 机测程序的生命周期以及开始时间是否准确
2 必要的情况下,把应用开始的时间进行服务器或客户端长久缓存
以前端产品显示优先还是后端差值优先
1 不严格使用计时器这样的计算结果来保证业务。因为除了上面的原因,我们也要知道计时器并不是真正的计时准确,可以去了解下事件循环机制。
2 为了时间的准确性,需要增加计时校验次数以及频率,以防止在产品体验中,计时的突变,比如计时的最小单位是1s,那么校验的间隔也最少是1s,也可缩小到100ms,然后注意调整此时的计时器的下一次执行时间
3 其实,理论上,不一定要用计时器做,用客户端时间校验的方式,或者服务端校验的方式也可以实现计时,不过这样可能会导致页面没有计时器的方式好,会有其他的成本。毕竟在大多数情况下,使用计时器计时只是在少数情况下存在误差。
同一时间提交 ,结果一定相同么
在产品中务必要增加相应的产品概念叫产品计时误差,提交时间误差,提交队列。
在较多的产品中,我们看似同一时间操作的业务,实际在后端也会有进一步时间的区分,以及请求队列的区分,可能是因为请求网络性能,也可能是因为一些优先级顺序,也可能是并发针对处理做的队列化处理。
前端时间差弱化
在不需要用户界面显示计时的业务中,在功能设计时可以这样考虑。
1 开始时,给服务端发送一个开始计时的操作
2 结束时,给服务端发一个结束计时操作
3 让后端对比这两个时间的插值,并运用到业务中