在我们做iOS开发的过程中,经常会与多线程打交道,异步绘制,网络请求等,方式有NSThread,NSOperationQueue,GCD等,在这里GCD的地位举足轻重,那么今天写一篇关于GCD的文章。首先迎来第一个问题:
什么是GCD
全名叫 Grand Central Dispatch 是一种异步执行任务的技术,一套基于c语言实现的api,语法十分简洁,只需要简单定义任务或按需加入到队列中,就可以按照计划实现功能,下面一个简单的例子。
dispatch_async(dispatch_get_global_queue(0, 0), ^{
//网络请求
//异步绘制图像
//数据库访问等
dispatch_async(dispatch_get_main_queue(), ^{
//刷新UI
});
});
在这里使用异步的方式定义了一个任务,并将其添加到一个全局队列中,这里面的任务内容可以进行一些耗时操作,由于是异步所以不影响主线程,当任务结束之后,同样使用异步的方式定义了一个任务,将其添加到了主队列中,这里执行的任务会在主线程完成。
同步和异步
前面内容提到了“异步”一词,那么这里聊一下什么是“异步”,相应的还有“同步”一词。
异步的作用是不需要CPU立刻响应,而是等待一个信号或回调来下一步操作,当前线程可以立刻执行后续内容,而同步为可以阻塞当前线程,当执行完一个任务之后才能执行下一个。
异步是目的,多线程是手段
当我们开启一个新的线程之后,可以将任务交由新的线程执行,实现异步效果,当需要的时候再返回之前的线程。
用图来做一个同步和异步的解释
这里thread1模拟主线程,当执行任务A的时候由于耗时比较短,所以可以在主线程上完成,当执行到任务B的时候,由于耗时长,所以开辟了一条新的线程,将任务交由子线程处理,同时继续完成任务C,当耗时操作完成之后,将结果返回给主线程进行操作,实现了异步功能。
使用多线程仍然要注意几个问题,1.数据竞争 2.死锁 3.线程开辟太多导致内存消耗过大,不过只要使用得当,多线程对我们开发的好处十分巨大。
串行队列和并发队列
首先解释一下“队列”,如其名字,它是执行处理的等待队列,这里的队列调度方式为先进先出模式(FIFO-First In First Out),也就是先添加到队列中的任务先执行,当然还有其他几种模式,不过这里暂时不考虑,有兴趣的请自行查资料
队列的种类也是两种,Serial Dispatch Queue和 Concurrent Dispatch Queue,分别为串行队列和并发队列,串行队列中的任务必须按照顺序依次执行,并发队列可以多个线程以并发的形式执行。
下面用代码来看串行队列和并发队列的区别,首先使用串行队列的方式创建几个异步操作
dispatch_queue_t queue = dispatch_queue_create("com.example.gcdDemo", DISPATCH_QUEUE_SERIAL);
dispatch_async(queue, ^{
NSLog(@"%@---0", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"%@---1", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"%@---2", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"%@---3", [NSThread currentThread]);
});
看看输出结果
{number = 3, name = (null)}---0
{number = 3, name = (null)}---1
{number = 3, name = (null)}---2
{number = 3, name = (null)}---3
很明显,这里是同一个线程,而且也确实是按照顺序执行的,那么接下来使用并发队列来操作。
dispatch_queue_t queue = dispatch_queue_create("com.example.gcdDemo", DISPATCH_QUEUE_CONCURRENT);
dispatch_async(queue, ^{
NSLog(@"%@---0", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"%@---1", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"%@---2", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"%@---3", [NSThread currentThread]);
});
再看看输出结果
{number = 5, name = (null)}---2
{number = 3, name = (null)}---0
{number = 4, name = (null)}---1
{number = 6, name = (null)}---3
很明显,并没有按照顺序执行,而且不是同一个线程,这就印证了上面所说的串行队列和并发队列的区别。
但是不代表创建了多少个并发任务就会开辟多少个线程,这个线程数量由XNU内核来决定,将上面的案例调整为8个任务,可以看到有些线程是重复的,表明了如果一开始就可以开辟8个线程,就不会出现这种情况,所以当一个任务结束之后,下一个任务可以放到完成的线程中,但是和串行队列还是有区别的
首先会开辟4条线程处理任务,将task0-task3异步形式放入线程中执行,假定task0首先完成,并发队列中取出task4放入线程3中执行,以此类推,所以也就造成了有些线程是重复的原因。
DISPATCH MAIN QUEUE/DISPATCH GLOBAL QUEUE
我们平时常用的大多是这两种,前者是在主线程执行的queue,由于主线程只有一个,自然是个串行队列,而global_queue是个并发队列,这个队列有4个优先级,分别是低优先级(DISPATCH_QUEUE_PRIORITY_LOW),默认优先级(DISPATCH_QUEUE_PRIORITY_DEFAULT),高优先级(DISPATCH_QUEUE_PRIORITY_HIGH),和后台优先级(
DISPATCH_QUEUE_PRIORITY_BACKGROUND),代码如下
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0);
GCD的api
前面已经提到一些关于GCD的api,下面会详细的探讨这些api的功能
dispatch_queue_create
dispatch_queue_t serialDispatchQueue = dispatch_queue_create("com.example.gcdDeo",NULL);
这里是创建一个queue的方法,返回类型为dispatch_queue_t,方法含有两个参数,一个是队列名,推荐使用应用程序ID逆序的域名方式,后面参数表示生成的队列类型,一种为DISPATCH_QUEUE_SERIAL为串行队列,这里也可以使用NULL,这个宏定义的值就是NULL,另一种是DISPATCH_QUEUE_CONCURRENT表示并发队列,这里虽然串行队列中的任务是按顺序执行的,但是如果创建多个串行队列,是会并行处理。
由于一个队列只操作一个线程,所以在执行一些比较重要的操作时,尽量使用串行队列,避免造成数据冲突。
dispatch_(a)sync
最常用的就是这两个函数了dispatch_sync同步执行,dispatch_async异步执行,第一个参数为指定的队列名,block为执行的任务内容,但是使用gcd也要注意一些问题
NSLog(@"1");
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2");
});
NSLog(@"3");
1
//接下来报错
看得出这个问题的原因,同步的方式在主线程执行一个任务,造成了线程阻塞。
dispatch_after
当我们需要在一段时间之后延迟执行某些任务的时候,可以使用dispatch_after这个函数,示例代码如下:
NSLog(@"延迟之前");
dispatch_time_t time = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC));
dispatch_after(time, dispatch_get_main_queue(), ^{
NSLog(@"延迟3秒执行");
});
这里的返回结果为
2018-09-04 14:52:59.437518+0800 GCDDemo[75192:21501573] 延迟之前
2018-09-04 14:53:02.438042+0800 GCDDemo[75192:21501573] 延迟3秒执行
可以看得出的确是延迟了3秒执行的任务,不过这里的实际意义为在3秒后将任务添加到主队列中执行,由于Main Dispatch Queue在主线程的Runloop中,所以真实的时间为3秒加上最短立刻最长Runloop一次循环的时间,并且如果Runloop中堆积的任务较多,可能时间会更长,所以时间并不是完全精确,不过想要大致完成延迟功能,dispatch_after是完全没有问题的。
time为dispatch_time_t类型,从第一个参数时间开始,到第二个指定后的时间结束,这里NSEC_PER_SEC是时间类型,以秒为单位,NSEC_PER_MSEC是以毫秒做单位,其他类型单位这里不多解释了。
dispatch_group
项目中我们经常会遇到将多个异步任务的结果同时返回,如果只是同步的话,执行完最后一个任务就是结束,但是异步却不行,所以这里我们需要使用dispatch_group,代码如下
NSLog(@"全部开始-----%@", [NSThread currentThread]);
dispatch_group_t group = dispatch_group_create();
dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
dispatch_group_async(group, queue, ^{
sleep(4);
NSLog(@"子线程1-----%@", [NSThread currentThread]);
});
dispatch_group_async(group, queue, ^{
sleep(3);
NSLog(@"子线程2-----%@", [NSThread currentThread]);
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
NSLog(@"全部结束-----%@", [NSThread currentThread]);
});
这里使用sleep模拟了两个耗时操作,并且打印了几个位置所处的线程,首先使用dispatch_group_create创建了一个组,并且使用了global queue,接下来模拟异步延时操作,使用dispatch_group_async这个函数和dispatch_async的功能是一样的,只不过前者归属于第一个参数这个组,当函数全部结束之后会调用dispatch_group_notify这个方法,表示所有异步操作都已经结束,代码执行结果如下
2018-09-04 16:22:03.449143+0800 GCDDemo[76086:21787405] 全部开始-----{number = 1, name = main}
2018-09-04 16:22:06.451174+0800 GCDDemo[76086:21787469] 子线程2-----{number = 3, name = (null)}
2018-09-04 16:22:07.452564+0800 GCDDemo[76086:21787470] 子线程1-----{number = 4, name = (null)}
2018-09-04 16:22:07.452926+0800 GCDDemo[76086:21787405] 全部结束-----{number = 1, name = main}
这里可以看出的确是当两个子线程都完成之后,才回到主线程的回调中,另外一种方式通过dispatch_group_wait方式阻止后续操作,直到异步函数全部完成
dispatch_group_wait(group, DISPATCH_TIME_FOREVER);
NSLog(@"全部结束-----%@", [NSThread currentThread]);
这里wait表示等待,第一个参数表示等待的对象,类型是dispatch_group_t,第二个参数表示等待时间,这里使用DISPATCH_TIME_FOREVER表示一直等待,所以这个函数变成了直到组中代码全部结束,等待才会停止,不过这里还是更加推荐使用dispatch_group_notify方式,因为dispatch_group_wait是同步的,所以不推荐在主线程中使用。
dispatch_group_enter/dispatch_group_leave
实际工作中,会出现让多个请求同时返回结果的案例,这时如果用上面的方法会造成一定问题,因为上面异步的任务只是一个NSLog,如果是一个延时请求呢,下面模拟一下多个请求同时发生的案例。
NSLog(@"全部开始-----%@", [NSThread currentThread]);
dispatch_group_t group = dispatch_group_create();
dispatch_queue_t queue = dispatch_queue_create("com.example.gcdDemo", DISPATCH_QUEUE_CONCURRENT);
dispatch_group_async(group, queue, ^{
dispatch_async(dispatch_get_global_queue(0, 0), ^{
sleep(4);
NSLog(@"模拟请求1-----%@", [NSThread currentThread]);
});
});
dispatch_group_async(group, queue, ^{
dispatch_async(dispatch_get_global_queue(0, 0), ^{
sleep(3);
NSLog(@"模拟请求2-----%@", [NSThread currentThread]);
});
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
NSLog(@"全部结束-----%@", [NSThread currentThread]);
});
这里在dispatch_group_async这些个异步任务中,再次用异步的方式模拟了一个请求任务,下面看一下结果
2018-09-04 16:50:50.221045+0800 GCDDemo[76421:21817204] 全部开始-----{number = 1, name = main}
2018-09-04 16:50:50.249321+0800 GCDDemo[76421:21817204] 全部结束-----{number = 1, name = main}
2018-09-04 16:50:53.225810+0800 GCDDemo[76421:21817394] 模拟请求2-----{number = 5, name = (null)}
2018-09-04 16:50:54.225917+0800 GCDDemo[76421:21817393] 模拟请求1-----{number = 3, name = (null)}
造成这样的原因是发起请求的两个任务已经完成了,所以调用了notify方法,但是请求的结果还没有成功,所以这样的代码是有问题的,那么这里就使用dispatch_group_enter和dispatch_group_leave这对方法来解决。
NSLog(@"全部开始-----%@", [NSThread currentThread]);
dispatch_group_t group = dispatch_group_create();
dispatch_queue_t queue = dispatch_queue_create("com.example.gcdDemo", DISPATCH_QUEUE_CONCURRENT);
dispatch_group_async(group, queue, ^{
dispatch_group_enter(group);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
sleep(4);
NSLog(@"模拟请求1-----%@", [NSThread currentThread]);
dispatch_group_leave(group);
});
});
dispatch_group_async(group, queue, ^{
dispatch_group_enter(group);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
sleep(3);
NSLog(@"模拟请求2-----%@", [NSThread currentThread]);
dispatch_group_leave(group);
});
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
NSLog(@"全部结束-----%@", [NSThread currentThread]);
});
这样的结果就没有问题了,这对方法可以理解为retain和release,当每次进入到一个新的异步任务中时,使用dispatch_group_enter告诉原本的异步任务这里还没有结束,当请求完成之后使用dispatch_group_leave表示已经结束了,可以退出这个异步操作了,这样的话,才能保证真正完成了一个延时函数,结果如下
2018-09-04 16:54:22.832901+0800 GCDDemo[76462:21821447] 全部开始-----{number = 1, name = main}
2018-09-04 16:54:25.837875+0800 GCDDemo[76462:21821502] 模拟请求2-----{number = 3, name = (null)}
2018-09-04 16:54:26.833634+0800 GCDDemo[76462:21821503] 模拟请求1-----{number = 4, name = (null)}
2018-09-04 16:54:26.833992+0800 GCDDemo[76462:21821447] 全部结束-----{number = 1, name = main}
当前案例还有其他的解决方案,我准备在下一篇文章中将案例的其他解决办法写出来,这里不加赘述了。
dispatch_barrier_(a)sync
再次通过一个案例来认识这个函数,假设有a,b,c,d四个异步任务,我新增加了一个任务new,我希望可以在a和b之后完成并且在c和d之前完成,这里可以通过同步等其他方式解决,不过有个更好的方式解决这个问题,dispatch_barrier_async,和它的名字一样,可以理解为一个栅栏,将前后分隔开,在下先上代码
dispatch_queue_t queue = dispatch_queue_create(NULL, DISPATCH_QUEUE_CONCURRENT);
dispatch_async(queue, ^{
sleep(3);
NSLog(@"task - A");
});
dispatch_async(queue, ^{
sleep(2);
NSLog(@"task - B");
});
NSLog(@"before barrier");
dispatch_barrier_sync(queue, ^{
NSLog(@"task - new");
});
NSLog(@"after barrier");
dispatch_async(queue, ^{
sleep(2);
NSLog(@"task - C");
});
dispatch_async(queue, ^{
sleep(1);
NSLog(@"task - D");
});
这里模拟了四个异步操作任务,将中间位置插入了一个new任务,这里看看返回结果
2018-09-04 17:55:08.783989+0800 GCDDemo[76920:21886183] before barrier
2018-09-04 17:55:10.787647+0800 GCDDemo[76920:21886310] task - B
2018-09-04 17:55:11.785806+0800 GCDDemo[76920:21886309] task - A
2018-09-04 17:55:11.786003+0800 GCDDemo[76920:21886183] task - new
2018-09-04 17:55:11.786164+0800 GCDDemo[76920:21886183] after barrier
2018-09-04 17:55:12.790452+0800 GCDDemo[76920:21886312] task - D
2018-09-04 17:55:13.790432+0800 GCDDemo[76920:21886309] task - C
这里可以看出,由于有模拟延时操作,所以before首先输出,然后执行了A和B两个任务,而barrier中的任务并没有延时却在A和B之后,说明栅栏功能生效,有因为是sync同步的关系,所以后面的after紧接着输出,这里把sync换成async会有什么结果呢
2018-09-04 17:59:29.114406+0800 BlockDemo[76948:21890748] before barrier
2018-09-04 17:59:29.114600+0800 BlockDemo[76948:21890748] after barrier
before和after是紧挨着输出的,说明dispatch_barrier_sync同样有同步的作用,而dispatch_barrier_async也有着异步的效果。
dispatch_apply
如果有一个案例需要按指定次数执行gcd的任务,可以用这个函数,第一个参数为次数,第二个参数为指定的队列,第三个参数是带参数的block,参数为当前次数下标
NSArray * array = @[@"1",@"2",@"3",@"4",@"5",];
dispatch_apply([array count], dispatch_get_global_queue(0, 0), ^(size_t index) {
NSLog(@"元素:%@----第%ld次", array[index],index);
});
2018-09-04 18:44:56.970194+0800 GCDDemo[77406:21942336] 元素:4----第3次
2018-09-04 18:44:56.970194+0800 GCDDemo[77406:21942205] 元素:1----第0次
2018-09-04 18:44:56.970194+0800 GCDDemo[77406:21942337] 元素:3----第2次
2018-09-04 18:44:56.970194+0800 GCDDemo[77406:21942335] 元素:2----第1次
2018-09-04 18:44:56.970380+0800 GCDDemo[77406:21942205] 元素:5----第4次
dispatch_semaphore
前文已经有讲部分关于产生不一样数据的处理问题,不过有时需要更细致的排他控制,例如你到了一个屋子,里面有一个椅子,你可以坐下,如果再拿来一个椅子,依然可以坐下,但是如果把椅子拿走,那么只能站着等待了,semaphore使用信号量的方式实现了类似的情况,首先第一个函数:
dispatch_semaphore_create(0);
这里创建了一个semaphore,返回类型是dispatch_semaphore_t,有一个参数,表示初始信号量的值,这里给0,如果遇到wait则需要等待。
dispatch_semaphore_wait(semaphore,DISPATCH_TIME_FOREVER);
dispatch_semaphore_signal(semaphore);
当第一个函数中的信号量0时,这个函数需要进行等待,如果大于0,则将信号量-1,第二个参数为等待的时间,这个可以根据需求使用,这里假定需要等待无限长的时间,知道信号量增加未知
第二个函数中会给信号量+1,可以看出这两个函数是要成对出现的,如果单独出现wait而且初始化为0的话,会造成后续任务全部卡住无法执行。下面给一个小的案例
dispatch_group_t group = dispatch_group_create();
dispatch_queue_t queue = dispatch_queue_create(NULL, DISPATCH_QUEUE_CONCURRENT);
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
dispatch_group_async(group, queue, ^{
dispatch_async(dispatch_get_global_queue(0, 0), ^{
sleep(3);
NSLog(@"完成1");
dispatch_semaphore_signal(semaphore);
});
});
dispatch_group_async(group, queue, ^{
dispatch_async(dispatch_get_global_queue(0, 0), ^{
sleep(2);
NSLog(@"完成2");
dispatch_semaphore_signal(semaphore);
});
});
dispatch_group_notify(group, queue, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
NSLog(@"全部完成");
});
这里再次模拟了多个请求需要同时返回结果的问题,通过信号量的方式,使用信号量的方式同样可以完成这个需求,当notify中有两个等待信号的时候,只能通过请求成功的信号量增加的方法去抵消,当两个请求全部完成的时候,等待信号也全部结束,这时表示任务全部完成。
不过如果更换一下需求会怎么样呢,如果我们需要让多个请求同步执行要怎么做,首先我们需要开启异步去管理,同样请求也是异步方法,所以我们用这种方式不能让请求同步执行,这里需要使用线程依赖的方式操作,GCD线程依赖这里面也使用semaphore的方式去做,修改代码如下
dispatch_group_t group = dispatch_group_create();
dispatch_queue_t queue = dispatch_queue_create(NULL, DISPATCH_QUEUE_CONCURRENT);
dispatch_semaphore_t semaphore0 = dispatch_semaphore_create(0);
dispatch_semaphore_t semaphore1 = dispatch_semaphore_create(0);
dispatch_group_async(group, queue, ^{
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[NSThread sleepForTimeInterval:3];
NSLog(@"完成1");
dispatch_semaphore_signal(semaphore0);
});
});
dispatch_group_async(group, queue, ^{
dispatch_semaphore_wait(semaphore0,DISPATCH_TIME_FOREVER);
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[NSThread sleepForTimeInterval:2];
NSLog(@"完成2");
dispatch_semaphore_signal(semaphore1);
});
});
dispatch_group_notify(group, queue, ^{
dispatch_semaphore_wait(semaphore1, DISPATCH_TIME_FOREVER);
NSLog(@"全部完成");
});
这里创建了两个信号量,因为任务1模拟了时间更久,我们这里需要让任务1先完成,那么我们在任务2中把任务1的信号量等待,直到任务1完成并增加信号量,再执行任务2,结果如下
2018-09-05 10:27:02.725024+0800 GCDDemo[81615:22654482] 完成1
2018-09-05 10:27:04.727478+0800 GCDDemo[81615:22654482] 完成2
2018-09-05 10:27:04.727852+0800 GCDDemo[81615:22654485] 全部完成
可以看出我们的目的已经实现了,但是如果有多个请求任务呢,必然需要创建多个信号量,按照需要的顺序进行依赖,但是这种方法其实写起来容易乱,最好的方式是使用NSOperationQueue添加线程依赖,但是这里不多加赘述,同样后续文章中会详细分析一次此案例,并使用其他方式解决这个问题。
dispatch_once
这个函数应该也不会陌生,当我们希望只会执行一次的函数我们会使用dispatch_once,所有我们创建单例的时候也会使用到这个函数。
+ (instancetype)shareInstance {
static Manager * manager = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
manager = [Manager new];
});
return manager;
}
这种单例不需要担心线程问题,即使是多线程环境下也一定是安全的,onceToken会保证运行过程中这部分只会执行一次。
GCD的实现
GCD的使用是十分方便的,这里探讨一下它是如何实现的
C语言实现的用于管理追加Block的FIFO队列
用于排他控制的atomic类型的轻量级信号
C语言实现的管理线程的容器
首先确定一下用于实现dispatch queue的软件组件
我们所使用的全部api都处于libdispatch库中,Dispatch Queue通过结构体和链表实现FIFO队列。FIFO通过dispatch_async等函数管理添加的block。
但是block并不是直接加入到FIFO队列中,而是先加入Dispatch Continuation这个dispatch_continuation_t类型的结构体中,再加入到队列中,这个结构体包含了block所属的group等信息,也就是执行上下文。
XNU内核有4中workqueue,优先级和Global Dispatch Queue的优先级相同,当在Global Dispatch Queue中执行block时,libdispatch从FIFO队列中取出Dispatch Continuation,调用pthread_workqueue_additem_np函数,将自身信息,符合其优先级的workqueue信息以及执行回调函数等传递给参数。
pthread_work_queue_additem_np函数使用workq_kernreturn系统调用。通知workqueue应当执行的项目。根据通知,XNU内核基于系统判断是否生成线程,如果是overcommit属性则始终生成线程。
workqueue的线程执行pthread_workqueue函数,该函数调用libdispatch的回调函数,在回调函数中执行加入到Dispatch Continuation的Block。
Block执行结束后,进行通知Dispatch Group结束、释放Dispatch Continuation等处理。开始准备执行Global Dispatch Queue的下一个Block
以上就是Dispatch Queue的大致执行过程。
Dispatch Source
GCD中除了常用的Dispatch Queue外,还有Dispatch Source,它具有很多种类型处理能力,最常见的就是使用定时器。
dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
//创建一个dispatch_source_t类型变量,类型指定为定时器
dispatch_source_set_timer(timer,DISPATCH_TIME_NOW,1.0*NSEC_PER_SEC, 0);
//指定定时器执行时间为每秒执行一次
dispatch_source_set_event_handler(timer, ^{
NSLog(@"定时内容");
//每秒执行的内容
});
dispatch_source_set_cancel_handler(timer, ^{
NSLog(@"定时取消");
//取消定时器的回调
});
dispatch_resume(timer);
//启动定时器
//dispatch_source_cancel(timer);
//取消定时器
这里本身会存在一个问题,就是set_event_handle这个回调会不执行,原因是当执行过作用域之后,这个source可能会被释放掉,所以可以使用添加到属性的方式放大source的作用域,保证定时器可以始终执行
@property (nonatomic, strong) dispatch_source_t timer;
这里如果内存管理语义使用了assign创建定时器,则会报出会被释放的错误。
使用Dispatch Queue本身是不具备“取消”功能的,要么放弃取消,要么使用NSOperationQueue等方法,而Dispatch Source具备该功能,而且取消后执行的处理可以使用block形式,这里也能看出Dispatch Source的强大功能。
到此为止关于GCD的这篇文章就结束了,如果文章中出现问题欢迎指出,并且如果有更优秀的看法也欢迎提出或讨论。
本文部分内容参考自《Objective-C高级编程》一书,有兴趣的小伙伴可以翻看一下