场景

在开发过程中，有时候会遇到这样一些问题，比如：

• 在某些业务要求下，需发送同步请求。
• 在某些界面需请求多个接口，且各个接口返回的数据之间或者整体存在依赖关系。
• ···

那么在上述的这些场景下应如何发送网络请求？发同步请求 or 异步请求？请求嵌套？······

本文将简单探究开发过程中网络请求同步的问题以及相关注意点。

NSURLConnection 中的同步请求

我们都知道 NSURLConnection 中有一个同步请求的 API :

+ (NSData *)sendSynchronousRequest:(NSURLRequest *)request
returningResponse:(NSURLResponse **)response
error:(NSError **)error

针对上述的第一种情况 A，该 API 可满足要求。如果同步请求阻塞主线程的时间过长，存在被 watchdog kill 的可能。想避免这种情况，建议在子线程中调用此 API。(感兴趣的同学可以看看，关于 watchdog timeout crashes/Understanding and Analyzing Application Crash Reports)

同步请求相对异步请求而言存在一些缺陷，如：

1. 请求发出后，就无法取消
2. 返回的数据只能放到请求结束后进行处理
3. ···

很遗憾，NSURLConnection 目前已被苹果全面弃用，并且 AFNetworking 在 3.x 中已经移除此类 API，因此同步请求不建议采用此种方式。

Dispatch_semaphore（信号量）

信号量机制，我们可以简单理解为资源管理分配的一种抽象方式。在 GCD 中，提供了以下这么几个函数，可用于请求同步等处理，模拟同步请求：

1. dispatch_semaphore_t semaphore = dispatch_semaphore_create(value);
2. dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
3. dispatch_semaphore_signal(semaphore);

value 可以理解为资源数量，以 value = 0 为例，调用 dispatch_semaphore_wait 操作成功后，当资源数量 value 等于 0 时，就会阻塞当前线程（反之，value 就会减 1），直到有 dispatch_semaphore_signal 通知信号发出，当 value 大于 0 时，当前线程就会被唤醒继续执行其他操作。

下面我们展示一段代码来模拟同步请求：

Objective-C:

    // 1.创建信号量
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
    NSLog(@"0");
    // 开始异步请求操作（部分代码略）
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        NSLog(@"1");
        // This function returns non-zero if a thread is woken. Otherwise, zero is returned.
        // 2.在网络请求结束后发送通知信号
        dispatch_semaphore_signal(semaphore);
    });
    // Returns zero on success, or non-zero if the timeout occurred.
    // 3.发送等待信号
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    NSLog(@"2");

    // print 0、1、2
    

Swift:

    func sendSynchronousDataTask(with url: URL) -> (Data?, URLResponse?, Error?) {
        var data: Data?
        var response: URLResponse?
        var error: Error?
        // 1.创建信号量
        let semaphore = DispatchSemaphore(value: 0)
        // 开始异步请求操作
        let dataTask = URLSession.shared.dataTask(with: url) {
            data = $0
            response = $1
            error = $2
            // 2.在网络请求结束后发送通知信号
            semaphore.signal()
        }
        dataTask.resume()
        // 3.发送等待信号
        _ = semaphore.wait(timeout: .distantFuture)
        
        return (data, response, error)
    }

在 iOS 系统中，如果应用不能及时的响应用户界面交互事件（如启动、暂停、恢复和终止），watchdog 就会杀死程序并生成一个 watchdog 超时崩溃报告，据官方说法，watchdog timeout 时间并没有明文规定，但一般会少于网络请求超时时间。

In order to keep the user interface responsive, iOS includes a watchdog mechanism. If your application fails to respond to certain user interface events (launch, suspend, resume, terminate) in time, the watchdog will kill your application and generate a watchdog timeout crash report. The amount of time the watchdog gives you is not formally documented, but it’s always less than a network timeout.

这里有一个奇怪的现象，经测试，笔者采用信号量机制一直阻塞主线程时并没有被 watchdog kill，但 NSURLConnection 中的同步请求方法 + sendSynchronousRequest:returningResponse:error: 在慢速网络下与其说 crash 了，不如说被 watchdog kill 了。不扯远了，开始下一个话题 —— dispatch_group_t

Dispatch_group（组）

继续本文话题，回顾文章开头提到的问题，如果针对单个请求进行同步处理，那么使用同步请求即可，上述两种方式都可以。如果在某些界面需请求多个接口，且各个接口返回的数据之间或者整体存在依赖关系，那怎么办呢？虽然采用嵌套请求的方式能解决此问题，但存在很多问题，如：其中一个请求失败会导致后续请求无法正常进行、多个请求在时间上没有复用，即无并发性。

A dispatch group is a mechanism for monitoring a set of blocks. Your application can monitor the blocks in the group synchronously or asynchronously depending on your needs. By extension, a group can be useful for synchronizing for code that depends on the completion of other tasks.

针对这种情形，即某个操作依赖于其他几个任务的完成时，我们可采用 dispatch_group。主要使用如下两个函数：

1. dispatch_group_enter(group);
2. dispatch_group_leave(group);

以上这两个函数必须配对使用，否则 dispatch_group_notify 不会触发。贴一段代码 + 一张效果图（源码）：

    // 创建 dispatch 组
    dispatch_group_t group = dispatch_group_create();
    
    // 第一个请求：
    dispatch_group_enter(group);
    [self sendGetAddressByPinWithURLs:REQUEST(@"getAddressByPin.json") completionHandler:^(NSDictionary * _Nullable data, NSError * _Nullable error) {
        NSArray *addressList = [TXAddressModel mj_objectArrayWithKeyValuesArray:data[@"addressList"]];
        self.addressList = addressList;
        dispatch_group_leave(group);
    }];
    
    // 第二个请求
    dispatch_group_enter(group);
    [self sendCurrentOrderWithURLs:REQUEST(@"currentOrder.json") completionHandler:^(NSDictionary * _Nullable data, NSError * _Nullable error) {
        TXCurrentOrderModel *currentOrderModel = [TXCurrentOrderModel mj_objectWithKeyValues:data];
        self.currentOrderModel = currentOrderModel;
        dispatch_group_leave(group);
    }];
    
    // 当上面两个请求都结束后，回调此 Block
    dispatch_group_notify(group, dispatch_get_main_queue(), ^{
        NSLog(@"OVER:%@", [NSThread currentThread]);
        [self setupOrderDataSource];
    });

对于熟悉 dispatch_group 的同学来说，可能会想，为何不用 dispatch_group_async？对于网络请求而言，请求发出时它就已经执行完毕，也就是 block 中还有个 completeHandler 的情况下，dispatch_group_async 并不会等待网络请求的回调，所以不符合我们要求。

总结

通过本文简单探究，展示了如何采用信号量机制模拟同步请求，在开发过程中，我们应尽量避免发送同步请求；并且在某个操作依赖于其他几个任务的完成时，采用 dispatch_group_async or dispatch_group_enter/dispatch_group_leave 来实现同步等处理。如果是进行网络请求同步，应采用后者。当然，如果感兴趣，我们可以在第三方网络库的基础上封装一层自己网络库。（相关源码）

广告

欢迎关注微信公众号