北京APP开发公司之倒计时设计.docVIP

北京APP开发公司转载之倒计时设计 大家有可能都了解相关倒计时的设备，比如厨房闹钟。那么如何自己设计一个倒计时程序呢，下面有齿轮为您转载一篇来之sindrilin的小巢整理的一个倒计时方案。（如有侵权，请及时联系我们，我们会及时下线相关内容） 计算机是不存在倒计时这个概念的，所有的倒计时设计来源于对定时器的运用：给予一个deadline，以秒为时间间隔，在每次回调时刷新屏幕上的数字。倒计时的实现几乎没有门槛，无论NSTimer也好，GCD也罢，甚至使用CADisplayLink都能用来制作一个倒计时方案。但同样的，低门槛也意味着方案的上下限差也很大，本文打算谈谈如何设计一个倒计时方案 为什么要写这篇文章 事实上，倒计时和我目前开发的方向八竿子打不着，我也确实没有必要和想过写这么一套方案。只是这几天有朋友分享了别人设计的倒计时功能： 采用一个全局计时管理对象针对每一个倒计时按钮分配计时器，计时器会生成一个NSOperation对象来执行回调，完成倒计时功能 在抛开代码不谈的情况下，这套设计思路我也是存疑的。如果倒计时要使用operation，那就需要使用queue来完成任务。根据queue的串行并行属性，要考虑这两点： 如果queue是并行的，一个界面上存在多个倒计时按钮时，可能会新建线程来处理同一个queue的任务，这部分的开销并不是必需的 operation需要投放到queue里面启动执行。假如每秒的回调包装成operation处理，那么需要一个定时机制来投放这些operation。如果是这么，为什么不直接使用定时器，而要用operation 但在看完设计者的文章和代码之后，我发现对方根本没有考虑过上面的问题。他operation的任务思路很奇怪： 在每一个operation里面，采用while + sleep的方式，每次回调后让线程睡眠一秒，直至倒计时结束 - (void)main {?? ?......?? ?do {?? ? ? ?callback(self.leftTime);?? ? ? ?[NSThread sleepForTimeInterval: 1];?? ?} while (--self.leftTime 0);?? ?......} 这种实现有三个坑爹的地方： while循环结束之前，内部的临时变量不会被释放，存在内存占用过大的风险 如果queue是串行属性，多个operation将无法保证回调时间的正确 不应该采用sleep方式计时，这很浪费线程的执行效率 另外，应用进入后台时，所有的子线程会被停止执行任务，这个会导致了应用切换前后台后，倒计时剩余时间不准。对于这种情况一般也有三种方式来做时间校正： 保存一个倒计时deadline，在进入active后重新计算剩余倒计时 注册通知，在切换前后台时计算时长，减去这个时间更新剩余时间 创建应用后台任务，继续进行倒计时 而上面的设计采用了3的解决方案，鉴于应用在后台时，用户对应用毫无感知的特点，这几乎是最差的一种方案。于是基于这一个个槽点，我决定按照自己的想法，做一个相对高效的倒计时方案 存储结构 一套功能方案设计的目的是为了简化逻辑流程，隐藏实现细节，尽可能少的暴露接口。普通的倒计时是调用方直接使用定时器实现规律性回调，定时器需要持有调用方的信息。而倒计时设计隐藏了定时器的实现细节，只需调用方提供回调，其余的耦合关联由管理类来完成，类似的设计有Notification和Observer等 不同的考量标准和业务场景决定了不同的结构设计 即便是系统使用的两种类似的监听设计，在内部实现时，所用到的存储结构也是不同的。Notification不持有对象本身，采用保存对象地址的实现，但这样存在野指针风险。Observer会持有对象，但会造成循环引用的风险。可以说： 回调设计 在iOS中常用的回调方式包括delegate和block两种，这两种方式都能很好的处理倒计时的需求。但出于以下理由我选择了block： delegate的耦合关系强于blockdelegate在委托方和代理方中间添加了一层中间层，解除了双方的直接耦合关系，但同样的委托方和代理方需要依赖于protocol，这是这种模式必然存在的耦合关系。相比之下，block并不存在这种烦恼 更少的代码同样的回调处理下，delegate的代码量要多于block。并不是说更多的代码一定不好，只是同样符合实现需求，逻辑清晰同样清晰的情况下，后者优于前者： ??#pragma mark - delegate type??- (void)doSomething {?? ? ?/// do something?? ? ?if ([_delegate respondsToSelector: @