【Swift 进阶】一招解决多任务等待：让你的 iOS 应用速度飙升

### 前言

最近在开发一个需要同时处理多个网络请求的功能时，我深刻体会到了 Swift 并发系统的强大。如果你曾经为如何同时等待多个异步任务完成而头疼，今天这篇文章将为你揭开 Swift 并发编程的另一层面纱。我们将深入探讨如何高效地等待多个异步任务，让你的 iOS 应用性能更上一层楼。

### 异步与并发：别混淆了概念

我记得刚接触 Swift 并发编程时，总是把异步和并发搞混。其实，这两个概念并不等同——**标记为 `async` 的函数并不会自动并发执行**。这是我不知踩了多少次的坑了，也是我在代码审查中经常看到的问题。

来看个我前两天才重构的代码：

```
func loadData() async throws -> Product.Recommendations {
    let featured = try await loadFeatured()
    let favorites = try await loadFavorites()
    let latest = try await loadLatest()
    
    return Product.Recommendations(
        featured: featured,
        favorites: favorites,
        latest: latest
    )
}
```

乍一看没问题，但实际上这三个加载操作是**按顺序排队等待**的。想象一下，用户点击进入页面，傻傻地盯着加载动画转啊转，每个请求 1 秒，等了足足 3 秒才看到内容，那种感觉...我自己用都想砸手机了。

### 顺序等待的坑，我掉进去了

去年我在给某电商客户做首页推荐系统时，用户反馈说打开太慢。我翻开代码一看，原来是所有请求都在排队等待。产品经理在旁边"友善"地问我："为什么我们的页面比竞品慢这么多？"那一刻，我感受到了来自灵魂深处的尴尬。

最初我的"聪明"解决方案是这样的：

```
func loadData() async throws -> Product.Recommendations {
    try await Product.Recommendations(
        featured: loadFeatured(),
        favorites: loadFavorites(),
        latest: loadLatest()
    )
}
```

看着这段代码，我还洋洋得意以为自己优化了性能...直到用 Instruments 测试后一脸懵逼 —— 性能根本没提升！Swift 编译器依然按顺序处理这些调用，我又一次被语法表象骗了。

### async-let：救命稻草终于来了

### ![Discover async let — Swift with Vincent](https://mmbiz.qpic.cn/mmbiz_png/4ial9Ho3r07B8hiaOyzylicgKtmsF3sSxqC168xPZRGY4BgtHX8QP2jSfHlbVOPnCicSR72Kqvu01yhbzFAXZ3wNyw/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1&wx_co=1)

研究了几天后，我发现了 `async-let` 这个语法，简直就是救命稻草：

```
func loadData() async throws -> Product.Recommendations {
    async let featured = loadFeatured()
    async let favorites = loadFavorites()
    async let latest = loadLatest()
    
    return try await Product.Recommendations(
        featured: featured,
        favorites: favorites,
        latest: latest
    )
}
```

代码改完后，我在测试设备上运行，页面加载时间从 3.5 秒降到了 1.2 秒！那种感觉，就像是把一辆拖拉机升级成了跑车。产品经理看到优化结果时一脸惊讶："就改了这么几行代码？"，我假装这是小事一桩，心里却在暗爽。

### Task Groups：处理动态任务的得力助手

实际开发中，我们经常会遇到需要并发处理不确定数量任务的情况。比如上周我正在开发的相册功能，需要加载用户选择的所有图片。

最初的实现简单粗暴：

```
func loadImages(from urls: [URL]) async throws -> [URL: UIImage] {
    var images = [URL: UIImage]()
    
    for url in urls {
        images[url] = try await loadImage(from: url)
    }
    
    return images
}
```

测试时我选了 20 张图片，等啊等...足足等了 25 秒才加载完。简直是糟糕体验的教科书级案例！

于是我掏出了 Task Group 这个大杀器：

```
func loadImages(from urls: [URL]) async throws -> [URL: UIImage] {
    try await withThrowingTaskGroup(of: (URL, UIImage).self) { group in
        for url in urls {
            group.addTask {
                let image = try await self.loadImage(from: url)
                return (url, image)
            }
        }
        
        var images = [URL: UIImage]()
        
        fortry await (url, image) in group {
            images[url] = image
        }
        
        return images
    }
}
```

改完后，那 20 张图片只用了 2 秒就全部加载完毕，简直就是见证奇迹的时刻！我清晰地记得测试工程师瞪大眼睛的表情："这也行？"

### 实战教训："并发"不是万能药

经历了几个项目的"血与泪"后，我总结了几点血泪教训：

1. **固定任务数量**就用 `async-let`。上周我就因为为了"统一代码风格"，给三个并发任务硬用了 Task Group，结果代码反而变得复杂且难以维护，被同事在代码审查中狠狠吐槽了一番。
2. **动态任务**必须用 Task Group。这点没得商量，除非你想写一堆丑陋的 if-else。
3. **有依赖的任务**老老实实按顺序来。我曾经尝试把有依赖关系的任务强行并发化，结果制造了一个隐藏了两周的 bug，排查过程简直是噩梦。
4. **资源有限，别无限并发**。上个月我在处理用户图库时，无脑并发加载几千张缩略图，然后...App 很光荣地崩溃了，用户投诉接连不断。设置合理的并发上限后，一切恢复正常。

### 数据竞争：并发编程的隐形杀手

并发编程最坑的就是数据竞争问题了。去年我负责的评分系统随机崩溃，排查了整整三天才发现是多个并发任务同时修改同一个字典导致的。那三天我过得生不如死，甚至梦见自己被 bug 追着跑...

几经折腾后，我总结了几招防身术：

1. **并发操作返回独立结果**，别直接修改共享变量。这招屡试不爽。
2. **能用值类型就别用引用类型**。记得有个同事特别喜欢用 class，结果并发问题接二连三，我帮他改成 struct 后问题神奇消失。
3. **遇到复杂状态管理就用 Actor**。自从 Swift 5.5 引入 Actor 后，我的并发代码稳定性提高了不少，以前动不动就崩的功能现在稳如泰山。

### 结语

玩转 Swift 的并发系统确实需要一点时间和经验，但掌握后绝对是值得的。从那些被优化的页面收到的用户好评，到那些因为流畅体验而增加的转化率，都证明了这一点。

记住，并发编程不是用来炫技的，而是解决实际问题的工具。用对了地方，你的应用会脱胎换骨；用错了地方，你会在调试中度过漫长的加班夜晚（没错，我就是前车之鉴）。

当你看到用户在 App Store 评论里夸你的应用"反应快得惊人"时，那种成就感是其他优化方法难以比拟的。Swift 并发，值得你花时间掌握的技能。

转自：iOS新知

【Swift 进阶】一招解决多任务等待：让你的 iOS 应用速度飙升

评论0