移动端如何写一个相对靠谱的倒数秒杀时间或者说开售时间

开始接到这个需求的时间感觉,诶和倒数计差不多嘛应该很简单,但是细细想来.如果要求的比较高的话还是比较复杂的

第一种方案:获取剩余开售时间

剩余.png

这种方式存在明显的缺陷,就是当App进程被杀死后或者计时器停止之后再次进去界面显示的时间肯定是错误的,不建议使用.

第二种方案:获取开售时间的时间戳

Snip20170104_18.png

通过获取开售时间的时间戳对比本地时间,算出剩余时间相对上面的方便要准确,但是还有一个问题就是当用户修改本地时间之后,如果没有特别要求在最后购买的时候服务器在做一次限制还是可以的,双11的时候特地看了下淘宝的H5页面也是获取的本地时间,但是他在内部的秒杀也是用了其他方法待我下面慢慢道来

第三种方案:开售时间的时间戳与网络校准时间对比

Snip20170103_13.png

与第二种方法相比多加了一步时间校准的过程,网络获取的当前时间与当前本地时间对比,算出的时间差
时间差=本地时间-网络时间
剩余时间=开售时间-(本地时间-时间差)
这种方案还算是比较精确了,但是在断网之后这方法就会失效,不过断网了又能干嘛呢,但是为了精益求精原则分析了大量的材料与App之后,还有一种终极方法,请看下面的第四种方案.

第四种方案:网络校准时间 + 本地时间 + 开机时长同时校准

Snip20170103_15.png

这种方式是对上面的几种方案的强化

Snip20170103_16.png

不知道你们这个图是否能看懂
比如说现在开机时间是1000秒当前网络时间是1点整,第二次启动应用的时候没有网络,开机时间是1600秒,那么当前时间就是1点+1600-1000 = 1点10分这样就算是在断网情况下用户修改了时间还是可以得到相对准确定时间,当然重启之后这个方法就失效了,所以需要判断记录的时间是否比当前时间大.
iOS和Android的获取开机时长的方法都是有的,大家自己去Google百度一下吧

总结

具体实现还是要看具体情况,利用234方案穿插使用应该是能满足大部分的需求的~
猜猜最后我们用了哪种方案~~~~