为何私有队列dispatch_async更新UI晚于主队列？附UI更新实现疑问

嗨，这个问题问到点子上了，咱们从UIKit的规则和GCD的调度逻辑两方面来拆解：

先明确：后台线程更新UI是不可靠的“侥幸行为” #

首先得纠正一个认知：虽然有时候你在后台线程调用UI方法看起来能生效，但这完全是未定义行为——UIKit框架本身是非线程安全的，苹果官方明确要求所有UI操作（包括绘制、控件属性修改等）必须在主线程执行。

• 偶尔成功只是因为刚好没触发线程冲突（比如主线程此时没操作同一个UI元素），但随时可能导致崩溃、界面错乱、渲染异常等问题，绝对不能依赖这种写法。

为什么后台队列的UI更新会晚于主队列？ #

回到你的核心问题，这本质是GCD的队列调度优先级和主线程RunLoop的机制决定的：

• 主队列的优先级绑定：主队列是串行队列，并且直接绑定主线程的RunLoop。主线程的RunLoop会优先处理主队列中的任务——毕竟UI刷新、手势事件响应（比如你的UIPanGestureRecognizer回调）都是在主线程RunLoop的特定模式下执行的，系统会优先保证主线程的UI任务及时完成。
• 后台并发队列的调度延迟：你用的DISPATCH_QUEUE_PRIORITY_DEFAULT全局并发队列，任务调度优先级低于主队列。系统会先把CPU资源倾斜给主线程，只有当主线程空闲时，才会调度后台队列的任务到空闲线程执行。光是线程启动、任务调度就会产生延迟。
• UI渲染的主线程依赖：哪怕后台线程强行执行了绘制操作，UIKit的渲染管线（比如Core Animation的提交、屏幕刷新）都是由主线程驱动的。后台的绘制结果无法及时同步到渲染服务，最终就会出现明显的滞后。

针对你的场景的正确写法 #

你的需求是“主线程画原始点，后台计算旋转点后再绘制”，正确的做法是后台只做计算，绘制必须切回主队列，示例代码如下：

CGPoint touchPoint = [sender locationInView:self.view];
// 主线程处理原始点的绘制
[pencilLayer[0] addPoint:touchPoint];

// 后台线程仅执行旋转点的计算逻辑
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    // 这里写旋转点的计算代码，比如自定义的旋转逻辑
    CGPoint rotatedPoint = [self calculateRotatedPoint:touchPoint];
    
    // 计算完成后切回主队列执行UI绘制
    dispatch_async(dispatch_get_main_queue(), ^{
        [pencilLayer[1] addPoint:rotatedPoint];
    });
});

这样既利用了后台线程做耗时计算，又保证了UI操作的线程安全，还能避免更新滞后的问题。

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