本文详细介绍了GCD在iOS中的使用,主要包括以下几个方面
- GCD 简介
- GCD优点
- GCD基础概念
- GCD 的使用步骤
- GCD 组合方式
- GCD 常用方法总结
GCD 简介
Grand Central Dispatch(GCD) 是 Apple 开发的一个多核编程的较新的解决方法。它主要用于优化应用程序以支持多核处理器以及其他对称多处理系统。它是一个在线程池模式的基础上执行的并发任务。在 Mac OS X 10.6 雪豹中首次推出,也可在 iOS 4 及以上版本使用。
GCD优点
- GCD 可用于多核的并行运算
- GCD 会自动利用更多的 CPU 内核(比如双核、四核)
- GCD 会自动管理线程的生命周期(创建线程、调度任务、销毁线程)
- 程序员只需要告诉 GCD 想要执行什么任务,不需要编写任何线程管理代码
GCD基础概念
为了不重复编写我专门写了一篇介绍基础概念文章详细介绍了多线程编程中的一些概念,如同步/异步、串行/并行、队列/线程/任务、进程/线程等,请了解相关概念后继续阅读。
GCD 的使用步骤
GCD 的使用步骤其实很简单,只有两步。
- 创建一个队列(串行队列或并发队列)
- 将任务追加到任务的等待队列中,然后系统就会根据任务类型执行任务(同步执行或异步执行)
队列的创建方法
1 | // 串行队列的创建方法 |
任务的创建方法
1 | // 同步执行任务创建方法 |
GCD 组合方式
- 异步 + 串行
- 异步 + 并发
- 同步 + 串行(很少使用、可能死锁)
- 同步 + 并发(很少使用)
结论:同步执行没有开启新线程的能力, 所有的任务都只能在当前线程执行
异步执行有开启新线程的能力, 但是, 有开启新线程的能力, 也不一定会利用这种能力, 也就是说, 异步执行是否开启新线程, 需要具体问题具体分析
具体组合的实践代码我在另外一篇文章有详细介绍,本篇将这部分跳过。
GCD其他函数用法
dispatch_after
该函数用于任务延时执行,具体使用方法如下
1 | -(void)GCDDelay{ |
dispatch_once
保证函数在整个生命周期内只会执行一次,使用方法如下:
1 | + (id)sharedInstance { |
dispatch_group
dispatch_group_create
用于创建任务组
1 | dispatch_group_t dispatch_group_create(void); |
dispatch_group_async
把异步任务提交到指定任务组和指定下拿出队列执行
1 | void dispatch_group_async(dispatch_group_t group, |
- group ——对应的任务组,之后可以通过
dispatch_group_wait
或者dispatch_group_notify
监听任务组内任务的执行情况 - queue ——block任务执行的线程队列,任务组内不同任务的队列可以不同
- block —— 执行任务的block
dispatch_group_enter
用于添加对应任务组中的未执行完毕的任务数,执行一次,未执行完毕的任务数加1,当未执行完毕任务数为0的时候,才会使dispatch_group_wait
解除阻塞和dispatch_group_notify
的block执行
1 | void dispatch_group_enter(dispatch_group_t group); |
dispatch_group_leave
用于减少任务组中的未执行完毕的任务数,执行一次,未执行完毕的任务数减1,dispatch_group_enter
和dispatch_group_leave
要匹配,不然系统会认为group任务没有执行完毕
1 | void dispatch_group_leave(dispatch_group_t group); |
dispatch_group_wait
等待组任务完成,会阻塞当前线程,当任务组执行完毕时,才会解除阻塞当前线程
1 | long dispatch_group_wait(dispatch_group_t group, |
- group ——需要等待的任务组
- timeout ——等待的超时时间(即等多久),单位为dispatch_time_t。如果设置为
DISPATCH_TIME_FOREVER
,则会一直等待(阻塞当前线程),直到任务组执行完毕
dispatch_group_notify
待任务组执行完毕时调用,不会阻塞当前线程
1 | void dispatch_group_notify(dispatch_group_t group, |
- group ——需要监听的任务组
- queue ——block任务执行的线程队列,和之前group执行的线程队列无关
- block ——任务组执行完毕时需要执行的任务block
以下代码简单演示group的使用方法,并测试group中嵌套异步代码存在的问题
1 | dispatch_group_t group = dispatch_group_create(); |
控制台输出
1 | 2016-09-25 09:28:28.716 group one start |
从打印结果可以看出,在group中嵌套了一个异步任务时,group并没有等待group内的异步任务执行完毕才进入dispatch_group_notify中,这是因为,在dispatch_group_async中又启了一个异步线程,而异步线程是直接返回的,所以group就认为是执行完毕了。
对于以上这种情形,解决方案是使用dispatch_group_enter
和dispatch_group_leave
方法来告知group组内任务何时才是真正的结束。代码如下
1 | dispatch_group_t group = dispatch_group_create(); |
控制台输出
1 | 2016-09-25 09:34:07.672 group one start |
以上代码,通过dispatch_group_enter
告知group,一个任务开始,未执行完毕任务数加1,在异步线程任务执行完毕时,通过dispatch_group_leave
告知group,一个任务结束,未执行完毕任务数减1,当未执行完毕任务数为0的时候,这时group才认为组内任务都执行完毕了(这个和GCD的信号量的机制有些相似),这时候才会回调dispatch_group_notify
中的block。
dispatch_barrier_async
栅栏函数,使用此方法创建的任务,会查找当前队列中有没有其他任务要执行,如果有,则等待已有任务执行完毕后再执行,同时,在此任务之后进入队列的任务,需要等待此任务执行完成后,才能执行
1 | -(void)GCDbarrier{ |
打印结果:
1 | ThreadDemo[1833:678739] 任务2 |
dispatch_apply
该函数用于重复执行某个任务,如果任务队列是并行队列,重复执行的任务会并发执行,如果任务队列为串行队列,则任务会顺序执行
1 | //串行队列 |
dispatch_semaphore
信号量主要有3个函数,分别是:
1 | //创建信号量,参数:信号量的初值,如果小于0则会返回NULL |
正常的使用顺序是先降低然后再提高,这两个函数通常成对使用。
1 | -(void)dispatchSignal{ |
执行结果:
总结:由于设定的信号值为2,先执行两个线程,等执行完一个,才会继续执行下一个,保证同一时间执行的线程数不超过2。
dispatch_Source
Dispatch Source是GCD中的一种基本数据类型,从字面意思可称其为调度源,它用于处理特定的系统底层事件,即:当一些特定的系统底层事件发生时,调度源会捕捉到这些事件,然后可以做相应的逻辑处理。
Dispatch Source可用来监听以下几类事件:
- Timer Dispatch Source:定时调度源。
- Signal Dispatch Source:监听UNIX信号调度源,比如监听代表挂起指令的SIGSTOP信号。
- Descriptor Dispatch Source:监听文件相关操作和Socket相关操作的调度源。
- Process Dispatch Source:监听进程相关状态的调度源。
- Mach port Dispatch Source:监听Mach相关事件的调度源。
- Custom Dispatch Source:监听自定义事件的调度源。
使用Dispatch Source时,通常是先指定一个希望监听的系统事件类型,再指定一个捕获到事件后进行逻辑处理的闭包或者函数作为回调函数,然后再指定一个该回调函数执行的Dispatch Queue即可。当监听到指定的系统事件发生时,Dispatch Source会将已指定的回调函数作为一个任务放入指定的队列中执行,也就是说当监听到系统事件后就会触发一个任务,并自动将其加入队列执行。
这里与通常的手动添加任务的模式不同,一旦将Diaptach Source与Dispatch Queue关联后,只要监听到系统事件,Dispatch Source就会自动将任务(回调函数)添加到关联的队列中,直到我们调用函数取消监听。
为了保证监听到事件后回调函数能够都到执行,已关联的Dispatch Queue会被Diaptach Source强引用。有些时候回调函数执行的时间较长,在这段时间内Dispatch Source又监听到多个系统事件,理论上就会形成事件积压,但好在Dispatch Source有很好的机制解决这个问题,当有多个事件积压时会根据事件类型,将它们进行关联和结合,形成一个新的事件。
Dispatch Source涉及的方法开发中使用的场景比较稀少,本文只讲解如何用它来构造一个定时器。
定时器
使用定时器时需要调用 dispatch_source_set_timer函数来配置定时器,这个函数有四个参数:
- source:待配置的定时器类型的 Dispatch Source
- start:控制定时器第一次触发的时刻。参数类型是 dispatch_time_t,这是一个opaque类型,我们不能直接操作它。我们得需要 dispatch_time 和 dispatch_walltime 函数来创建它们。另外,常量 DISPATCH_TIME_NOW 和 DISPATCH_TIME_FOREVER 通常很有用。
- interval:触发间隔
- leeway:定时器进度,单位纳秒;如果设为0,系统只是最大程度满足精度需求。精度越高功耗越大。
1 | - (void)timerDispatchSource |
NSTimer 与 GCD Timer比较
NSTimer
- 依赖NSRunloop
- 容易导致内存泄漏
- NSTimer的创建与撤销必须在同一个线程操作、 performSelector的创建与撤销必须在同一个线程操作
GCD Timer
- 可以被当做对象放入数组或字典中
- GCD Timer必须强引用,否则出了栈就会失效,这种失效不会触发取消处理器
- GCD Timer精度可控
- 如果使用dispatch_walltime来设置定时器的起始时间,定时器默认使用walltime来触发定时器;如果使用dispatch_time来设置定时器的起始时间,定时器默认使用系统时钟来触发定时器,然而当计算机休眠时,系统时钟也是休眠的。对于时间间隔比较大的定时器,使用dispatch_walltime来设置定时器的起始时间
###