前言
在实际开发中我们通常会遇到这样一种需求：某个页面加载时通过网络请求获得相应的数据，再做某些操作。有时候加载的内容需要通过好几个请求的数据组合而成，比如有两个请求A和B，我们通常为了省事，会将B请求放在A请求成功的回调中发起，在B的成功回调中将数据组合起来，这样做有明显的问题：
- 请求如果多了，需要写许多嵌套的请求
- 如果在除了最后一个请求前的某个请求失败了，就不会执行后面的请求，数据无法加载
- 请求变成同步的，这是最大的问题，在网络差的情况下，如果有n个请求，意味着用户要等待n倍于并发请求的时间才能看到内容
一、某界面存在多个请求，希望所有请求均结束才进行某操作。
同步请求这么low的方式当然是不可接受的，所以我们要并发这些请求，在所有请求都执行完成功回调后，再做加载内容或其他操作，考虑再三，选择用GCD的dispatch_group。
dispatch_group通常有两种用法，一种是
- dispatch_group_async(<#dispatch_group_t group#>, <#dispatch_queue_t queue#>, <#^(void)block#>)
创建一个dispatch_group_t， 将并发的操作放在block中，在
dispatch_group_notify(<#dispatch_group_t group#>, <#dispatch_queue_t queue#>, <#^(void)block#>)
的block中执行多组block执行完毕后的操作，对于网络请求来说，在请求发出时他就算执行完毕了，并不会等待回调，所以不满足我们的需求。
dispatch_group_t group = dispatch_group_create();
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//请求1
NSLog(@"Request_1");
});
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//请求2
NSLog(@"Request_2");
});
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//请求3
NSLog(@"Request_3");
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
//界面刷新
NSLog(@"任务均完成，刷新界面");
});
打印如下
Request_2
Request_1
Request_3
任务均完成，刷新界面
网络请求我们一般都用异步的，并不知道什么时候是否完成了。
- 所以采用另一种用法：
使用dispatch_group_enter(group)和dispatch_group_leave(group)，这种方式使用更为灵活，enter和leave必须配合使用，有几次enter就要有几次leave，否则group会一直存在。当所有enter的block都leave后，会执行dispatch_group_notify的block。
我们当然可以在网络请求前enter，在执行完每个请求的成功回调后leave，再在notify中执行内容加载，这样看来问题就解决了，就像这样：
dispatch_group_t group = dispatch_group_create();
dispatch_group_enter(group);
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//请求1
[网络请求:{
成功：dispatch_group_leave(group);
失败：dispatch_group_leave(group);
}];
});
dispatch_group_enter;
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//请求2
[网络请求:{
成功：dispatch_group_leave;
失败：dispatch_group_leave;
}];
});
dispatch_group_enter(group);
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//请求3
[网络请求:{
成功：dispatch_group_leave(group);
失败：dispatch_group_leave(group);
}];
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
//界面刷新
NSLog(@"任务均完成，刷新界面");
});
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
打印如下
Request_2
Request_1
Request_3
任务均完成，刷新界面
二、某界面存在多个请求，希望请求依次执行。
对于这个问题通常会通过线程依赖进行解决，因使用GCD设置线程依赖比较繁琐，这里通过NSOperationQueue进行实现，这里采用比较经典的例子，三个任务分别为下载图片，打水印和上传图片，三个任务需异步执行但需要顺序性。代码如下，下载图片、打水印、上传图片仍模拟为分别请求新闻列表3页数据。
//1.任务一：下载图片
NSBlockOperation *operation1 = [NSBlockOperation blockOperationWithBlock:^{
[self request_A];
}];
//2.任务二：打水印
NSBlockOperation *operation2 = [NSBlockOperation blockOperationWithBlock:^{
[self request_B];
}];
//3.任务三：上传图片
NSBlockOperation *operation3 = [NSBlockOperation blockOperationWithBlock:^{
[self request_C];
}];
//4.设置依赖
[operation2 addDependency:operation1]; //任务二依赖任务一
[operation3 addDependency:operation2]; //任务三依赖任务二
//5.创建队列并加入任务
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
[queue addOperations:@[operation3, operation2, operation1] waitUntilFinished:NO];
首先我们使用未添加信号量dispatch_semaphore时运行，打印如下
B___图片打水印
B___图片打水印
B___图片打水印
B___图片打水印
B___图片打水印
A___下载图片
A___下载图片
A___下载图片
A___下载图片
A___下载图片
C___上传打好水印的图片
C___上传打好水印的图片
C___上传打好水印的图片
C___上传打好水印的图片
C___上传打好水印的图片
根据打印结果可见，若不对请求方法做处理，其运行结果并不是我们想要的，联系实际需求，A、B、C请求分别对应下载图片、打水印、上传图片，而此时运行顺序则为B->A->C，在未获得图片时即执行打水印操作明显是错误的。重复运行亦会出现不同结果，即请求不做处理，其结果不可控无法预测。线程依赖设置并未起到作用。
解解决此问题的方法仍可通过信号量dispatch_semaphore进行解决。我们将请求方法替换为添加dispatch_semaphore限制的形式。
因此对于这种问题需要另辟蹊径，这里我们就要借助GCD中的信号量dispatch_semaphore进行实现，即营造线程同步情况。
dispatch_semaphore信号量为基于计数器的一种多线程同步机制。用于解决在多个线程访问共有资源时候，会因为多线程的特性而引发数据出错的问题。
如果semaphore计数大于等于1，计数-1，返回，程序继续运行。如果计数为0，则等待。
dispatch_semaphore_signal(semaphore)为计数+1操作。dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER)为设置等待时间，这里设置的等待时间是一直等待。我们可以通俗的理解为单柜台排队点餐，计数默认为0，每当有顾客点餐，计数+1，点餐结束-1归零继续等待下一位顾客。比较类似于NSLock。
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[网络请求:{
成功：dispatch_semaphore_signal(sema);
失败：dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
再次重复运行，我们会发现每次运行结果均一致，A、B、C三任务异步顺序执行（A->B->C）
A___下载图片
A___下载图片
A___下载图片
A___下载图片
A___下载图片
B___图片打水印
B___图片打水印
B___图片打水印
B___图片打水印
B___图片打水印
C___上传打好水印的图片
C___上传打好水印的图片
C___上传打好水印的图片
C___上传打好水印的图片
C___上传打好水印的图片
通过重复运行打印结果可证实确实实现了我们想要的效果。这样即解决了所提出的问题二。
后续
如果看的不是特别明白，可以看看这篇文章，写的很棒
点我进入
