Swift并发编程：async/await实战 —— 一个深夜炼丹师的血泪总结
作者：某大厂AI算法工程师，兼职iOS野生开发者。坐标帝都，通勤1h，靠深夜写代码续命。最近被Swift并发模型“教育”了一番，遂有此文。
上周五晚上十一点半，我瘫在工位上，盯着Xcode里那堆红得发紫的编译错误，脑子里只有一个念头：“产品经理是不是觉得我的头发太密了？”
事情是这样的：我们团队正在搞一个智能推荐组件，需要从后端拉取用户画像、实时行为日志、A/B实验配置等一堆异步数据。以前用DispatchQueue+completionHandler还能凑合，但这次逻辑复杂度直接爆表——多个接口要并行请求，部分结果又要串行依赖，还有一堆超时、重试、缓存策略。更离谱的是，这玩意儿要在主线程更新UI，稍不注意就卡成PPT。
就在Deadline前48小时，我一拍大腿：“不如直接上Swift 5.5的async/await吧！” 毕竟Apple WWDC都吹了两年了，再不用真要被时代淘汰了（顺便面试时也能多点谈资）。
于是，一场人与编译器的深夜Battle开始了……
为什么是现在？
说实话，我之前一直对Swift并发持观望态度。毕竟作为算法工程师，主业是Python调参、CUDA优化、分布式训练那一套。iOS开发只是副业（老板让我顺手维护个内部工具App）。但今年公司搞“全栈化”，要求算法也要懂前端交互，领导一句“你不是会Swift吗？”直接把我架在火上烤。
再加上最近在看跳槽机会，刷LeetCode的同时也翻了不少iOS面经。发现“讲讲Swift并发模型”、“async/await和GCD的区别”这类题出现频率极高。有些公司甚至要求现场手写TaskGroup实现并发控制……不学不行啊！
初体验：从地狱到天堂（差点）
先看一段“祖传代码”：
// 老派写法：回调地狱嵌套三层
NetworkService.fetchUserProfile { user, error in
guard let user = user else { return }
NetworkService.fetchUserBehavior(userId: user.id) { behavior, error in
guard let behavior = behavior else { return }
RecommendationEngine.process(user: user, behavior: behavior) { result in
DispatchQueue.main.async {
self.updateUI(with: result)
}
}
}
}
光是缩进就让人窒息！更别说错误处理分散、难以测试、无法取消任务……每次改需求都像拆炸弹。
换成async/await后画风突变：
// 新派写法：线性逻辑，清爽如德芙
do {
let user = try await NetworkService.fetchUserProfile()
let behavior = try await NetworkService.fetchUserBehavior(userId: user.id)
let result = try await RecommendationEngine.process(user: user, behavior: behavior)
await MainActor.run {
self.updateUI(with: result)
}
} catch {
handleError(error)
}
那一刻，我仿佛看到了圣光——原来异步代码也能像同步一样读！再也不用在回调里找爸爸了！
但别高兴太早，坑才刚刚开始……
踩坑实录：那些让我想砸MacBook的瞬间
坑1：async函数不能直接在非并发上下文中调用
我兴冲冲把上面的代码塞进viewDidLoad，结果Xcode直接报错：
'async' call in a function that does not support concurrency
WTF？ 原来UIViewController的方法默认不在并发上下文中！必须用Task包裹：
override func viewDidLoad() {
super.viewDidLoad()
Task {
// 现在可以调用async函数了
await loadData()
}
}
开发心得：记住！任何想用
await的地方，要么本身是async函数，要么包在Task里。这是Swift并发的“入场券”。
坑2：主线程更新UI的正确姿势
你以为这样就完了？Too young！当我把updateUI放在Task里直接调用，App直接Crash：
Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
原因：Task默认在后台线程执行！而UIKit要求所有UI操作必须在主线程。
解决方案有两个：
- 用
MainActor.run { }显式切回主线程（推荐） - 把整个函数标记为
@MainActor
// 方案1：局部切换
Task {
let data = try await fetchData()
await MainActor.run {
self.label.text = data.title // 安全！
}
}
// 方案2：全局标记（适合整个VC都是UI相关）
@MainActor
class MyViewController: UIViewController {
// 所有方法自动在主线程
}
面试题预警：面试官常问“如何保证async代码中UI更新在主线程？” 答案就是
MainActor！
坑3：并发请求？别忘了TaskGroup！
回到最初的需求：要并行拉取用户资料、行为日志、实验配置。如果傻乎乎地串行写：
let user = try await fetchUser()
let behavior = try await fetchBehavior()
let config = try await fetchConfig() // 串行！总耗时 = 三者之和
那性能直接打骨折。正确姿势是withTaskGroup：
func loadAllData() async throws -> (User, Behavior, Config) {
return try await withThrowingTaskGroup(of: LoadResult.self) { group in
group.addTask { .user(try await self.fetchUser()) }
group.addTask { .behavior(try await self.fetchBehavior()) }
group.addTask { .config(try await self.fetchConfig()) }
var user: User!
var behavior: Behavior!
var config: Config!
for try await result in group {
switch result {
case .user(let u): user = u
case .behavior(let b): behavior = b
case .config(let c): config = c
}
}
return (user, behavior, config)
}
}
enum LoadResult {
case user(User)
case behavior(Behavior)
case config(Config)
}
效果立竿见影：原本1.2s的加载时间，直接压到400ms！用户再也不用看菊花转半天了。
开发心得：
TaskGroup是Swift并发的“核武器”，但要注意错误处理——任何一个子任务失败，整个Group都会抛出异常。
性能对比：数据说话
为了说服团队全面迁移，我做了个简单benchmark（模拟3个200ms网络请求）：
| 方案 | 平均耗时 | 代码复杂度 | 可维护性 |
|---|---|---|---|
| GCD + 回调嵌套 | 610ms | ⭐⭐⭐⭐⭐ | ⭐ |
| GCD + DispatchGroup | 210ms | ⭐⭐⭐ | ⭐⭐ |
| async/await 串行 | 605ms | ⭐ | ⭐⭐⭐⭐ |
| async/await + TaskGroup | 205ms | ⭐⭐ | ⭐⭐⭐⭐⭐ |
结论很清晰：并发性能不输GCD，代码可读性碾压。
App Store审核避坑指南
别以为代码跑通就万事大吉！去年双11期间，我们就因为并发问题被App Store拒过一次。
场景：在application(_:didFinishLaunchingWithOptions:)里用Task初始化SDK，结果审核机器检测到“主线程阻塞”。
原因：虽然Task是异步的，但如果在App启动关键路径里滥用，仍可能因资源竞争导致卡顿。
解决方案：
- 避免在
AppDelegate里做重型异步操作 - 用
Task.detached明确脱离当前Actor（慎用！） - 启动时的必要初始化，优先用同步方式+缓存
// 审核友好写法
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
// 同步初始化轻量配置
SDK.shared.setup(with: cachedConfig)
// 异步刷新（不阻塞启动）
Task {
let freshConfig = try await ConfigService.fetch()
SDK.shared.updateConfig(freshConfig)
}
return true
}
血泪教训：Apple对启动性能极其敏感，哪怕你的代码“理论上”不卡主线程，也可能被误杀。
面试题精析：高频考点整理
结合最近面试经历，整理几个Swift并发必问题：
Q1: async/await和GCD的本质区别是什么？
答：
- GCD是基于队列的并发模型，开发者手动管理线程、队列、同步原语
async/await是结构化并发（Structured Concurrency），由Swift运行时自动管理任务生命周期、取消、优先级- 关键优势：自动传播取消信号、更好的错误处理、避免线程爆炸
Q2: 什么是Actor？为什么需要MainActor？
答：
- Actor是Swift 5.5引入的隔离状态模型，保证同一时间只有一个任务访问其可变状态（类似GCD的串行队列，但更安全）
MainActor是特殊的Actor，绑定到主线程，用于保护UI状态- 最佳实践：所有UI相关的类/属性，用
@MainActor标记
Q3: 如何取消一个正在进行的async任务？
答：
- 用
Task的cancel()方法 - 在
async函数内部定期检查Task.isCancelled - 或使用
withTaskCancellationHandler注册清理逻辑
let task = Task {
while !Task.isCancelled {
// 做点耗时的事
try await Task.sleep(nanoseconds: 1_000_000_000) // 1秒
}
}
// 取消
task.cancel()
写在最后：从抗拒到真香
现在回头看，当初被逼着学Swift并发，其实是件好事。不仅解决了项目燃眉之急，代码Review时同事都夸“这逻辑清晰得不像你写的”（扎心了）。
更重要的是，它让我意识到：现代编程语言正从“如何并发”转向“如何安全地并发”。Swift的Actor模型、结构化并发，本质上是在帮开发者避开那些年我们踩过的坑——死锁、竞态、内存泄漏……
当然，深夜加班还是少不了。昨晚又改到凌晨两点，不过这次是因为在TaskGroup里漏了个try，导致测试环境崩了……运维大哥在群里@我：“兄弟，你是不是对‘稳定’有什么误解？”
但没关系，至少代码比以前优雅多了。毕竟，一个合格的炼丹师，既要调得好模型，也要写得出好代码，对吧？
附：实用速查表
场景 推荐方案 简单异步调用 Task { await ... }并行任务 withTaskGroup/withThrowingTaskGroupUI更新 MainActor.run { }或@MainActor需要取消 保存 Task引用，调用cancel()脱离当前上下文 Task.detached(priority: .background) { }记住：不要为了用新特性而用！评估项目Swift版本（需>=5.5）、团队熟悉度、是否值得重构。有时候，老派GCD反而更稳妥。
本文代码已在真实项目验证，兼容iOS 15+。如果你也在北京，通勤路上欢迎一起吐槽Swift并发（或者约个深夜debug局？）
评论 0