iOS当多个网络请求完成后执行下一步的方法详解

我们对比 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-------------3----------3-------
2017-12-05 10:29:51.178 DownImage[938:56971] 2---2
2017-12-05 10:29:51.193 DownImage[938:57200] 0---0
2017-12-05 10:29:51.202 DownImage[938:56631] 3---3
2017-12-05 10:29:51.248 DownImage[938:56971] 1---1
2017-12-05 10:29:51.262 DownImage[938:56971] 5---5
2017-12-05 10:29:51.291 DownImage[938:56631] 6---6
2017-12-05 10:29:51.375 DownImage[938:56631] 7---7
2017-12-05 10:29:51.384 DownImage[938:56631] 4---4
2017-12-05 10:29:51.434 DownImage[938:56971] 8---8
2017-12-05 10:29:51.487 DownImage[938:57199] 9---9
2017-12-05 10:29:51.488 DownImage[938:45252] end

5-------------5----------5-------
2017-12-05 10:29:52.190 DownImage[938:56631] 0---0
2017-12-05 10:29:52.304 DownImage[938:57199] 1---1
2017-12-05 10:29:52.432 DownImage[938:56971] 2---2
2017-12-05 10:29:52.520 DownImage[938:56971] 3---3
2017-12-05 10:29:52.576 DownImage[938:56631] 4---4
2017-12-05 10:29:52.628 DownImage[938:56971] 5---5
2017-12-05 10:29:52.706 DownImage[938:56631] 6---6
2017-12-05 10:29:52.764 DownImage[938:56971] 7---7
2017-12-05 10:29:52.853 DownImage[938:56631] 8---8
2017-12-05 10:29:52.925 DownImage[938:56971] 9---9
2017-12-05 10:29:52.926 DownImage[938:45252] end								 
 6/7   首页 上一页 4 5 6 7 下一页 尾页