iOS 的倒计时有多种实现细节，Cocoa Touch 为我们提供了 NSTimer 类和 GCD 的dispatch_source_set_timer方法去更加方便的使用计时器。我们也可以很容易的的各种 UI 控件上添加倒计时功能，你只需要定时刷新一次界面，给控件文本属性重新赋新值即可，但在实际项目中，可能并没有你想的这么简单美好。
我们不妨设想一下这样的情景：
主界面上有一个注册按钮，你点击按钮 push 到下一级页面，这个页面让你输入手机号并有一个获取验证码的按钮。你填完号码，再点击“获取验证码”按钮，然后按钮上的文字开始了 60 秒的倒计时。20 秒之后你 pop 回上一级页面，那么现在的页面应该被销毁了，10 秒后再次 push 到这个注册页面，那么倒计时按钮上的文字应该是【获取验证码】还是 【30 秒后重试】？
合理交互应该是：按钮正在从 30 秒开始，继续倒计时，直到秒数为 0 然后按钮文字再次变为【获取验证码】，并且倒计时过程中，按钮不可点击。否则倒计时限制将不再有意义。
有 2 个细节需要注意：
- 界面销毁以后，计时器还在继续计时
- 重新创建界面后，如果该按钮的计时器存在，则应当立即继续倒计时。
我们要做的就是获取该按钮对应对的计时器。
有人会说，何必如此麻烦，直接将这个页面或者这个按钮写成单例不就得了？是的，单例可以轻松解决这个问题，但是这种设计模式切不可滥用，假如你的 App 有20 个页面需要获取验证码按钮，那岂不是得生成 20 个单例的 View controller ？要知道，你并不是经常需要这些页面。如果把按钮设计成单例，那更不可取，一但你修改了一个按钮，其他地方的按钮必受牵连，引发不可估计的后果。
我的一个方案是，生成一个全局的计时器管理类，它负责为每一个需要倒计时功能的按钮分配一个计时器，按钮和计时器通过一个 key 相互绑定。按钮被 dealloc 之后，计时器任然存在，直至计时结束。按钮重新生成时，计时器管理类会根据 key 决定该按钮是否需要继续倒计时。
Do it!
首先需要思考，这个计时器管理类应该是是什么样子？它的具体功能又是什么？我给它命名为WLButtonCountdownManager，它是一个全局类，可用单例设计（1 个单例类比 20 个单例页面划算得多）。它负责分配计时器并将其与按钮绑定，所以它需要有一个容器属性来存储计时器，并且还要知道，容器里是否已经有计时器在运行。那么WLButtonCountdownManager的头文件大概类似于这样：
@class WLCountdownTask;
NS_ASSUME_NONNULL_BEGIN
@interface WLButtonCountdownManager : NSObject
/**
* 获取单例
*
* @return 该类的唯一实例
*/
+ (instancetype)defaultManager;
/**
* 开始倒计时，如果倒计时管理器里具有相同的key，则直接开始回调。
*
* @param aKey 任务key，用于标示唯一性
* @param timeInterval 倒计时总时间，受操作系统后台时间限制，倒计时时间规定不得大于 120 秒.
* @param countingDown 倒计时时，会多次回调，提供当前秒数
* @param finished 倒计时结束时调用，提供当前秒数，值恒为 0
*/
- (void)scheduledCountDownWithKey:(NSString *)aKey
timeInterval:(NSTimeInterval)timeInterval
countingDown:(nullable void (^)(NSTimeInterval leftTimeInterval))countingDown
finished:(nullable void (^)(__unused NSTimeInterval finalTimeInterval))finished;
/**
* 查询倒计时任务是否存在
*
* @param akey 任务key
* @param task 任务
* @return YES - 存在， NO - 不存在
*/
- (BOOL)countdownTaskExistWithKey:(NSString *)akey task:(WLCountdownTask * _Nullable * _Nullable)task;
@end
NS_ASSUME_NONNULL_END
[*注]这里不得不提一下，对于单例的写法，各位看官仁者见仁智者见智。一个严谨的单例至少需要满足以下条件：
- 全局唯一性
①不可通过 alloc 再次分配资源
②线程安全 - 不可继承
About timer
关于计时器，我使用子线程每秒睡眠一次进行模拟，计时操作精度要求并不高，且线程池也利于管理。
第一步，子类化一个 NSOperation 的类，名为WLCountdownTask:
@interface WLCountdownTask : NSOperation
/**
* 计时中回调
*/
@property (copy, nonatomic) void (^countingDownBlcok)(NSTimeInterval timeInterval);
/**
* 计时结束后回调
*/
@property (copy, nonatomic) void (^finishedBlcok)(NSTimeInterval timeInterval);
/**
* 计时剩余时间
*/
@property (assign, atomic) NSTimeInterval leftTimeInterval;
/**
* 后台任务标识，确保程序进入后台依然能够计时
*/
@property (assign, nonatomic) UIBackgroundTaskIdentifier taskIdentifier;
/**
* `NSOperation`的`name`属性只在iOS8+中存在，这里定义一个属性，用来兼容 iOS7
*/
@property (copy, nonatomic) NSString *operationName;
@end
- (void)main {
self.taskIdentifier = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:nil];
do {
dispatch_sync(dispatch_get_main_queue(), ^{
if (self.countingDownBlcok) self.countingDownBlcok(self.leftTimeInterval);
});
[NSThread sleepForTimeInterval:1];
} while (--self.leftTimeInterval > 0);
dispatch_sync(dispatch_get_main_queue(), ^{
if (self.finishedBlcok) {
self.finishedBlcok(0);
}
});
if (self.taskIdentifier != UIBackgroundTaskInvalid) {
[[UIApplication sharedApplication] endBackgroundTask:self.taskIdentifier];
self.taskIdentifier = UIBackgroundTaskInvalid;
}
}
@end
关于后台计时问题，也可以采取缓存程序进入后台和恢复前台运行的时间戳解决。
下一步，WLButtonCountdownManager 拥有一个线程池（也叫并发操作队列，规定队列中最多只允许存在 20 个并发线程），每分配一个计时器（即创建一个子线程）就将其放入池子中，计时器跑完以后会自动从池子里销毁。
在创建计时任务之前，Manager 从池子里检索是否有相同 key 的计时任务，如果任务存在，直接回调计时操作。否则，新建一个标识为 key 的任务。
- (void)scheduledCountDownWithKey:(NSString *)aKey
timeInterval:(NSTimeInterval)timeInterval
countingDown:(void (^)(NSTimeInterval))countingDown
finished:(void (^)(NSTimeInterval))finished
{
if (timeInterval > 120) {
NSCAssert(NO, @"受操作系统后台时间限制，倒计时时间规定不得大于 120 秒.");
}
if (_pool.operations.count >= 20) // 最多 20 个并发线程
return;
WLCountdownTask *task = nil;
if ([self countdownTaskExistWithKey:aKey task:&task]) {
task.countingDownBlcok = countingDown;
task.finishedBlcok = finished;
if (countingDown && task.leftTimeInterval > 0) {
countingDown(task.leftTimeInterval);
}
} else {
task = [[WLCountdownTask alloc] init];
task.leftTimeInterval = timeInterval;
task.countingDownBlcok = countingDown;
task.finishedBlcok = finished;
if ([@([UIDevice currentDevice].systemVersion.doubleValue) compare:@(8)] == NSOrderedAscending) {
task.operationName = aKey;
}
else {
task.name = aKey;
}
[_pool addOperation:task];
}
}
- (BOOL)countdownTaskExistWithKey:(NSString *)akey
task:(WLCountdownTask *__autoreleasing _Nullable *)task
{
__block BOOL taskExist = NO;
if ([@([UIDevice currentDevice].systemVersion.doubleValue) compare:@(8)] == NSOrderedAscending) {
[_pool.operations enumerateObjectsUsingBlock:^(__kindof WLCountdownTask * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
if ([obj.operationName isEqualToString:akey]) {
if (task) *task = obj;
taskExist = YES;
*stop = YES;
}
}];
}
else {
[_pool.operations enumerateObjectsUsingBlock:^(__kindof WLCountdownTask * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
if ([obj.name isEqualToString:akey]) {
if (task) *task = obj;
taskExist = YES;
*stop = YES;
}
}];
}
return taskExist;
}
Last
至此，解决方案到此就结束了。文中难免有些疏漏的地方，你也可以参见本文 Demo 了解详细用法。如果你对这个项目有更好的方案，或者建议，非常欢迎 pull request 和我一起来完善它。
2016-10-08更新
有同学反馈，假如倒计时要求的时间比较长，如 15 分钟，该如何处理。一般来讲，用户很少会在前台连续操作 APP 长达 15 分钟（阅读，社交类 APP 除外），所以倒计时的难点会出现在程序进入后台的情况。而这种超过 2 分钟的倒计时需求比较少见，倒计时目的是防止频繁调用接口以此预防支付不必要的短信息费用。所以一种办法是和你的产品沟通，更改需求，比如 1 自然天内同一号码只允许获取 3~5 次验证码。如果失败了，参考后两种。
第二种方法是，强制让程序在后台一致保持运行，但是不建议这么做，长时间的后台运行会消耗额外的系统资源以及电量。
那么第三种方法就是，进入后台后不再进行倒计时，只需分别记录程序进入后台和再次恢复至前台的时间戳，计算时间差即可。这样即使再长的倒计时需求也可以满足，但这种方式有个缺陷，假如用户手动修改系统时间，那么计算得到的时间会有误差。
另外，有同学的需求场景是这样的：
点击按钮，向服务端发送 HTTP Request 请求获取验证码，等待服务端处理完毕获取响应体，然后根据结果判断是否应该启用倒计时。
这种情况下，只需要改写你自己实现的 Button 子类，将自动倒计时修改为手动调用倒计时。处理流程大概是这样：
