转载

定时器集合 NSTimer dispatch_source_t & dispatch

零、说在前面的

最近趁着悠闲，所以总是想写点什么，主要是为了总结。不总结、恐怕以后就被遗忘了，总结一下、也能很好的巩固一下。

在介绍主题之前，先来看看下面的这张图片：

项目简单整理

这张图片，没有什么，就是一个目录的简单整理。我在 iOS项目的搭建到分发的介绍中有一个实际的项目，有几个简简单单的小功能与三个小 pod 库之外也没有什么，感兴趣的话可以去看看。

在即将介绍的时间集合过程中，也会有一个简单的项目。记得下载。本介绍仅仅是对所有的定时器的简单时间而已，看似简单，里面可能有你未曾注意的地方。本文介绍的都是一些细枝末节的技术点，往往会在面试的过程中起到关键性的作用。

代码在这里 HGTimeSet 、欢迎下载。

一、定时器集合

强调一下：本篇介绍仅仅是介绍如何的去使用各种的定时器、以及避免错误的使用方式而已，对于详细的底层原理，我没有打算要介绍。毕竟定时器的底层原理是与 Runloop 有关的，那是一个很大的话题。

大概先在这里列举一下接下来要介绍的在 iOS 开发中可能会用到的定时器：

系统分类（NSDelayedPerforming）方法
线程派发 dispatch_after
NSTimer
dispatch_source_t
CADisplayLink

1.1 NSDelayedPerforming

点击进去，会看到如下几个方法，前两个就是定时器方法：

定时器集合 NSTimer dispatch_source_t & dispatch

NSDelayedPerforming 分类方法

一个简单的例子：

NSLog(@"123");// 三秒过后再执行[self performSelector:@selector(testSelectorDelay) withObject:nil afterDelay:3];NSLog(@"321");

测试方法：

// 一个简单的测试方法- (void)testSelectorDelay {    NSLog(@"testSelectorDelay");
}

打印顺序是这样的： 123、321、testSelectorDelay。说明这么使用不会阻塞当前的线程、在使用上也不会出现什么问题，正常使用即可。

1.2 线程派发 dispatch_after

代码如下：

NSLog(@"123");    
    // 3秒钟之后执行 block
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{        NSLog(@"定时器触发");
    });    
    NSLog(@"321");

运行代码，打印顺序是：123、321、定时器触发。也说明这么使用不会阻塞当前的线程、在使用上也不会出现什么问题，正常使用即可。

综上的两个定时器，一般只要是正常使用，就没有什么问题。但是有一个问题，一旦使用，根本就没有方法暂停定时器。这是一个痛点。

1.3 NSTimer

这个定时器是大家再熟悉不过的了。这个定时器，有两种使用方式：Block 与 Target。接下来看看都是如何使用之。

在这里想插一嘴的是，关于这个定时器的类创建方法是分为两大类的，分别是以 timer、scheduled的，具体有什么区别，如果你不知道的话、那就是很少使用，或者就是每次使用都是在 copy 别人的代码，那么现在可以去查看相关文档以及亲自试验一下。

除了以上特点，还有一个是即将要介绍的特点：支持 Block 与 Target 两种使用方式，接下来分别介绍一下。

在接下来的所有介绍中，每个定时器的 repeats 的值都是 YES。

1.3.1 Timer Block

第一种使用方式

具体使用，如下：

// 开启定时 repeats 的值是 YES
[NSTimer scheduledTimerWithTimeInterval:3 repeats:YES block:^(NSTimer * _Nonnull timer) {        NSLog(@"定时器的 Block 被执行");
}];

很简单、也正常。但是有一个问题：这个定时器根本停不下来。

处理方式，很简单。弄一个 NSTimer 的属性来与之关联，就能在指定的时机停止当前的定时功能。

定义一个这个的属性：

// 现在的内存语义是 strong@property (nonatomic, strong) NSTimer* blockTimer;

比如，我们希望在当前使用对象销毁的时候，停止定时器，那么我们可以这么做：

- (void)dealloc {#if DEBUG
    NSLog(@"你的离开，是我唯一的期待");#endif
    
    // 停止定时器
    {        // 尽量不要使用 self.blockTimer
        [_blockTimer invalidate];
        _blockTimer = nil;
    }
}

运行代码，发现现在定时器能正常的在当前对象中使用时，能在销毁的时候停止了。

上面有两个地方的注释，感觉怪怪的，值得注意一下：

// 尽量不要使用 self.blockTimer 几乎所以的大神都建议，在 dealloc 方法中，尽量不要使用 . 语法对成员变量的访问。会容易触发 KVO 以及其它额外的操作。当然了，这是一个习惯的问题，如果这个属性根本就没有做任何的 KVO 以及实现什么 getter 与 setter 方法的话，也没有什么影响。但是有一个问题是，当前的 class 没有做，不代表以后的子类不做。所以尽量不要使用 . 语法。
// 现在的内存语义是 strong 关于这个注释，看下面的介绍

在上面的例子中，其实 blockTimer 完全没有必要弄成一个属性的，简单的定义一个成员变量即可。但是我这么弄，是有目的的。接下来，我们把这里的内存语义由 strong 变成 weak，看看会有什么效果。

想想刚刚我们为了出来定时器根本停不下来的时候，才定义这么一个属性，现在将这个内存语义变成了 weak，这个时候回想到我们是怎么给这个属性赋值的：

// 开启定时 repeats 的值是 YESself.blockTimer = [NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {    NSLog(@"定时器的 Block 被执行");
}];

是的，直接将创建好的一个定时器给了一个 weak 类型的指针。这样，不可以吧？！运行代码看看效果。

运行代码之后发现，功能完全没有受到任何的威胁。仔细的研究之后，发现主要的原因_blockTimer 这个成员变量一直都是有值的。但是这个属性是 weak 指针呐，那么又说明另一个问题，在另一个地方还有一个类似强指针的指针指向了这个定时器的内存（这里我只敢说是类似因为我还没有看过具体的源码，暂时是猜的）。

好像这个 strong 与 weak 对我们的影响不是太大，只要我们最后能调用 invalidate 以及设置成 nil 就没有其它的什么问题。是的，确实是这样，但是我也不是随便这么一说的，我说出来，还是有点道理的，怕你在接下来被我所说的产生更大的误解。

接下来，我想让你忘记 blockTimer 这个属性、假装我从来没有定义过。但是我的代码，想改成这个样子的：

// 开启定时 repeats 的值是 YES 没有 blockTimer[NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {    NSLog(@"定时器的 Block 被执行, %@", self);
}];

一看这代码就与刚开始的代码一样啊，再仔细一看仅仅是在 block 使用了一下 self 而已。刚开始的时候，发生的事故是定时器根本就停不下来。这一次又会发生点什么呢？运行代码，就会发现这次不仅是定时器根本就停不下来这么简单了，就连当前的实例对象也无法释放了。换言之，内存泄漏了。我左看下看，也没有看到哪里出现了指针循环啊。带着无限的恐惧，修改成这样：

// 将 self 弱化__weak typeof(self) weakSelf = self;// 开启定时 repeats 的值是 YES 没有 blockTimer[NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {    NSLog(@"定时器的 Block 被执行, %@", weakSelf);
}];

运行代码，有新的结论了：当前的实例对象 self 能正常的销毁了，但是呢问题有回到了定时器根本停不下来的状态 block 中的 weakSelf 一直为空。那这说明了什么呢？说明上面的那一个结论：在另一个地方还有一个类似强指针的指针指向了这个定时器的内存。所谓的另一个地方应该就是与这个 self 是有关的，有类似强指针的指针关系的。

上面的每种使用都有问题，那么应该如何才算是正确的使用呢？经过上述介绍，就是最后一种方式配合 blockTimer 来使用即可，最终应该这样使用：

// 将 self 弱化__weak typeof(self) weakSelf = self;// 开启定时 repeats 的值是 YES 没有 blockTimerself.blockTimer = [NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {   NSLog(@"定时器的 Block 被执行, %@", weakSelf);
}];

完美的解决了如下的问题：

定时器根本停不下来
强指针导致内存泄漏

关于 blockTimer 是 weak 还是 strong，主要看心情吧。暂时还没有发现其它的什么问题。

上面对 Block 已经通过两个问题，介绍了一堆的东西。在接下来的 Target 中，如果与上面有重复的、类似的，我就不提了。

1.3.2 Timer Target

同样，先弄一个简单的代码：

// 开启定时 repeats 的值是 YES[NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(testTimer) userInfo:nil repeats:YES];

执行方法：

// 测试方法- (void)testTimer {    NSLog(@"testTimer");
}

运行代码，发现两个问题：

根本停不下来
当前实例对象根本不能销毁

厉害了，好像更严重了。如何解决根本停不下来的问题呢？与上面 Block 方式的解决方法一样？那肯定不行的，因为这个当前的实例对象，根本就没有销毁，以至于根本就不会调用 -dealloc 的方法。

那么就只能在希望当前实例对象即将需要销毁的时候关闭定时器，但是这个也是不可能的，因为没有提供这样的方法。那就使用代理吧。厉害了，这个代理不是 delegate，而是 NSProxy。这个代理，在很久之前见到过，只可惜没有用过，更别说研究过，更别说面试官问的时候能回答得上来。[有种相见恨晚的感觉]

直接上代码：

定义一个代理：

/**
 一个代理定时器
 */@interface HGProxy :  NSProxy@property (nonatomic, weak) id target;@end@implementation HGProxy- (void)proxyAction {#pragma clang diagnostic push#pragma clang diagnostic ignored "-Wundeclared-selector"
    //
    [_target performSelector:@selector(timerAction)];    
#pragma clang diagnostic pop
    }@end

具体的使用方法：

// 代理  注意:没有 init 方法HGProxy* proxy = [HGProxy alloc];// 一定要设置这个值proxy.target = self;// 开启定时 repeats 的值是 YES[NSTimer scheduledTimerWithTimeInterval:1 target:proxy selector:@selector(proxyAction) userInfo:nil repeats:YES];

上面的代码，好好的看注释。运行代码，完美的解决问题。但是，太繁琐了，使用起来特别的别扭，感觉方法调来调去的。这个方法是没有问题，但是使用很别扭，还有更好的方案么？答案肯定是：有的。预知详细内容，请见下节分享。

1.3.3 YYKit 中对 NSTimer 的处理

很多的面试官，就完全可以使用这个问题来反映出面试者是否看过 YYKit 这份优秀的代码。在 YYKit 中有两个文件做了处理。

关于 Target 的其它优化方案，在 YYKit 中还有两种处理方案，特别的棒。就是这两种：

主要是这个两个文件：NSTimer+YYAdd 与 YYWeakProxy，在我的 demo 中也有实现。

1.4 dispatch_source_t

这也是一个很常见的定时器，只是在使用起来有那么一点的复杂，但是复杂归复杂，功能还是比上面的多的。比如，能通过 block 监听定时器的取消事件。更多的代码，请见 demo，这里将一小段代码展示如下：

// 定时执行的 blockdispatch_source_set_event_handler(_timer, ^{    NSLog(@"定时执行的 block 被执行");
});// 取消定时器时执行的 block 被dispatch_source_cancel触发dispatch_source_set_cancel_handler(_timer, ^{    NSLog(@"取消定时器时执行的 block 被执行");
});

这个定时器与 NSTimer 定时器有所不同，不需要在 -dealloc 中特意的关闭定时器，这里的关闭主要是指取消。上面的代码是没有问题的，一但当前的实例对象呗销毁了，这个定时器自动就停止了。但是如果需要在取消的时候，去做一些收尾工作的话，那就需要调用一下这个行数了 dispatch_source_cancel 。所以一般情况还是需要在 -dealloc 中关闭一下比较好。

那这个定时器，在使用的过程中需要注意点什么呢？看下面的代码：

// 定时执行的 blockdispatch_source_set_event_handler(_timer, ^{    NSLog(@"定时执行的 block 被执行 %@", self);
});// 取消定时器时执行的 block 被dispatch_source_cancel触发dispatch_source_set_cancel_handler(_timer, ^{    NSLog(@"取消定时器时执行的 block 被执行 %@", self);
});

是的、我又开始搞事情了。指针循环了，看了半天没有循环啊，但是确实是循环了。-dealloc 根本不是被调用。

所以，这里需要注意的是，在以上的两个 block 中，一定要对 self 弱化。这样的，就没有事了：

// weak self__weak typeof(self) weakSelf = self;// 定时执行的 blockdispatch_source_set_event_handler(_timer, ^{    NSLog(@"定时执行的 block 被执行 %@", weakSelf);
});// 取消定时器时执行的 block 被dispatch_source_cancel触发dispatch_source_set_cancel_handler(_timer, ^{    // 如果是在 -dealloc 中被取消的话, weakSlef 是没有值的.根据这个特点,可以判断是否是在 -dealloc 中被取消的
    NSLog(@"取消定时器时执行的 block 被执行 %@", weakSelf);
});

OK 了，相对来说，这种定时器的处理方式还算可以，不是那么的复杂。只是这个指针循环隐藏得有点不容易被发现。还有一个特殊的地方就是这个定时器可以通过 block 监听到取消事件。

1.5 CADisplayLink

这种定时器的特点就是，频率与屏幕的刷新频率一致。具体的使用，代码如下：

开启一个定时器
[CADisplayLink displayLinkWithTarget:self selector:@selector(testDisplayLink)];

测试方法是这样的：

// 测试方法- (void)testDisplayLink {    NSLog(@"testDisplayLink");
}

运行代码，发现不能运行，正常的姿势是需要将这个定时器加入到当前 Runloop 的模式下，这样的：

CADisplayLink *displayLink = [CADisplayLink displayLinkWithTarget:self selector:@selector(testDisplayLink)];
[displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSRunLoopCommonModes];

这样就能正常的运行起来了。但是最终发现，出现了像 NSTimer 的 Target 一模一样的问题，解决方案也是一抹一样的，这里不赘述了。

二、总结

综上所述，关于定时器的使用，无外乎就是要注意在使用定时器的过程中所带来的内存泄漏的问题。如果不是亲自的实现，是很难发现的。这主要的原因还是因为在内部做了一下强引用的关联，然后没有被暴露出来，导致很难被发现。上面的介绍中也一一的给出了，不同的解决方案。

在使用方面，不同的定时器也有着不一样的用法。大致就是:

系统分类（NSDelayedPerforming）与线程派发（dispatch_after）这两中是不可控的，无法将其关闭，同时呢也是不是重复的。
dispatch_source_t 定时器的特点就是你能监听定时器被取消。往往用在当定时器被取消之后立马要处理一些处理的时候，显得特别的方便。
NSTimer 与CADisplayLink，同病相怜，有很多的相似之处，在用法上也有所不同。第一个就是频率的不同，还有一个是：CADisplayLink被默认加入在 Runloop 中，需要手动添加。当然，要说明一下的是，所有的定时器都是与 Runloop 有关的，可以查看相关的资料。

如果由于刚刚时间仓促，忘记了下拉代码，那么可以直接点击这里点击这里点击这里。

要是有什么不对的、或者需要补充的，感谢评论讨论！

我的更多文章，可以直接看这里 NewStart NewStart NewStart

谢谢大家！

作者：CoderHG
链接：https://www.jianshu.com/p/f775b008532a

原文 http://www.cocoachina.com/ios/20180416/23018.html

正文到此结束