Swift中asyncAfter设0延迟仍有延迟的原因探究

先直接给结论：这种延迟和创建新线程完全无关，根源在于RunLoop与GCD的任务调度机制差异。

关于DispatchQueue.main.asyncAfter(deadline: .now() + 0.0) #

主队列是串行队列，它的任务调度完全依赖主线程的RunLoop。哪怕你设置了0延迟，GCD也不会让这个block立即插入当前执行流——它会把任务放到主队列的待处理列表中，等待当前RunLoop循环的所有任务执行完毕，下一次RunLoop迭代时才会触发执行。

而直接调用self.updateUI()是在当前执行上下文里同步执行，属于当前RunLoop循环的一部分，所以两者的执行时机有明显差异，看起来就像是带asyncAfter的代码有“延迟”。

关于performSelector(_:withObject:afterDelay:) #

这个API的逻辑和上面类似，它本质是通过RunLoop的定时器来触发方法执行。哪怕设置afterDelay: 0，系统也会把这个方法注册为一个“零延迟”定时器，而RunLoop只会在当前循环周期的所有任务完成后，才会处理定时器事件，所以同样要等到下一次RunLoop迭代才会执行onFlip方法。

直观的对比例子 #

假设你正在执行一个耗时的同步任务：

print("开始执行耗时任务")
for _ in 0..<100000000 { /* 模拟耗时操作 */ }
// 直接调用会在耗时任务结束后立即执行
self.updateUI()
// asyncAfter(0)会在耗时任务结束、当前RunLoop周期完成后才执行
DispatchQueue.main.asyncAfter(deadline: .now() + 0.0) {
    self.updateUI()
}

这里直接调用的updateUI会紧跟耗时任务执行，而asyncAfter的block则要等当前RunLoop周期结束、进入下一轮循环才会运行，这就是你感知到“延迟”的原因。

总结 #

这种“延迟”本质是任务调度时机的差异：直接调用是同步执行（当前上下文立即执行），而0延迟的asyncAfter和performSelector是异步调度到下一次RunLoop迭代执行，全程都在主线程，没有创建任何新线程。

内容的提问来源于stack exchange，提问作者Saranjith