iOS同步请求——基于AFNetworking和GCD

上一篇分析了同时回调多个请求的问题，那么还有一种情况在平时也比较常见——同步多个请求，比如在用户调用登录接口后再调用获取用户的详细信息接口，这里用接口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方面还会继续更新，如果觉得本文有些作用还请点个赞，感谢各方大佬~