随着抢购秒杀之类的活动越来越多，倒计时几乎成了每个有交易的APP中必备的一种功能，但是随之而来的一些问题也很难缠。比如说怎么高精度的与服务端同步。
如果完全按照本地时间来处理倒计时，带来的问题是本地时间是可以随意更改的，安全性问题会比较突出，同时也显得不专业（但是淘宝是获取本地时间的）。
在此分享一下我在工作中处理倒计时的方法。
- 一个页面单个倒计时
这种情况下，处理倒计时还是比较简单，不用考虑一些在cell中出现的倒计时需要考虑复用的情况。通常的做法是和后台协商好让服务端给返回一个剩余时间——即请求接口的那一刻距离活动结束还剩余的时间。这样做完全不受本地时间更改的影响。接下来需要做的就是在请求的数据成功回调的那一刻开启一个计时器对一个全局或者局部的变量（暂且叫做A）进行每一秒+1的操作（大部分倒计时精确到秒，所以每一秒+1就行）。这样用你服务端返回的剩余时间减去你定义的A。得到的就是距离上次你请求到数据后精确的剩余时间。这种情况适用于一个页面只有一个秒杀倒计时，而且这个页面是tableview，有可能来回滚动造成cell重新赋值加载的情况。 - 页面上有很多cell，每个cell都有倒计时的情况
如图：
list.png
这种情况写每个cell都有一个倒计时在走，而且用户可以在这个页面停留很长的时间，如果使用MVC开发的模式大部分做法是将对应cell中返回的剩余时间发送个对应的cell进行倒计时显示。按照情况一下的方法处理剩余时间需要定义一个全局的变量保存一个从上次请求道数据总共走了多长时间了值，每次在cell中进行倒计时显示的时候减去这个已走的时长，剩下的就是精确地剩余时间。而且重用的问题也得到有效的解决。
这种方案误差几乎可以压制到一秒以内，唯一能产生误差的地方是服务端请求数据到客户端获取到数据这个之间网络延迟太大造成的延迟，但是既然都做抢购了相比你们公司服务器响应时间不会这么差吧。相比把所有的倒计时统一缓存起来，遍历每一个时间减去走过去的时间的方法，这种方法性能上回好一些。
这种方案对一般的仅仅有一页数据的情况下还是很好的一种解决方案，但是如果页面可以分页（上拉加载更多），这样如果一直用第一次请求数据时开启的计时器所记录的你一共走过了多少时间的话，对于第二页及接下来的数据会有较大的误差，这个时候我的方案是创建一个可变数组存放每一页请求到数据时对应的走过了多少时间。然后在cell处理对应的数据时减去对应的走过的时间值。这样逻辑会变复杂很多，如果实在嫌麻烦可以采用本地时间的方案，比较淘宝都在这么干，只要服务端做好验证，也不会出大问题。
