gpt4 book ai didi

ios - 构造多级dispatchQueue会不会有什么不好的事情发生

转载 作者:搜寻专家 更新时间:2023-11-01 06:26:17 25 4
gpt4 key购买 nike

片段1

let workerQueue = DispatchQueue(label: "foo")
workderQueue.async {
#code
DispatchQueue.main.async {
#code
workerQueue.async {
#code

}
}
}

片段2

let workerQueue = DispatchQueue(label: "foo")
DispatchQueue.main.async {
#code
workerQueue.async {
#code
DispatchQueue.main.async {
#code

}
}
}

可以编写代码片段 1 或片段 2 这样的代码吗?主线程会不会被阻塞?

最佳答案

不,这些模式本身并没有什么“坏”之处。

话虽如此,典型的模式是:

workerQueue.async {
// do something computationally intensive

DispatchQueue.main.async {
// update UI and/or model
}
}

这是因为“我有一些足够密集的东西,我不希望它在主队列上运行(并且对用户体验产生不利影响),但是当我完成后,我需要更新我的 UI 和/或模型。”

您很少有更高级别的嵌套,如您的第一个示例所示,“当我更新完 UI 后,我需要将其他内容分派(dispatch)回我的同一个工作队列”。如果您有这方面的实际示例,也许您可​​以与我们分享,因为可能有更优雅的重构方法来避免嵌套调度的“塔”,这可能会开始使代码有点难以理解。

在你的第二个例子中,你首先分派(dispatch)到主线程的地方也有点不典型。 (是的,我们偶尔不得不这样做,但这种情况不太常见。)我猜你假设你已经在其他线程上了(尽管并非总是如此)。如果是这种情况,代码期望您在特定线程上,您可能希望明确做出该假设,例如:

func foo() {
dispatchPrecondition(condition: .onQueue(workerQueue))

// do some stuff that should be on the `workerQueue`

DispatchQueue.main.async {
// update UI, etc.

...
}
}

最重要的是,任意级别的嵌套绝对没有问题,特别是如果使用 async 进行嵌套...使用 sync 进行嵌套可能会引发死锁问题,如果你不小心。但从实际情况来看,“ future 的程序员能否阅读这段代码并清楚地推断出最终的行为是什么”,您通常会希望对其进行约束,以免造成混淆。


作为一个实际的例子,我可能正在一些专用功能队列(例如数据库访问队列或图像处理队列)上做一些事情,我可能需要使用另一个同步队列来确保线程安全访问,我可能需要在主队列上进行 UI 更新。但是我通常没有这个三级队列塔,但是,例如,我封装了这些不同的级别以避免混淆(例如,我有一个读写器泛型,它封装了我用于线程的并发队列的细节-安全访问),并且我的代码避免了在任何给定方法中复杂地混合不同类型的调度队列。在任何特定的抽象级别上,我都试图避免一次出现太多不同的队列类型。

关于ios - 构造多级dispatchQueue会不会有什么不好的事情发生,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/54102721/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com