大家好,我是展菲,目前在上市企业从事人工智能项目研发管理工作,平时热衷于分享各种编程领域的软硬技能知识以及前沿技术,包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者:《ESP32-C3 物联网工程开发实战》
图书作者:《SwiftUI 入门,进阶与实战》
超级个体:COC上海社区主理人
特约讲师:大学讲师,谷歌亚马逊分享嘉宾
科技博主:华为HDE/HDG
我的博客内容涵盖广泛,主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告,同时也会提供产品优缺点分析、横向对比,并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲:您的前沿技术领航员
👋 大家好,我是展菲!
📱 全网搜索“展菲”,即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”,每周定时推送干货满满的技术长文,从新兴框架的剖析到运维实战的复盘,助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”,与我直接交流,不管是项目瓶颈的求助,还是行业趋势的探讨,随时畅所欲言。
📅 最新动态:2025 年 3 月 17 日
快来加入技术社区,一起挖掘技术的无限潜能,携手迈向数字化新征程!
文章目录
- 前言
- await 写多了,不一定是并发
- 一个非常真实的业务场景
- Task Group:能解决,但有点重
- async let:Swift 并发里最好用的语法糖
- async let 到底“并发”在哪里?
- 一个完整、可运行的 Demo
- 放到真实业务里,差距会被无限放大
- 首页加载
- 详情页组合接口
- async let 什么时候不该用?
- 总结
前言
如果你已经开始用 Swift Concurrency,大概率写过下面这种代码:
leta=awaitfetchA()letb=awaitfetchB()写的时候很自然,用起来也没报错,但页面加载总感觉慢半拍。
后来你开始怀疑网络、怀疑后端、怀疑是不是埋点太多,唯独没怀疑过这两行代码。
但问题,往往就出在这里。
await 写多了,不一定是并发
先说一个容易被忽略的事实:
连续写的 await,默认是串行执行的。
也就是说,上面这段代码的真实执行顺序是:
- 等
fetchA()完成 - 拿到结果
- 再去等
fetchB()完成 - 两个都结束后,才继续往下走
哪怕fetchA和fetchB:
- 没有任何依赖关系
- 都是纯网络请求
- 理论上完全可以同时跑
Swift 也不会“帮你并发”。
一个非常真实的业务场景
想象一个常见页面:
- 请求用户信息
- 请求远程配置
- 两个接口互不影响
- 页面必须等两个接口都回来才能渲染
很多人第一反应就是这样写:
letuser=awaitfetchUserInfo()letconfig=awaitfetchRemoteConfig()代码没问题,但体验上就是——慢。
那有没有办法,让它们真的同时跑?
Task Group:能解决,但有点重
如果你对 Swift 并发比较熟,可能会想到 Task Group:
letresult=awaitwithTaskGroup(of:Int.self){groupingroup.addTask{awaittaskA()}group.addTask{awaittaskB()}awaitgroup.waitForAll()returnawaitgroup.reduce(0,+)}确实能并发,也很强大,但说实话:
- 为了等两个任务
- 写了一大坨模板代码
- 可读性开始下降
对于简单、固定数量的任务,这个成本有点高。
async let:Swift 并发里最好用的语法糖
Swift 其实早就考虑到了这种高频场景,于是给了一个非常舒服的写法:async let。
直接看代码:
asyncleta=taskA()asyncletb=taskB()letresult=awaita+bprint(result)这几行代码,解决了刚才所有问题:
taskA和taskB立即并发执行- 不需要 Task Group
- 逻辑非常贴近业务语义
async let 到底“并发”在哪里?
很多人第一次看到async let会有点疑惑:
asyncleta=taskA()// 为什么这里没有 await?原因其实很简单:
async let的作用不是“取值”- 而是“声明一个并发任务”
真正等待结果,是在你使用它的时候:
letresult=awaita+b也就是说:
任务启动和等待是分离的
这正是性能优化的关键。
一个完整、可运行的 Demo
下面这段代码可以直接跑,能非常直观地看到效果:
functaskA()async->Int{try?awaitTask.sleep(nanoseconds:1_000_000_000)print("taskA finished")return10}functaskB()async->Int{try?awaitTask.sleep(nanoseconds:2_000_000_000)print("taskB finished")return20}Task{asyncleta=taskA()asyncletb=taskB()letresult=awaita+bprint("result:",result)}执行结果类似:
taskA finished taskB finished result: 30重点不是输出顺序,而是——
总耗时只有 2 秒,而不是 3 秒。
放到真实业务里,差距会被无限放大
首页加载
asyncletuser=fetchUserInfo()asyncletconfig=fetchRemoteConfig()letdata=awaitHomeData(user:user,config:config)详情页组合接口
asyncletdetail=fetchDetail(id:id)asyncletstock=fetchStock(id:id)asyncletpromotion=fetchPromotion(id:id)letviewModel=awaitViewModel(detail:detail,stock:stock,promotion:promotion)这种地方如果写成串行,
慢的不是一个接口,而是整个用户体验。
async let 什么时候不该用?
它也不是银弹,有明确边界:
- 任务数量是动态的 → 用 Task Group
- 需要复杂的失败回滚 → Task Group 更合适
- 生命周期要跨作用域 → async let 不行
一句话总结:
固定数量、互不依赖、结果要一起用 —— async let 是最优解。
总结
很多 Swift 并发性能问题,并不是你“不会并发”,
而是代码看起来像并发,实际却是串行。
async let这种语法,看似只是语法糖,
但在真实项目里,往往能直接决定一个页面是“秒开”还是“卡一下”。
如果你身边有人还在无意识地连写await,
把这篇文章丢给他,大概率能少踩一个坑。