Cocoa框架中wxYield的等效实现，解决大文件压缩UI冻结问题

你遇到的界面冻结是因为耗时的压缩解压任务运行在主线程，阻塞了主事件循环的UI刷新、用户交互事件处理。Cocoa生态不推荐使用类似wxYield手动出让事件循环的方案，更合理的实现是将耗时任务与主线程UI操作分离。

1 对标wxYield的快速兼容方案（不推荐生产环境使用） #

如果需要最小改动适配现有逻辑，可以在压缩任务的每轮处理间隙手动触发主事件循环处理待执行事件，效果和wxYield一致：

// 每次更新进度后插入该行代码
[[NSRunLoop mainRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.01]];

该方案的缺陷非常明显：嵌套的RunLoop可能导致重复触发任务、逻辑时序混乱，同时存在内存泄漏风险。

2 推荐的GCD多线程方案 #

将压缩解压的IO/计算任务放到后台队列执行，所有UI更新操作切回主队列处理，完全不会阻塞主线程响应：

// 主线程先展示进度窗口
self.progressWindow.hidden = NO;
self.progressBar.doubleValue = 0;

// 提交任务到后台串行队列执行
dispatch_async(dispatch_get_global_queue(QOS_CLASS_UTILITY, 0), ^{
    // 执行压缩/解压逻辑，每处理一块数据触发进度回调
    BOOL taskResult = [self doCompressTaskWithProgress:^(double currentProgress) {
        // 进度更新必须切回主队列
        dispatch_async(dispatch_get_main_queue(), ^{
            self.progressBar.doubleValue = currentProgress;
        });
    }];
    
    // 任务结束后切回主线程处理收尾
    dispatch_async(dispatch_get_main_queue(), ^{
        self.progressWindow.hidden = YES;
        // 按业务需求弹出成功/失败提示
    });
});

• 所有UI控件的读/写操作必须放在主队列执行，后台线程操作UI会导致界面异常甚至崩溃
• 可以为后台任务添加取消标记，支持用户中途终止任务，避免资源浪费
• 大文件处理建议使用流式读写，不要一次性加载全量文件到内存，降低内存占用

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