目录

  1. 场景
  2. NSURLConnection 中的同步请求
  3. Dispatch_semaphore（信号量）
  4. Dispatch_group（组）
  5. 总结
  6. 广告

场景

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

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

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

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

NSURLConnection 中的同步请求

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

1
2
3
4

+ (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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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 不会触发。贴一段代码 + 一张效果图（源码）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 创建 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];
});

browser-jd

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

总结

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

广告

欢迎关注微信公众号

wechat-qrcode