上一篇分析了同时回调多个请求的问题,那么还有一种情况在平时也比较常见——同步多个请求,比如在用户调用登录接口后再调用获取用户的详细信息接口,这里用接口A和接口B分别表示这两个接口,我们可以将B接口的调用放入A接口的回调当中,也能实现这类要求,但是如果同步请求过多,这么处理代码结构会显得很杂乱且不利于排查问题,所以这里可以利用“信号量”的方式处理这个问题。基础问题请参考《GCD的使用和原理》一文。
首先将代码贴出来并简单分析下思路
[self request_A];
[self request_B];
- (void)request_A {
NSLog(@"进入A");
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[[URLBase sharedInstance] getBusinessDataWithSuccess:^(NSDictionary *result) {
NSLog(@"请求A结束");
dispatch_semaphore_signal(sema);
} failure:^(NSError *error) {
NSLog(@"请求A结束");
dispatch_semaphore_signal(sema);
}];
NSLog(@"A等待");
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
NSLog(@"A完成");
}
- (void)request_B {
NSLog(@"进入B");
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[[URLBase sharedInstance] getHomeConfigurationWithSuccess:^(NSDictionary *result) {
NSLog(@"请求B结束");
dispatch_semaphore_signal(sema);
} failure:^(NSError *error) {
NSLog(@"请求B结束");
dispatch_semaphore_signal(sema);
}];
NSLog(@"B等待");
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
NSLog(@"B完成");
}
到这里很清晰,一共两个request,当A执行到dispatch_semaphore_wait
这里的时候,会被阻塞,当请求成功后,执行dispatch_semaphore_signal
后,会将信号量+1打破阻塞继续执行请求B。
但是这里存在一个小问题,运行这段代码看下结果。
Gemii[28155:9084536] < - -[GMHomeViewController request_A] - > 进入A
Gemii[28155:9084536] < - -[GMHomeViewController request_A] - > A等待
Gemii[28155:9084640] [BoringSSL] Function boringssl_session_errorlog: line 2881 [boringssl_session_read] SSL_ERROR_ZERO_RETURN(6): operation failed because the connection was cleanly shut down with a close_notify alert
Gemii[28155:9084640] [BoringSSL] Function boringssl_session_errorlog: line 2881 [boringssl_session_read] SSL_ERROR_ZERO_RETURN(6): operation failed because the connection was cleanly shut down with a close_notify alert
这里显然已经报错了,先分析下原因,之前我们的dispatch_semaphore_wait
阻塞方法写在dispatch_group_notify
方法中,并且确定了这个方法并不是主线程,而我们现在是要在主线程中阻塞,保证可以阻塞到后续请求,分析到这里已经好办了,最简单的方式就是将AFNetworking的回调结果放到其他线程中。
manager.completionQueue = dispatch_get_global_queue(0, 0);//需要指定成功回调队列类型
将AFNetworking的成功回调改为全局队列,可以看到B请求已经在A请求成功后执行了。
Gemii[28148:9081564] < - -[GMHomeViewController request_A] - > 进入A
Gemii[28148:9081564] < - -[GMHomeViewController request_A] - > A等待
Gemii[28148:9081443] < - -[GMHomeViewController request_A]_block_invoke - > 请求A结束
Gemii[28148:9081564] < - -[GMHomeViewController request_A] - > A完成
Gemii[28148:9081564] < - -[GMHomeViewController request_B] - > 进入B
Gemii[28148:9081564] < - -[GMHomeViewController request_B] - > B等待
Gemii[28148:9081564] < - -[GMHomeViewController request_B] - > B完成
Gemii[28148:9081443] < - -[GMHomeViewController request_B]_block_invoke - > 请求B结束
但是我们大多数希望请求结果之后可以立刻更新数据并刷新UI,不单独调用一次返回主线程,所以这里我们也可以利用其它方法处理这个问题。
NSBlockOperation * operation1 = [NSBlockOperation blockOperationWithBlock:^{
[self request_A];
}];
NSBlockOperation * operation2 = [NSBlockOperation blockOperationWithBlock:^{
[self request_B];
}];
[operation2 addDependency:operation1];
NSOperationQueue * queue = [[NSOperationQueue alloc] init];
[queue addOperations:@[operation1, operation2] waitUntilFinished:NO];
我们使用NSOperationQueue中的线程依赖来实现我们要的需求,首先NSBlockOperation可以添加我们想要的线程依赖[task_B addDependency:task_A];
这里表示任务B依赖于任务A执行,只是这样还是有问题,NSBlockOperation开启的block并没有开启额外线程,所以当前执行的内容依然在主线程中,所以开启NSOperationQueue添加所有的任务,这里会开启并发队列,保证主线程不会被阻塞,这样一来也可以完成我们想要的需求。利用信号量还有其他方法可以实现我们的要求,这里也不多加赘述了。
到这里已经解决了我们的需求,如果有什么地方存在问题或有疑问,欢迎指出,最近任务不紧接了个公司的小程序的任务,后续可能会贴出来一些小程序遇到的坑,iOS方面还会继续更新,如果觉得本文有些作用还请点个赞,感谢各方大佬~