前言
在实际开发中我们通常会遇到这样一种需求:某个页面加载时通过网络请求获得相应的数据,再做某些操作。有时候加载的内容需要通过好几个请求的数据组合而成,比如有两个请求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___上传打好水印的图片
通过重复运行打印结果可证实确实实现了我们想要的效果。这样即解决了所提出的问题二。
后续
如果看的不是特别明白,可以看看这篇文章,写的很棒
点我进入
网友评论
但是最后多个请求依次执行,用信号量总感觉有点鸡肋
但是有个问题,我写了一个计时器 执行了50次NSBlockOperation 这个线程依赖 这50次的结果都相同 是不是巧合??? 并没有出现 B-A-C 这种现象。或则是错乱的现象。
1、dispath_notify
1.1、dispath_notfiy 结合 dispath_enter/leave (增强)
2、NSBlockOperation 设置dependency
2.1、NSBlockOperation 设置dependency 结合dispatch_semaphore
# 非常厉害,直接看明白了。原来以为多余呢