Swift 并发的可视化与优化

Swift 并发的可视化与优化

了解如何利用 Instruments 中的 Swift 并发模板优化您的 App。我们将讨论常见的性能问题，并向您介绍如何借助 Instruments 查找与解决这些问题。学习如何保持您的 UI 响应性，最大化并行性能，以及分析您的 App 中的 Swift 并发活动。为能更好地理解此讲座，我们建议您先熟悉 Swift 并发 (包括任务和角色) 的相关内容。

资源
相关视频

WWDC23
- 使用 Instruments 分析挂起
- 超越结构化并发的基础
WWDC22
WWDC21
下载

♪ ♪
Mike: 欢迎来到 Swift 并发的可视化与优化我是 Mike 我从事 Swift 运行时库方面的工作 Harjas: 大家好我是 Harjas 从事 Instruments 方面的工作 Mike: 我们将一起讨论如何更好地理解您的 Swift 并发代码并使其运行得更快也会谈到在 Instruments 14 中提供的一个新可视化工具让我们先快速回顾一下 Swift Concurrency 的各个部分以及它们是如何一起工作的以确保您保持速度之后我们将演示新的并发工具我们将向您展示该如何使用它解决一些使用 Swift Concurrency 的 App 的实际性能问题最后我们将讨论潜在的线程池耗尽和continuation误用问题以及如何避免它们去年我们引入了 Swift Concurrency 这是一个新的语言功能包括 async/await 结构化并发和 Actor 我们很高兴地看到那之后在 Apple 内外这些功能都被大量运用 Swift concurrency 为该语言增加了几个新功能它们共同使并发编程更容易更安全 Async/await 是并发代码的基本语法构建块它们允许您创建并调用可以在执行过程中挂起工作并在稍后恢复工作的函数而不会阻塞执行线程
Task 是并发代码中的基本工作单元 Task 会执行并发代码并管理其状态和相关数据它们包含局部变量处理取消开始和挂起异步代码的执行结构化并发使生成并行运行的子任务并等待它们完成变得很容易该语言提供了将工作聚集在一起的语法并确保任务被等待或在不使用时自动取消 Actor 会协调需要访问共享数据的多个任务它们将数据与外部隔离并且每次只允许一个任务操作它们的内部状态从而避免了并发变更带来的数据竞争在 Instruments 14 中我们新引入了一套可以捕获及可视化 App 中所有这些活动的工具以帮助您了解 App 正在做什么定位问题并提高性能为了更深入地讨论 Swift Concurrency 的基本原理我们在相关视频部分放了几个关于这些功能的视频链接
让我们看看如何使用 Swift Concurrency 代码来优化 App Swift concurrency 使得编写正确的并发和并行代码变得很容易然而编写误用并发结构的代码仍然是可能的您也有可能正确地使用它们但无法获得您所期望的性能优势
在使用 Swift concurrency 编写代码时会出现一些常见的问题这些问题可能会导致性能下降或出现 bug Main Actor 阻塞会导致 App 中止 Actor 争用和线程池耗尽会减少并行执行从而损害性能 continuation误用会导致泄漏或崩溃新的 Swift Concurrency 工具可以帮助您发现并修复这些问题让我们从 main Actor 阻塞开始逐一看看当一个长期运行的任务在 main Actor 上运行时就会发生 main Actor 阻塞 main Actor 是一个特殊的 Actor 它在主线程上执行所有工作 UI 工作必须在主线程上完成 main Actor 允许您将 UI 代码集成到 Swift Concurrency 中但是因为主线程对 UI 非常重要所以它需要保持可用不能被长时间运行的工作单元占用当这种情况发生时您的 App 会像锁定一样并不再响应在 main Actor 上运行的代码必须快速完成要么完成它的工作要么将计算从 main Actor 移到后台通过将工作放到一个普通的 Actor 或一个分离的任务中可以将它移到后台小的工作单元可以在 main Actor 上执行以更新 UI 或执行其他必须在主线程上完成的任务让我们看看实际的演示 Harjas: 谢谢 Mike 这是我们的 File Squeezer App 我们构建这个 App 是为了能够快速压缩文件夹中的所有文件对小文件它似乎运行得很好然而当我使用更大的文件时它花费的时间比预期长得多 UI 完全停摆不响应任何交互这种行为会让用户非常反感可能会让他们认为 App 已经崩溃或永远不会完成运作我们应该努力确保我们的 UI 能够持续响应最佳用户体验为了研究这个性能问题我们可以使用 Instruments 中新的 Swift Concurrency 模板 Swift Tasks 和 Swift Actors 工具提供了一套完整的工具来帮助您可视化并优化并发代码当您刚刚开始调查性能问题时您应该首先查看一下 Swift Tasks 工具提供给您的顶层统计数据其中第一个是 Running Tasks 它显示了有多少任务正在同时执行接下来是我们的 Alive Tasks 它会显示在给定的时间点上有多少任务出现最后是 Total Tasks 它会绘制到该时间点为止已创建的任务总数当您试图减少 App 的内存占用时应该仔细查看 Alive 和 Total Tasks 统计信息所有这些统计数据的组合可以让您很好地了解代码的并行化情况以及正在消耗多少资源该工具的众多细节视图之一是 Task Forest 它被显示在这个窗口的下半部分提供了结构化并发代码中任务之间的主从关系的图形表示接下来是我们的 Task Summary 视图这显示了每个任务在不同状态下花费的时间我们已经通过允许您右键单击一个任务就将包含所选任务所有信息的轨道固定到时间线上使视图更加强大这允许您快速查找并了解需要关注的可能运行了很长时间或等待访问 Actor 的任务一旦您把一个 Swift Task 固定到时间线上就会得到四个关键功能首先是显示您的 Swift Task 处于什么状态的轨道接下来是扩展详细视图中的任务创建回溯第三个是叙述视图它提供了更多关于 Swift Task 所处状态的背景例如如果它正在等待一个任务它将通知您正在等待哪个任务最后您可以在叙述视图中访问与在摘要视图中相同的固定操作所以您可以把一个子任务一个线程甚至一个 Swift Actor 固定到时间线上这种叙述视图有助于发现一个 Swift Task 如何与其他并发原语和 CPU 相关联现在我们已经简要地了解了新工具中的一些功能让我们来分析 App 并优化代码吧我们可以在 Xcode 中拉出我们的项目按下 Command-I 来实现这一点这将编译我们的 App 打开 Instruments 并将目标预选为 File Squeezer App 您可以从这里在模板选择器中选择 Swift Concurrency 选项并开始记录
我再次将大文件放入了 App 中
我们再次看到 App 开始旋转 UI 没有响应我们将让它再运行几秒钟以便 Instruments 能够捕获关于我们 App 的所有信息
既然我们有了线索那么就可以开始调查了我要全屏显示这段跟踪以便更好地看到所有信息
我们可以使用 option+拖拽来放大我们感兴趣的区域
在进程跟踪中 Instruments 向我们显示了 UI 中止发生的确切位置对于不清楚中止的发生时间或持续时间的情况这很有用正如我前面提到的一个很好的起点是顶层 Swift Task 统计数据我马上注意到的是 Running Tasks 计数大多数时候只有一个任务在运行这告诉我们部分问题在于我们的所有工作都被迫序列化我们可以用 Task State 摘要来查找运行时间最长的任务并使用固定操作将其固定到时间线上
这个任务的叙述视图告诉我们它在后台线程上运行了一小段时间然后在主线程上运行了很长一段时间为了进一步研究我们可以将主线程固定到时间线上
主线程被几个长时间运行的任务阻塞这就展示了 Mike 提到的 Main Actor 阻塞问题所以我们要问自己的问题是 “这个任务在做什么” 以及 “这个任务从何而来” 我们可以回到叙述视角来回答这两个问题扩展详细视图中的创建回溯显示任务是在 compressAllFiles 函数中创建的这个说明显示任务正在执行 compressAllFiles 中的一号闭包右键单击这个符号我们就可以在源代码查看器中打开它
这个函数中的一号闭包调用了我们的压缩代码现在我们知道了这个任务是在哪里创建的以及它在做什么我们就可以在 Xcode 中打开我们的代码并调整它了这样我们就不会在主线程上运行这些繁重的计算 compressAllFiles 函数位于 CompressionState 类中整个 CompressionState 类被注释为在 @MainActor 上运行这解释了为什么任务也运行在主线程上我们需要将这个类放在 MainActor 上因为这里的 @Published 属性必须只从主线程更新否则我们可能会遇到运行时问题因此我们可以尝试将这个类转换为它自己的 Actor 然而编译器会告诉我们不能这样做因为我们其实是在说这个共享的可变状态需要由两个不同的 Actor 保护但这确实给了我们一个关于真正的解决方法是什么的提示在这个类中我们有两个不同的可变状态其中一个状态即 files 属性需要与 MainActor 隔离因为 SwiftUI 会观察它但是需要保护对另一种状态即日志的访问不受并发访问的影响但是在任何给定的点上哪个线程访问日志并不重要因此它实际上并不需要被放在 Main Actor 上但是我们仍然希望保护它不受并发访问的影响所以我们要将它封装到自己的 Actor 中我们现在所要做的就是添加一种方法让 Task 根据需要在两者之间进行跳转我们可以创建一个新的 Actor 并将其命名为 ParallelCompressor
然后我们可以将日志状态复制到新的 Actor 中并添加一些额外的设置代码
从这里开始我们需要让这些 Actor 相互通信首先让我们从 CompressionState 类中删除引用日志变量的代码并将其添加到 ParallelCompressor Actor 中
最后我们需要更新 CompressionState 以在 ParallelCompressor 上调用 compressFile
有了这些更改让我们再次测试 App 我要再次把大文件放到 App 中
UI 不再中止这是一个很大的改进但我们没有得到我们期望的速度我们很想充分利用机器中的所有核心以尽可能快的速度完成这项工作 Mike 我们还应该注意什么呢
Mike: 我们把工作从 Main Actor 上移走解决了卡顿问题但我们仍没有得到我们想要的性能要知道为什么我们需要仔细看看 Actor Actor 使多个任务可以安全地操纵共享状态但是它们是通过序列化对共享状态的访问来实现这一点一次只允许一个任务占用 Actor 其他需要使用该 Actor 的任务将会等待 Swift concurrency 允许使用非结构化任务任务组和 async let 进行并行计算理想情况下这些结构能够同时使用多个 CPU 核心当使用这些代码中的 Actor 时要注意不要在这些任务共享的 Actor 上执行大量的工作当多个任务试图同时使用同一个 Actor 时 Actor 将序列化这些任务的执行因此我们失去了并行计算的性能优势
这是因为每个任务都必须等待 Actor 可用要解决这个问题我们需要确保当任务真正需要独占访问 Actor 的数据时才在 Actor 上运行其他的都应该在 Actor 之外运行我们要把任务分成几块有些块必须在 Actor 上运行而其他的则不需要非 Actor 隔离块可以并行执行这意味着计算机可以更快地完成工作让我们看看运行中的演示 Harjas: 谢谢 Mike 让我们看看我们更新的 File Squeezer App 的轨迹并想着 Mike 刚刚告诉我们的内容 Task Summary 显示我们的并发代码在 Enqueued 状态中花费了惊人的时间这意味着我们有很多任务等待着获得对 Actor 的独占访问权让我们锁定其中一个任务来了解原因
这个任务在运行压缩工作之前会花很长时间等待进入 ParallelCompressor Actor 让我们继续将 Actor 固定到时间线上
这里我们有 ParallelCompressor Actor 的一些顶层数据这个 Actor Queue 似乎被一些长时间运行的任务阻塞了任务应该只在 Actor 上停留其需要的时间让我们回到任务叙述上
在 ParallelCompressor 上排队之后任务会在 compressAllFiles 的一号闭包中运行所以让我们从那里开始调查源代码显示了这个闭包主要是在运行我们的压缩工作因为 compressFile 函数是 ParallelCompressor Actor 的一部分所以这个函数的整个执行都发生在 Actor 上阻塞了其他所有压缩工作要解决这个问题我们需要把 compressFile 函数从 Actor 隔离中取出来放到一个分离的任务中
通过这样做我们就可以通过分离的任务在 Actor 上尽占用更新相关可变状态所需的时长所以现在压缩函数可以在线程池中的任何线程上自由执行直到它需要访问被 Actor 保护的状态例如当它需要访问 files 属性时它将移到 Main Actor 上但一旦完成它就会再次进入 “并发的海洋” 直到它需要访问 logs 属性为此它会移到 ParallelCompressor Actor 上但同样地一旦在那里完成它就会再次离开 Actor 继续在线程池上执行不过当然了我们不是只有一个在做压缩工作的任务我们有很多这样的任务由于不受 Actor 的限制它们都可以并发执行只受线程数量的限制
当然每个 Actor 一次只能执行一个任务但大多数时候我们的任务不需要在 Actor 上执行因此就像 Mike 解释的那样这允许我们的压缩任务并行执行并利用所有可用的 CPU 核心现在我们来做些改变
我们可以将 compressFile 函数标记为非隔离的
这确实会导致一些编译器错误通过将它标记为 nonisolated 我们是在告诉 Swift 编译器我们不需要访问这个 Actor 的共享状态但这并不完全正确这个日志功能是受 Actor 隔离的并且需要访问共享的可变状态为了解决这个问题我们需要让这个函数异步然后用 await 关键字标记所有的日志调用
现在我们需要更新任务创建以创建一个分离的任务
我们这样做是为了确保任务不会继承曾创建它的 Actor 上下文对于分离的任务我们需要显式捕获 self
让我们再次测试我们的 App
该 App 能够同时压缩所有文件并使 UI 保持响应为了验证我们的改进我们可以检查 Swift Actors 工具看看 ParallelCompressor Actor Actor 上执行的大部分工作都是在很短的时间内完成的队列的大小也不会超出控制范围总结一下我们使用 Instrument 来分析 UI 卡顿的原因重新构造我们的并发代码以获得更好的并行性并使用数据验证性能改进现在 Mike 要告诉我们一些其他潜在的性能问题 Mike: 除了我们在演示中看到的我还想讲两个常见的问题首先让我们讨论一下线程池耗尽线程池耗尽会损害性能甚至导致 App 死锁 Swift concurrency 要求任务在运行时向前推进当任务在等待什么的时候它通常通过挂起完成但是任务中的代码可以执行阻塞调用例如阻塞文件或网络 IO 或获取锁而不挂起这打破了任务向前推进的要求当这种情况发生时任务会继续占用它正在执行的线程但它实际上并没有使用 CPU 核心由于线程池是有限的其中一些线程被阻塞了并发运行时将无法完全使用所有 CPU 内核这减少了可执行的并行计算量降低了 App 的最大化性能在极端情况下当整个线程池被阻塞的任务所占用并等待一些需要在线程池上运行的新任务并发运行时可能会死锁确保避免任务中阻塞的调用文件和网络 IO 必须使用异步 API 执行避免等待条件变量或信号量如果需要细粒度短暂持有的锁是可以接受的但是要避免有大量争用或长时间持有的锁如果您有需要完成这些任务的代码请将该代码移出并发线程池例如通过在 Dispatch 队列上运行它并使用 continuation 将其桥接到并发世界只要有可能使用异步 API 来替换阻塞操作以保持系统的顺畅运行在使用 continuation 时必须小心正确地使用它们 continuation 是 Swift concurrency 和其他形式的异步代码之间的桥梁 continuation 会暂停当前任务并提供一个在调用时恢复任务的回调函数然后这可以与基于回调的异步 API 一起使用从 Swift concurrency 的角度看任务会挂起然后在 continuation 被恢复时恢复从基于回调的异步 API 的角度来看工作开始然后在工作完成时调用回调 Swift Concurrency Instrument 知道 continuation 并会标记相应的时间间隔显示任务正在等待一个 continuation 被调用 continuation 回调函数有一个特殊的要求它们必须被调用一次不能多也不能少在基于回调的 API 中这是一个常见的需求但它往往是非正式的并且不被语言强制执行常常发生疏忽 Swift concurrency 将此作为一个硬性需求如果回调函数被调用两次程序就会崩溃或出错如果从未调用回调任务将会泄漏在这个代码片段中我们使用 withCheckedContinuation 来获得 continuation 然后调用一个基于回调的 API 在回调中我们恢复 continuation 这满足了恰好调用它一次的要求当代码比较复杂时一定要小心在左侧我们修改了回调只在成功时恢复 continuation 这是一个 bug 一旦失败 continuation 将不会恢复任务将永远挂起在右边我们恢复了两次 continuation 这也是一个 bug App 将不正常运行或崩溃这两个片段都违背了只恢复一次 continuation 的要求有两种可用的 continuation checked 和 unsafe 除非性能绝对重要否则 continuation 一定要使用 withCheckedContinuation API checked continuation 会自动检测误用并标记错误当 checked continuation 被调用两次时 continuation 会卡住当 continuation 根本没有被调用时 continuation 被销毁时会向控制台打印一条消息警告您 continuation 泄漏了 Swift Concurrency 工具将显示相应的任务无限期停留在 continuation 状态 Instruments 中有很多新的 Swift Concurrency 模板您可以获得结构化并发的图形可视化查看任务创建调用树并检查确切的组装指令以获得 Swift Concurrency 运行时的全貌要想了解更多关于 Swift Concurrency 如何在后台运作的信息请观看去年的讲座 “Swift Concurrency: Behind the Scenes” 要想了解更多关于数据竞争的知识请观看利用 Swift 并发消除数据争用感谢收看 Harjas: 祝您调试并发代码愉快

@MainActor
class CompressionState: ObservableObject {
    @Published var files: [FileStatus] = []
    var logs: [String] = []
    
    func update(url: URL, progress: Double) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].progress = progress
        }
    }
    
    func update(url: URL, uncompressedSize: Int) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].uncompressedSize = uncompressedSize
        }
    }
    
    func update(url: URL, compressedSize: Int) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].compressedSize = compressedSize
        }
    }
    
    func compressAllFiles() {
        for file in files {
            Task {
                let compressedData = compressFile(url: file.url)
                await save(compressedData, to: file.url)
            }
        }
    }
    
    func compressFile(url: URL) -> Data {
        log(update: "Starting for \(url)")
        let compressedData = CompressionUtils.compressDataInFile(at: url) { uncompressedSize in
            update(url: url, uncompressedSize: uncompressedSize)
        } progressNotification: { progress in
            update(url: url, progress: progress)
            log(update: "Progress for \(url): \(progress)")
        } finalNotificaton: { compressedSize in
            update(url: url, compressedSize: compressedSize)
        }
        log(update: "Ending for \(url)")
        return compressedData
    }
    
    func log(update: String) {
        logs.append(update)
    }

11:49 - CompressionState class using ParallelCompressor actor

actor ParallelCompressor {
    var logs: [String] = []
    unowned let status: CompressionState
    
    init(status: CompressionState) {
        self.status = status
    }
    
    func compressFile(url: URL) -> Data {
        log(update: "Starting for \(url)")
        let compressedData = CompressionUtils.compressDataInFile(at: url) { uncompressedSize in
            Task { @MainActor in
                status.update(url: url, uncompressedSize: uncompressedSize)
            }
        } progressNotification: { progress in
            Task { @MainActor in
                status.update(url: url, progress: progress)
                await log(update: "Progress for \(url): \(progress)")
            }
        } finalNotificaton: { compressedSize in
            Task { @MainActor in
                status.update(url: url, compressedSize: compressedSize)
            }
        }
        log(update: "Ending for \(url)")
        return compressedData
    }
    
    func log(update: String) {
        logs.append(update)
    }
}

@MainActor
class CompressionState: ObservableObject {
    @Published var files: [FileStatus] = []
    var compressor: ParallelCompressor!
    
    init() {
        self.compressor = ParallelCompressor(status: self)
    }
    
    func update(url: URL, progress: Double) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].progress = progress
        }
    }
    
    func update(url: URL, uncompressedSize: Int) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].uncompressedSize = uncompressedSize
        }
    }
    
    func update(url: URL, compressedSize: Int) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].compressedSize = compressedSize
        }
    }
    
    func compressAllFiles() {
        for file in files {
            Task {
                let compressedData = await compressor.compressFile(url: file.url)
                await save(compressedData, to: file.url)
            }
        }
    }
}

17:46 - CompressionState class using ParallelCompressor with minimal actor-isolation and detached tasks

actor ParallelCompressor {
    var logs: [String] = []
    unowned let status: CompressionState
    
    init(status: CompressionState) {
        self.status = status
    }
    
    nonisolated func compressFile(url: URL) async -> Data {
        await log(update: "Starting for \(url)")
        let compressedData = CompressionUtils.compressDataInFile(at: url) { uncompressedSize in
            Task { @MainActor in
                status.update(url: url, uncompressedSize: uncompressedSize)
            }
        } progressNotification: { progress in
            Task { @MainActor in
                status.update(url: url, progress: progress)
                await log(update: "Progress for \(url): \(progress)")
            }
        } finalNotificaton: { compressedSize in
            Task { @MainActor in
                status.update(url: url, compressedSize: compressedSize)
            }
        }
        await log(update: "Ending for \(url)")
        return compressedData
    }
    
    func log(update: String) {
        logs.append(update)
    }
}

@MainActor
class CompressionState: ObservableObject {
    @Published var files: [FileStatus] = []
    var compressor: ParallelCompressor!
    
    init() {
        self.compressor = ParallelCompressor(status: self)
    }
    
    func update(url: URL, progress: Double) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].progress = progress
        }
    }
    
    func update(url: URL, uncompressedSize: Int) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].uncompressedSize = uncompressedSize
        }
    }
    
    func update(url: URL, compressedSize: Int) {
        if let loc = files.firstIndex(where: {$0.url == url}) {
            files[loc].compressedSize = compressedSize
        }
    }
    
    func compressAllFiles() {
        for file in files {
            Task.detached {
                let compressedData = await self.compressor.compressFile(url: file.url)
                await save(compressedData, to: file.url)
            }
        }
    }
}

正在查找特定内容？在上方输入一个主题，就能直接跳转到相应的精彩内容。

提交你查询的内容时出现错误。请检查互联网连接，然后再试一次。

资源

相关视频

WWDC23

WWDC22

WWDC21