iOS使用dispatch_group实现分组并发网络请求

本文探讨了在iOS开发中,如何使用GCD的dispatch_group和dispatch_semaphore来处理多个网络请求,实现请求的并发执行与顺序执行,确保数据加载效率与正确性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言

在实际开发中我们通常会遇到这样一种需求:某个页面加载时通过网络请求获得相应的数据,再做某些操作。有时候加载的内容需要通过好几个请求的数据组合而成,比如有两个请求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___上传打好水印的图片

通过重复运行打印结果可证实确实实现了我们想要的效果。这样即解决了所提出的问题二。

后续
如果看的不是特别明白,可以看看这篇文章,写的很棒
点我进入

 



作者:so_what
链接:https://www.jianshu.com/p/657e994aeee2
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

### 关于 `dispatch_group_leave` 函数 在 GCD 中,`dispatch_group_enter` 和 `dispatch_group_leave` 是成对使用的函数。当希望跟踪一组异步任务的完成情况时,可以使用这些函数来管理计数器。每当调用一次 `dispatch_group_enter` 就会增加计数器;而每次调用 `dispatch_group_leave` 则减少该计数器。 对于 `dispatch_group_wait` 或者 `dispatch_group_notify` 来说,在所有进入组中的任务都完成了相应的离开操作之后才会继续执行后续逻辑。如果忘记匹配地调用了这两个方法,则可能导致程序永远等待下去[^1]。 下面是展示如何正确使用 `dispatch_group_enter` 及其对应的 `dispatch_group_leave` 的例子: ```swift let group = DispatchGroup() let queue = DispatchQueue.global() // 进入分发组前先标记即将开始的任务数量 group.enter() queue.async { defer { // 确保无论成功与否都会退出分发组 group.leave() } // 执行一些耗时的操作... print("Task A started.") Thread.sleep(forTimeInterval: 2) print("Task A finished.") } // 同样处理另一个并发任务 group.enter() queue.async { defer { group.leave() } print("Task B started.") Thread.sleep(forTimeInterval: 1) print("Task B finished.") } // 当两个任务均已完成时触发通知 group.notify(queue: DispatchQueue.main) { print("Both tasks have been completed!") } ``` 需要注意的是,通常情况下推荐直接利用 Swift 提供更高层次抽象的方式如上所示代码片段那样,而不是手动去控制 enter/leave 对。因为这容易造成资源泄漏的风险 —— 如果异常发生未能正常 leave,则会导致死锁等问题出现[^4]。 #### 使用 `dispatch_group_wait` 实现同步阻塞直到所有任务结束 除了 notify 方式外还可以采用 wait 方法实现相同的效果,不过这种方式会使当前线程暂停直至满足条件为止: ```swift if case .timedOut = group.wait(timeout: .now() + 5.0){ print("Tasks took too long to complete") } else { print("All tasks were successfully processed within the timeout period") } ``` 这里设置了一个超时时间防止无限期挂起主线程。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值