在开发中,我们很容易遇到这样的需求,需要我们同时做多个网络请求,所有网络请求都完成后才能进行下一步的操作。如下载多个图片,下载完了才能展示。今天我们就来研究一下这个问题的解决方案。
1.首先,我们创建一个项目,然后做一般性的做法,不做任何处理去连续请求一个接口10次:
|
|
|
|
|
|
很明显,无任何处理情况下,end最先被打印出来,由于网络请求的异步回调,然后各个网络请求的回调顺序是无序的。
2.使用GCD的dispatch_group_t
|
|
|
|
从上两次输出可以看出,end确实是在所有网络请求之后才输出出来,这也是符合了我们的需求。
|
|
对以上4行代码可理解为:创建一个dispatch_group_t, 每次网络请求前先dispatch_group_enter,请求回调后再dispatch_group_leave,对于enter和leave必须配合使用,有几次enter就要有几次leave,否则group会一直存在。当所有enter的block都leave后,会执行dispatch_group_notify的block。
3.使用GCD的信号量dispatch_semaphore_t
|
|
|
|
4.考虑新需求,10个网络请求顺序回调。
需求需要顺序回调,即执行完第一个网络请求后,第二个网络请求回调才可被执行,简单来讲就是输出得是0,1,2,3…9这种方式的。
对于这个需求我也是根据自己最近做的项目来提的,因为网络请求回调的异步性,我们虽可以控制网络请求的顺序执行,却不能控制它的完成回调顺序。这就有点伤了,目前我项目是找到了解决方案,但这个问题还没有找到解决办法,提出来跟大家讨论一下。(请忽略网络请求执行,回调,在回调里请求下一个接口的办法,讨论还有没有别的方法,最好show the code).
最后,贴点NSOperation的代码,为了解决新需求所写,由于网络请求回调异步性不能满足需求,但若不是网络请求等异步回调的方式,这样的做法是可以的,大家可以试试.
|
|
5.还是使用信号量semaphore完成4的需求
|
|
我们对比 3 的代码,3 中我们只在最后也就是循环结束后调用dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER),循环中当网络请求回调10次(也就是都回调完)后,使传入的信号量加1:( dispatch_semaphore_signal(sem) ),这时等待结束,然后进行后续的操作。
在这个方法里,我们每一次遍历,都让其dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER),这个时候线程会等待,阻塞当前线程,直到dispatch_semaphore_signal(sem)调用之后,而我们dispatch_semaphore_signal(sem)是在网络请求的回调里调用的,所以这个方法的逻辑是:
遍历—发起任务—等待—任务完成信号量加1—等待结束,开始下一个任务
发起任务—等待—任务完成信号量加1—等待结束,开始下一个任务
发起任务—等待—任务完成信号量加1—等待结束,开始下一个任务
这样循环的模式,一个任务完成才能接着去做下面的任务,满足我们的需求。
但我们也要发现这样一个问题,我们使用这种方式,可以明显感觉出整个过程需要花费的时间大大增加了,不像我们 3 中同时(几乎)开启任务等待完成回调,这里是一个网络请求发出,等待,完成后发出第二个网络请求,等待,完成后再发出第三个,这样我们等待的时间是10个网络请求每一个回调时间的和,在时间上大大增加了消耗,而且对于dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER),它是会阻塞线程的,我们如果需要在网络请求完成后修改UI,那这种方式会影响我们的界面交互,接下来我们对比一下两者时间消耗:
|
|
看得出3花费时间为51.488 - 51.178约300多ms
— —5花费时间为52.926 - 52.190约700多ms
所以大家还请谨慎使用。