使用 Instruments 分析挂起

使用 Instruments 分析挂起

UI 元素通常是对现实世界交互的模仿，包括实时响应。如果 App 的用户交互明显延迟，也就是出现挂起，则可能会打破这种幻想并让用户产生挫败感。我们将向你展示如何使用 Instruments 来分析、理解和修复所有 Apple 平台 App 中的挂起。了解如何有效地查看 Instruments 跟踪文档、解释跟踪数据并记录其他分析数据，从而更好地了解特定的挂起。如果你不熟悉使用 Instruments，我们建议你首先观看“Instruments 入门指南”。如果你想了解可以帮助你发现 App 挂起的其它工具，请查看“通过 Xcode 和设备端检测追踪挂起”。

章节
- 1:56 - What is a hang?
- 3:51 - What is instant?
- 4:39 - Event handling and rendering loop
- 8:25 - Keep main thread work below 100ms
- 9:15 - Busy main thread hang
- 14:26 - Too long or too often?
- 21:46 - LazyVGrid still hangs on iPad
- 24:31 - Fix: Use task modifier to load thumbnail asynchronously
- 25:52 - Asynchronous hangs
- 32:38 - Fix: Get off of the main actor
- 35:57 - Blocked Main Thread Hang
- 39:19 - Fix: Make shared property async
- 40:35 - Blocked Thread does not imply unresponsive app
资源
相关视频

WWDC23
- 解密 SwiftUI 性能
- 认识 RealityKit Trace
WWDC22
- 利用 Xcode 和设备端检测对卡顿进行跟踪
- Swift 并发的可视化与优化
WWDC21
- 了解和消除 app 挂起
- Swift 并发功能：幕后故事
Tech Talks
- 探索 UI 动画阻碍与渲染循环
WWDC20
- SwiftUI 中的叠放、网格和大纲
WWDC19
- Instruments 入门
WWDC16
- System Trace in Depth
下载

♪ ♪
Joachim Kurz：欢迎观看 “用 Instruments 分析挂起” 我是 Joachim Instruments 团队的一名工程师今天我们来详细了解一下挂起我将先向你简单介绍什么是挂起为此我们会谈到人类的感知然后我将简要介绍事件处理与渲染循环因为这是理解挂起形成原因的基础有了这些理论知识我们将话题转向 Instruments 并共同讨论三个不同的挂起例示：繁忙的主线程挂起、异步挂起和阻塞的主线程挂起对于每种情况我将向你展示如何识别它们在分析它们时要关注什么以及如何知道何时将其他工具添加到你的文档中来进一步了解更多细节开始之前作为本次讲座的一部分稍微熟悉一下 Instruments 会效果更好如果你曾经使用 Instruments 分析过 App 那你可以继续往下观看否则建议查看我们 2019 年的讲座“Instruments 入门指南”
处理挂起时通常分为三个步骤：找到挂起然后分析该挂起来找到它发生的原因最后修复它 (并验证该挂起的确已修复) 今天我们会假设你已经找到了一个挂起将重点放在分析部分以及一些修复措施的讨论如果你想了解更多有关查找挂起的信息可以看看我们的另一场讲座 WWDC22 的“通过 Xcode 和设备端检测追踪挂起” 那次讲座涵盖了我们用于查找挂起的所有工具包括 Instruments、设备端挂起检测 (你可以在 iOS 开发者设置中启用) 和 Xcode Organizer 今天我们将使用 Instruments 分析一个已经发现的挂起为了更好地理解挂起我们来谈谈人类的感知和灯的打开
我们需要一个灯泡和一根电线啊好多了对于灯来说当我插入电线时它就会亮起当我将电线拔掉时它就会立刻熄灭但如果有延迟会是什么样子？我将电线插入但需要一段时间才能打开更奇怪的是当我拔掉电线时会发生同样的情况从电线插入到灯打开的时间只有 500 毫秒但你可能已经开始好奇这个盒子里到底发生了什么灯不能即时开关感觉有点奇怪不过在其他一些情况下 500 毫秒的延迟也无伤大雅什么样的延迟是可以接受的要取决于具体情况假设你无意中听到这样的对话： “乌龟是如何交流的？” “用乌龟专用手机” 在这里问题和答案之间有一秒钟的延迟感觉很自然但电灯开关并非如此
这是为什么？乌龟和独角兽的对话是一种请求—响应式交互但把电线插入一盏灯却是直接操作一个真实的物体真实的物体会立即做出反应如果我们模拟一个真实的东西它也应该立即做出反应如果没有就会带来虚假感
我说这是一盏真正的灯时你没有任何意见是因为在电缆插入到灯打开之间没有任何延迟但当出现明显的延迟时你的大脑会突然说：“等等这东西不是这样运作的” 但即时有多快呢？什么延迟才会小到让我们注意不到？
这是基线没有延迟
100 毫秒怎么样？
对我来说感觉就像我在打开它时注意到了一点点延迟但在关闭它时却没有除非我仔细观察才能发现你的体验可能会有所不同 100 毫秒是一个阈值明显较小的延迟其实是无法感知的让我们试试 250 毫秒
250 毫秒感觉就不再是即时的了并不慢但延迟绝对是明显的
这些感知阈值也为我们的挂起报告提供了参考对于离散交互比如轻点一个按钮来说低于大约 100 毫秒的延迟通常感觉是即时的在某些特殊情况下你可能希望能更低于该值但 100 毫秒是一个不错的目标除此之外还要根据具体情况而定延迟在 250 毫秒以下你可能都觉得还可以如果超过这个时间延迟就会变得明显至少在潜意识里是如此这是一个连续的尺度但超过 250 毫秒后肯定不会感觉是即时的因此我们的大多数工具默认从 250 毫秒开始报告挂起但我们称它们为“轻微挂起” 因为它们很容易被忽视根据具体情况这些挂起也可能并不是问题但通常情况并非如此所有超过 500 毫秒的延迟我们都认为肯定算是挂起基于此我们可以粗略使用以下阈值：如果你想让某些东西感觉即时那么延迟的目标是 100 毫秒或更短如果你需要请求—响应式交互 500 毫秒内没有任何反馈可能也可以接受但实际上在同一次交互中经常是两者兼而有之让我们看一个例子
我刚刚写完这封邮件想发给所有帮助准备这次讲座的同事我已经准备发送邮件了我将鼠标移至 Send 按钮并点击片刻之后电子邮件窗口移出屏幕表明邮件正在发送在这个过程中你实际上看到了两件事的发生首先按钮突出显示然后有 500 毫秒的小延迟接着电子邮件窗口移出屏幕但这种延迟感觉没问题因为我们已经知道按钮突出显示表示系统收到了我们的请求我们将按钮视为“真实”的东西我们希望它能“真实”地立即刷新
因此对于界面中的实际 UI 元素我们通常希望实现这种“即时”刷新为了让我们的 UI 元素 “即时”响应保持主线程免受非 UI 工作的影响是至关重要的想知道原因让我们来仔细了解事件处理和渲染循环看看 Apple 平台是如何处理事件的以及用户输入触发屏幕更新的机制
在某个时间点会出现人与设备的交互我们无法控制这种情况发生的时间首先这个过程通常会涉及一些硬件例如鼠标或触摸屏这些硬件会检测到交互创建一个事件并将其发送到操作系统操作系统确定将该事件交给哪个进程处理并将其转发到该进程例如你的 App 在 App 中 App 主线程负责处理事件这也是大部分 UI 代码运行的地方它决定着更新 UI 的方式然后这个 UI 更新被发送到渲染服务器这是一个单独的进程负责合成各个 UI 层并渲染下一帧最后显示驱动获取渲染服务器准备的位图并相应地更新屏幕上的像素如果你想了解更多有关其工作原理的信息可以查阅“提高 App 响应能力”的有关文档对于大家来说刚刚的概述足以帮助你了解目前的进程现在当另一个事件在此期间到来时它们通常可以并行处理但是如果我们只看单个事件是如何通过管线传输的那我们仍需按顺序查看所有步骤在我们进入主线程之前的事件处理步骤以及之后的渲染和更新显示步骤在其持续时间内通常是相当可预测的当我们在交互中遇到明显的延迟时原因往往是主线程上的某些部分花费了太长时间或者当事件进入时主线程上还有其他任务在执行所以需要等待其完成才能处理这一事件鉴于每次更新 UI 元素都需要在主线程上花费一些时间且为了感官上更加真实我们希望这些更新能在 100 毫秒内完成理想情况下主线程上的任何活动都不应超过 100 毫秒如果能更快一点那就再好不过了请注意主线程上长时间运行的活动也可能会导致卡顿通常采用较低的阈值以避免出现卡顿你可以在我们的 Tech Talk 讲座 “探索 UI 动画卡顿和渲染循环” 以及我们关于“提高 App 响应能力” 的文档中了解更多关于卡顿的知识今天我们重点讨论挂起我的一位同事在为我们的一款叫做 Backyard Birds 的 App 开发新功能时刚刚在其中发现了一处挂起让我们使用 Instruments 分析一下该 App
我准备好了这个 App 的 Xcode 项目要在 Instruments 中分析该 App 我只需要点击 Product 菜单再点击 Profile 然后 Xcode 就会构建该 App 并将其安装到设备上但并不会启动 App
Xcode 还会打开 Instruments 并且以 Xcode 中配置的相同的 App 和设备为目标进行配置在 Instruments 的模板选择器中选择 Time Profiler 模板如果你还不知道要寻找什么并想更好地了解你的 App 正在做什么 Time Profiler 通常是一个很好的起点上述操作将以 Time Profiler 为模板创建一个新的 Instruments 文档在这个新文件包含的工具中 Time Profiler 工具和 Hangs 工具对我们的分析都很有用点击工具栏左上角的 Record 按钮开始录制 Instruments 启动配置好的 App 并开始捕获数据
现在 Backyard Birds App 已经启动了我轻点第一个花园进入细节视图当我接着轻点 “Choose Background”按钮时应该出现一个底部列表显示可供选择的背景图片现在让我这么做试试我点击了按钮但似乎卡住了过了好一段时间列表才出现这是一个严重挂起
Instruments 一直在记录这一切我在工具栏中点击 Stop 按钮来停止录制 Instruments 也检测到了挂起它测量挂起的持续时间并根据严重程度标记相应的区间在这种情况下 Instruments 显示发生了“严重挂起” 这也符合我们在使用该 App 时所经历的情况 Instruments 检测到主线程无响应并将相应的间隔标记为可能出现挂起在我们的例子中也确实发生了挂起主线程无响应主要有两种情况最简单的情况是主线程只是仍然忙于处理其他活动在这种情况下主线程将显示大量 CPU 活动另一种情况是主线程被阻塞这通常是因为主线程正在等待其他地方完成某些工作当线程被阻塞时主线程上几乎没有 CPU 活动你的情况决定了你下一步应该采取哪些步骤来确定发生了什么回到 Instruments 我们需要找到 Main Thread 文档中的最后一个轨道显示了我们目标进程的轨道其左侧有一个小的展开按钮表明存在子轨道点击该指示器显示进程中每个线程的单独轨道然后在此选择 Main Thread 轨道这样做还会更新详细信息区域显示 Profile 视图该视图展示了整个记录时间内在主线程上执行的所有函数的调用树
但我们只关注挂起期间发生的事情因此我接着在时间线中右键点击 Hang-interval 打开子菜单我可以在这里选择 Set Inspection Range 但我要按住 option 键然后选择 Set Inspection Range and Zoom
这将放大间隔的范围并将细节视图中显示的数据过滤到选定的时间范围
虽然在整个挂起间隔期间 CPU 使用率不是 100% 但数值仍然相当高大多数时候 CPU 使用率在 60% 到 90% 之间这显然是主线程繁忙的情况让我们看看 CPU 在做什么
我们可以在这个视图中仔细查看调用树中的所有不同节点但右侧有一个很好的总结： Heaviest Stack Trace 视图当我点击该视图中的一个框架时调用树视图会更新以显示该节点这也向我们表明这个方法调用已经在调用树中十分深入了
默认情况下 Heaviest Stack Trace 隐藏了非源自源代码的后续函数调用方便用户更容易地查看源代码涉及的位置我们可以通过点击底部栏中的 Call Tree 按钮并启用 Hide System Libraries 复选框将类似的过滤器应用于调用树视图这将从系统库中过滤出所有函数并让我们更容易专注于自己的代码调用树视图显示几乎所有的回溯都包含 “BackgroundThumbnailView.body.getter”调用看来我们应该让 body getter 再快一点你觉得呢？不尽然！所以我们现在知道存在主线程繁忙的情况这意味着 CPU 正在做很多工作我们还发现了有一种方法在消耗大量 CPU 时间但现在有两种不同的情况我们在这个方法中花费了大量的 CPU 时间可能是因为这个方法本身运行了很长时间但也可能是这种方法被调用了很多次所以它才出现在这里我们应该如何减少主线程上的工作取决于具体情况
典型的调用堆栈结构如下这里有一个 main 函数的调用它会调用一些 UI 框架和其他东西然后在某个时刻你的代码会被调用如果这个函数只被调用一次并且一次调用需要很长时间比如这里的乌龟函数那么我们就要查看一下它调用了什么如果它做了很多工作那我们也许就能少做点但也可能是我们正在调查的这个方法被调用了很多次就像这里的独角兽一样当然它所做的工作也就反复进行了很多次这通常是因为有调用方多次调用独角兽函数例如从循环中调用与其优化我们关注的独角兽函数不如研究如何减少调用该函数的次数
这意味着我们下一步需要考虑的方向取决于我们面临的具体情况对于长时间运行的函数例如我们的乌龟案例我们应该看看它的实现和被调用者我们需要往下看然而如果一个函数被调用很多次比如独角兽那么更有效的做法是查看是什么调用了它并确定是否可以减少调用次数我们需要向上看但 Time Profiler 无法告诉我们现在是哪种情况我们假设对独角兽和乌龟的调用是接连发生的 Time Profiler 通过间隔一定的时间检查 CPU 上运行的内容来收集数据对于每个样本它都会检查 CPU 上当前正在运行哪个函数在此示例中我们将获得乌龟和独角兽分别出现四次的数据但也可能是乌龟函数速度很快而独角兽则需要更长的时间或者其他情况的组合所有这些场景都将在 Time Profiler 中创建相同的数据
要测量特定函数的执行时间请使用 os_signposts 我们在 2019 年的讲座中介绍了如何做到这一点详见“Instruments 入门指南” 但也有适用于各种技术的专门工具可以准确地告诉你发生了什么 SwiftUI View Body 工具便是其中之一要添加 SwiftUI Body 工具的话点击工具栏右上角的加号按钮即可打开 Instruments 库这是 Instruments App 提供的所有工具的列表非常丰富你甚至可以编写自定义工具
我在过滤器字段中输入“SwiftUI” 系统显示出两个工具选择“View Body”工具并将其拖到文档窗口中完成添加现在由于上次记录时该工具不在文档中所以它没有可显示的数据但没问题我们就再记录一次吧为了节省时间我已经记录好了我在文档中用 SwiftUI View Body 工具记录后 View Body 轨道现在也显示出一些数据 SwiftUI 视图主体轨道中有很多间隔轨道有点窄所以我按下 Ctrl+Plus 增加轨道高度 SwiftUI View Body 轨道根据实现它们的库对间隔进行分组每个间隔代表执行一次 body 视图让我们再次放大挂起部分
第二轨中有很多橙色间隔都被标记为 “BackgroundThumbnailView” 这准确地告诉我们执行了多少个 body 视图以及每一次执行需要多长时间橙色表示特定 body 的执行时间比我们在 SwiftUI 中的目标时间稍长但更大的问题似乎是有多少个间隔在细节视图中有所有 body 间隔的简要情况点击 Backyard Birds 旁的展开按钮可以查看 Backyard Birds 中各个视图类型这表明 BackgroundThumbnailView 的 body 执行了 70 次平均持续时间约为 50 毫秒总持续时间超过 3 秒这几乎解释了我们所有的挂起时间但是当我们只需要在前面显示 6 张图像时 70 次似乎有点多在这种情况下应该减少调用 body 的次数所以我们需要查看 body getter 的调用者找出为什么它经常被调用并看看如何减少调用次数为了轻松找到相关代码我再次选择 Main Thread 轨道然后右键点击调用树中的 BackgroundThumbnailView.body.getter 节点打开子菜单然后选择“Reveal in Xcode”
这就在 Xcode 中打开了我们的 body 实现让我们来看看如何使用这个视图右键点击类型然后依次选择“Find”和 “Find Selected Symbol in Workspace” Find 导航器中的第一个结果就是我们要找的内容
这里我们的 “BackgroundThumbnailView”被用于 GridRow 内的一个 ForEach 而它又处于一个 Grid 的另一个 ForEach 内 Grid 会在创建时立即处理其全部内容因此即使我们只需要前几个背景缩略图它也会计算所有的背景缩略图但还有一个替代方案：LazyVGrid 它仅处理填满一个屏幕所需的视图 SwiftUI 中的许多视图都有 lazy 变体只处理所需视图这通常是减少工作量的简单方法然而在渲染相同的内容时 eager 变体使用的内存要少得多在默认情况下可以使用常规的 eager 变体但你发现由于前期工作过多而导致性能问题时请切换到 lazy 变体
我们在 WWDC 2020 上关于“SwiftUI 中的叠放、网格和大纲”的讲座中介绍了这些 lazy 变体并对其进行了更详细的描述让我们分析一下更新后的代码开始记录再次轻点 Choose Background 按钮重现这个挂起现在情况好多了虽然还是有一点延迟但已经没有之前那么严重了 Instruments 证实了这一点我们记录的挂起时间现在不到 400 毫秒这是一个轻微挂起 “View Body”轨道还显示我们现在只执行了 8 次 BackgroundThumbnail 的 body 符合我们的预期也许这就足够了轻微挂起并不是很明显通过分析 iPad 上的 Backyard Birds 我们还可以确保该 App 在其他设备类型上也能正常运行
看我正在 iPad 上运行 Backyard Birds 我打开了细节视图轻点“Choose Background”按钮这个列表需要很长时间才能出现列表出现后我们就能明白为什么会这么慢了因为我们的屏幕更大空间更大所以缩略图也更多了 Instruments 也记录了这次挂起
将检查范围集中在挂起间隔我们再次看到更多的 BackgroundThumbnailView 主体这也说得通现在我们需要在整个屏幕上渲染大约 40 个图像因为此时屏幕可以容纳更多图像因此同样的代码在 iPhone 上运行基本正常但在 iPad 上速度很慢这只是因为屏幕变大了这就是你应该同样修复轻微挂起的原因之一你在测试时看到的轻微挂起条件更改后可能对某些用户来说是就是明显的挂起我们现在只渲染填充屏幕所需的视图因此在减少调用频率方面耗尽了优化潜力让我们看看如何才能使单次执行速度变得更快我将检查范围设置为单个 BackgroundThumbnailView 的间隔并切换回“Main Thread”轨道 Instruments 在 Heaviest Backtrace View 中显示了 view body getter 并显示它调用了名叫 “BackyardBackground.thumbnail” 的属性获取器这是一个模型对象它提供了要在我们的视图中显示的缩略图该缩略图获取器调用了“UIImage imageByPreparingThumbnailOfSize:” 我们似乎是顺手处理了缩略图这可能需要一些时间在本例中大约为 150 毫秒这是我们应该在后台进行的工作而不是让主线程被其占用为了更好地理解我们可以做的改变我想看看缩略图获取器被调用的环境我在 Heaviest Stack Trace 视图中右键点击 “BackgroundThumbnailView.body.getter” 然后选择“Open in Source Viewer” 调用树视图会变为源代码查看器显示了 body getter 的实现并用 Time Profiler 示例注释了实现的代码行显示了代码在不同地方花费了多少时间我们的 body 实现在这里非常简单；只是使用背景返回的缩略图创建一个新的 Image 视图但这个缩略图的调用需要很长时间我想到一个新的代码写法为了跳转到 Xcode 我点击右上角的菜单按钮并选择“Open file in Xcode”
和之前一样此处显示了我们在 Xcode 中的源代码可以随时进行修改我现在要做的是在后台加载缩略图并在加载过程中显示进度指示器首先我们需要一个状态变量来保存加载的缩略图
然后在 body 中如果我们已经加载了图像则将在 Image 视图中使用该图像否则会显示进度视图
现在剩下的就是加载实际的缩略图我们希望在进度视图出现后就开始加载缩略图这就是“.task”修饰符的作用
出现后 SwiftUI 将为我们启动一个任务即调用“thumbnail”获取器并将结果赋给“image” 由此更新视图让我们试试看！现在我使用 Instruments 开始记录轻点“Choose Background”按钮列表立刻就出现了！好极了！我们看到了进度指示器几秒钟后我们的缩略图就显示出来了成功太棒了！
等等 Instruments 仍然显示了将近 2 秒钟的挂起现在发生的情况是挂起的时间稍微晚了一些我们一起看看挂起在 Backyard Birds App 中在哪里发生我已经打开了细节视图紧接着我会再次轻点 “Choose Background”按钮然后尝试轻点 Done 按钮希望能直接删除工作表好的现在我依次点击 “Choose Background”和“Done” 我轻点了好多次但在加载过程中我的轻点被忽略了这就是 Instruments 报告给我们的挂起这次发生在工作表显示之后
这种挂起与之前的类型略有不同我们已经讨论过主线程繁忙与阻塞之间的区别还有另一种给挂起分类的方式就是挂起发生的原因与时间我们称之为同步挂起和异步挂起
在这里主线程正在进行一些工作如果一个事件进入后需要很长时间处理该事件那么这就是挂起假设我们控制住了这一因素确保事件得到快速处理但也许我们只是延迟了一些工作让主线程稍后再将其完成；或者主线程处理了一些其他工作然后一个新事件进来了所以该事件必须等待之前的工作完成后才能得到处理即使每个单独事件的代码能很快处理完成这仍然会导致挂起在我们的平台上挂起检测的工作方式是查看主线程上的所有工作项并检查相关项是否过长如果是则将其标记为潜在挂起无论是否有用户输入它都会这样做因为用户输入可能在任何时候发生然后我们就会面临真正挂起的出现这意味着挂起检测也会检测到这些异步或延迟情况但它只测算潜在的延迟而不是实际经历的延迟
我们之所以将异步挂起称为异步挂起是因为它们通常是由主队列上正在进行的 “dispatch_async”活动或在 main actor 上异步运行的 Swift Concurrency 引起的但是任何让主线程投入工作的原因都可能导致挂起我们看到的第一个挂起是同步挂起我们轻点了一个按钮触发了长时间运行的活动因此结果显示较晚
刚刚看到的挂起是异步或延迟挂起轻点 Done 按钮本身实际上并不会触发耗费较多时间的活动但是主线程上仍有正在处理的任务这导致了轻点没有被处理因此如果在此期间没有与 App 交互使用 App 的人可能根本不会注意到这个问题但我们仍应修复这些问题以防带来困扰现在就开始修复吧我又回到了 Instruments 我已经将选择范围设置为刚刚的异步挂起并进行了放大在 view body track 的摘要视图中 Instruments 显示我们的 BackgroundThumbnailView 的 body getter 现在有 75 次调用这是因为大多数缩略图 body getter 都被执行了两次 SwiftUI 创建了 40 个带有进度指示器的视图来填充网格但实际上最终只显示了 35 个对于这 35 个我们开始加载图像加载完成后视图会更新并再次调用 body 总共执行了 75 次 body getter
即使有所有 75 个 body getter 总执行时间也远远小于 1 毫秒所以我们的 body getter 现在速度已经很快了这部分完成了但是我们仍然有一个挂起我再次点击“Main Thread”轨道在 Heaviest Stack Trace 视图中由 Instruments 可知在主线程上耗时较长的仍然是缩略图获取器这一次它被 “BackgroundThumbnailView.body.getter” 中的闭包调用而不是直接被 body getter 调用双击它这是打开源代码查看器的快捷方式现在这正是我们期望在后台执行的代码因为它在任务修饰符的闭包中这段代码应该在此时运行但不应该在主线程上运行对于这样的问题即 Swift Concurrency 任务没有按照你期望的方式执行我们有另一个辅助解决工具： Swift Concurrency Tasks 工具我已经记录了添加 Swift Concurrency Tasks 工具后的相同行为 Swift Tasks 工具为文档添加了一个摘要轨道但对于我们的案例来说更有趣的是它为每个线程轨道贡献的数据这里在主线程轨道中有一个来自 Swift Tasks 工具的新图表单个轨道可以显示多个图表通过点击线程轨道标题中的向下箭头我可以配置显示哪些图表我可以选择另一个图表比如 Time Profiler 的 CPU Usage 图表或者在点击的同时按住 Command 键选择多个图表所以现在 Instruments 同时显示了这个线程的 CPU Usage 以及该线程的 Swift Tasks 图表再次放大挂起时间间隔现在“Swift Tasks”轨清晰显示了主线程上有大量任务在执行将检查范围设置为其中之一并检查 Profile 视图中的 Heaviest Stack Trace 确认该任务封装了我们的缩略图处理工作
因此这项工作如我们所愿被正确地封装在一个任务中但是该任务正在主线程上执行这出乎了我们的意料让我解释一下发生了什么首先 body getter 继承了 SwiftUI 的 View 协议中的 @MainActor 注释因为“body”在“View”协议中被注释为“@MainActor” 所以当我们实现它时 body getter 也被隐式注释为 @MainActor 其次 “.task”修饰符的闭包被注释为继承周围环境的 actor 而隔离由于 body getter 被隔离到 MainActor 任务闭包也将被隔离因此默认情况下在该闭包中运行的所有代码都将运行在 main actor 上并且由于 “thumbnail”获取器是同步的因此它现在同步运行在主线程上
默认情况下 Swift Concurrency Tasks 继承了周围环境的 actor 隔离 SwiftUI 的 .task 修饰符也有同样的行为有两种方法可以摆脱 main actor 异步调用未绑定到 main actor 的函数允许任务脱离 main actor 在某些情况下这是不可行的那么你可以通过使用 “Task.detached”显式地将任务从周围的 actor 环境中分离出来但这并不是最简捷的方法而且创建一个单独的任务比简单地暂停一个现有任务成本更高当相应的视图消失时 SwiftUI 还会自动取消通过任务修饰符创建的任务但这种取消不会像 Task.detached 那样传播到新的非结构化任务中要了解更多信息请查看 WWDC22 上的 “Swift Concurrency 的可视化和优化” 以及我们关于提高 App 响应速度的文档因为在我们的案例中我们已经处于异步环境中而且让缩略图函数转为非隔离和异步状态十分容易所以我们将选择第一个选项这里是我们的缩略图加载代码问题在于由于继承了 body getter 的 main actor 隔离这个任务将在 main actor 上执行而由于 thumbnail 获取器是同步的它也将停留在 main actor 上解决方法很简单我们跳转到 thumbnail 获取器的定义部分使获取器成为异步然后回到我们的视图结构……
因为我们的获取器现在是异步的所以需要在它前面添加 await
这将允许“thumbnail”获取器在 Swift Concurrency 并发线程池而不是主线程上执行我们来试试吧再次进入细节视图轻点 “Choose Background” 哇好快啊！不仅没有挂起而且整体加载速度似乎也更快了我几乎没有看到进度视图 Instruments 也确认现在没有挂起这里的 CPU 使用率很高让我放大一下这是现在加载缩略图的地方检查主线程我们可以确认主线程上的所有任务间隔现在都非常短向下滚动到其他线程轨迹可以发现我们的 Swift 任务现在是在其他线程上并行执行的而不是顺序执行这样就可以更好地利用我们的多核 CPU 由此我们能够在几百毫秒内处理完所有缩略图而无需花费将近 1.5 秒在这段时间内主线程始终保持响应因此我们现在已经彻底解决了这个问题
我们现在已经调查并修复了因主线程繁忙而导致的主线程无响应问题可以借由主线程在挂起期间使用大量 CPU 的现象来识别该问题我们还了解了挂起可以是同步的即直接作为用户交互的一部分发生；或者是异步的即之前在主线程上调度的工作导致传入的事件被延迟处理以及 Instruments 如何检测这两种情况我们通过减少工作和在后台进行其他无法减少的工作来修复挂起并且只在更新 UI 时回到主线程但还有一种情况我们还没有考虑过那就是主线程被阻塞在这种情况下主线程的 CPU 使用率会很低其他维度同样适用于被阻塞的主线程但是分析这种情况还需要其他工具现在我们来看一个例子
这里是另一个挂起的跟踪文件我已经放大了挂起部分挂起的时间很长有几秒钟在“Main Thread”轨道中 CPU 使用率图显示最初 CPU 使用率还有数值但随后就归零了这显然是主线程阻塞的情况我们讨论过 Time Profiler 如何通过对 CPU 上运行的程序取样来收集数据
当我们放大时 CPU 使用率图表甚至会显示单个样本因此这里的每个标记都是 Time Profiler 采集的样本右侧还有一些样本但之后就没有了但是当我选择一个没有样本的时间范围时 Time Profiler 无法告诉我们发生了什么因为这段时间它没有记录任何数据因此我们需要另一种工具： Thread States 工具与之前的其他工具一样你可以从 Instruments 库中添加该工具我已经再次记录了同样的挂起不过这次添加了 “Thread State Trace”工具现在这个工具有了一个新的轨道但是和“Swift Concurrency” 工具一样我们感兴趣的数据实际上在 “thread”轨道中在主线程中有一个很长的 “blocked”时间间隔超过 6 秒这解释了我们大部分的挂起持续时间当我点击间隔的中间位置时 Instruments 的时间游标也会移动到那里同时也会更新细节区域中的 Narrative 视图显示这个阻塞状态的条目 Narrative 视图告诉我们线程的故事：它在做什么何时做的以及为什么要做
对于选定的时间它告诉我们线程被阻塞了 6.64 秒阻塞的原因是调用了一个系统调用 mach_msg2_trap 右侧又是一个回溯视图但这个回溯并不是最重要的回溯它不是某种集合它是导致线程阻塞的 mach_msg2_trap 系统调用的精确回溯函数调用显示为底部的叶节点其调用栈显示在上方调用栈告诉我们该系统调用是由于分配了一个 MLModel 而发生的而分配 MLModel 又是由于分配了一个 “ColorizingService”类型的对象而发生的该对象作为该 colorizing service 上名为“shared”的单例属性的一部分而被调用而 shared 又是由一个 body getter 中的闭包调用的如果我们双击该闭包就可以再次跳转到源代码查看器并找到调用该属性的代码这行代码看起来没什么问题对吧？让我们仔细看看
我们正在访问 ColorizingService 的共享属性并将其存储在局部变量中但这并不是毫无问题的因为共享属性会在第一次访问时创建共享的 ColorizingService 实例这反过来又会启动整个模型加载机制从而阻塞线程所以你可能会说： “让我们把它移到 ‘await’之后的 async 部分” 然而与直觉相反这并不能解决问题 “await”关键字仅适用于后续代码中的异步函数调用在我们的示例中 “colorize”函数是“async”的但“shared”属性不是因为它是 static let 属性所以在第一次被访问时它会被延迟初始化而这是同步发生的 await 关键字无法改变这一点所以同步调用仍会在主线程上发生我们可以用之前示例中的方法来解决这个问题将 shared 属性也设置为“async” 从而脱离 main actor 一般来说当你在其他地方等待线程的工作时这种情况是没有问题的然而阻塞线程的另一个常见原因是锁或信号量有关在 Swift Concurrency 中使用锁和信号量时应牢记的最佳实践和应避免的事项请观看我们在 WWDC 21 的讲座“Swift Concurrency：幕后”
在结束之前我想谈谈与阻塞主线程相关的另一个案例这是我们刚才查看的跟踪内容右侧是我们刚刚调查过的主线程阻塞的挂起但是在它的左边还有一些其他的情况主线程被阻塞了好几秒钟但是 Instruments 并没有将其标记为潜在的挂起这里主线程只是休眠了因为没有用户输入从操作系统的角度来看主线程的确被阻塞了但它只是在无事可做时不运行主要是为了节省资源一旦有输入它就会被唤醒并进行处理因此要确定阻塞线程是否是响应速度问题请查看 Hangs 工具而不是线程状态工具
因此主线程阻塞并不意味着主线程无响应同样 CPU 使用率高也不意味着主线程没有响应但如果主线程没有响应意味着它要么被阻塞要么主线程繁忙我们的挂起检测会考虑到所有这些细节并且只会标记主线程实际未响应的时间间隔并将其显示为潜在挂起如果你在本次讲座中只能记住一件事那一定是：无论你在主线程上做什么工作都应在 100 毫秒内完成以便随时释放主线程重新进行事件处理时间越短越好若想详细分析挂起 Instruments 会是你的最佳搭档请记住繁忙主线程和阻塞主线程之间的区别并记住挂起也可能是由主线程上的异步工作引起的要解决挂起的问题你需要减少工作或将工作转移到后台有时甚至两者都要做到而减少工作往往意味着使用合适的 API 来完成工作一般来说在优化之前应该先测量并检查是否真的出现了挂起当然有一些最佳实践但并发和异步代码也更难调试你经常会惊讶于为什么有的进程那么快为什么有的进程又那么慢祝你在发现、分析和解决所有挂起时玩得开心感谢你的观看 ♪ ♪

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    
    var body: some View {
        Image(uiImage: background.thumbnail)
    }
}

19:58 - BackgroundSelectionView with Grid

var body: some View {
        ScrollView {
            Grid {
                ForEach(backgroundsGrid) { row in
                    GridRow {
                        ForEach(row.items) { background in
                            BackgroundThumbnailView(background: background)
                                .onTapGesture {
                                    selectedBackground = background
                                }
                        }
                    }
                }
            }
        }
    }

20:03 - BackgroundSelectionView with Grid (simplified)

var body: some View {
    ScrollView {
        Grid {
            ForEach(backgroundsGrid) { row in
                GridRow {
                    ForEach(row.items) { background in
                        BackgroundThumbnailView(background: background)
                    }
                }
            }
        }
    }
}

20:26 - LazyVGrid variant

var body: some View {
    ScrollView {
        LazyVGrid(columns: [.init(.adaptive(minimum: BackgroundThumbnailView.thumbnailSize.width))]) {
            ForEach(BackyardBackground.allBackgrounds) { background in
                BackgroundThumbnailView(background: background)
            }
        }
    }
}

24:05 - BackgroundThumbnailView

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    
    var body: some View {
        Image(uiImage: background.thumbnail)
    }
}

24:59 - BackgroundThumbnailView with progress (but without loading)

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
        }
    }
}

25:26 - BackgroundThumbnailView with async loading on main thread

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = background.thumbnail
                }
        }
    }
}

29:59 - BackgroundThumbnailView with async loading on main thread

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = background.thumbnail
                }
        }
    }
}

31:41 - BackgroundThumbnailView with async loading on main thread (simplified)

struct BackgroundThumbnailView: View {
    // [...]
    
    var body: some View {
        // [...]
        ProgressView()
            .task {
                image = background.thumbnail
            }
        // [...]
    }
}

33:40 - BackgroundThumbnailView with async loading on main thread

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = background.thumbnail
                }
        }
    }
}

33:59 - synchronous thumbnail property

public var thumbnail: UIImage {
    get {
        // compute and cache thumbnail
    }
}

34:03 - asynchronous thumbnail property

public var thumbnail: UIImage {
    get async {
        // compute and cache thumbnail
    }
}

34:08 - BackgroundThumbnailView with async loading in background

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = await background.thumbnail
                }
        }
    }
}

38:52 - shared property causes blocked main thread

var body: some View {
    mainContent
        .task(id: imageMode) {
            defer {
                loading = false
            }
            do {
                var image = await background.thumbnail
                if imageMode == .colorized {
                    let colorizer = ColorizingService.shared
                    image = try await colorizer.colorize(image)
                }
                self.image = image
            } catch {
                self.error = error
            }
        }
}

39:00 - shared property causes blocked main thread (simplified)

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                let colorizer = ColorizingService.shared
                result = try await colorizer.colorize(image)
            }
    }
}

39:10 - shared property causes blocked main thread + ColorizingService (simplified)

class ColorizingService {
    static let shared = ColorizingService()
   

    // [...]
}

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                let colorizer = ColorizingService.shared
                result = try await colorizer.colorize(image)
            }
    }
}

39:25 - shared synchronous property after await keyword still causes blocked main thread

class ColorizingService {
    static let shared = ColorizingService()
   

    // [...]
}

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                result = try await ColorizingService.shared.colorize(image)
            }
    }
}

39:39 - shared synchronous property after await keyword still causes blocked main thread (+colorize function)

class ColorizingService {
    static let shared = ColorizingService()
   
    func colorize(_ grayscaleImage: CGImage) async throws -> CGImage
    // [...]
}

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                result = try await ColorizingService.shared.colorize(image)
            }
    }
}

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

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

章节

资源

相关视频

WWDC23

WWDC22

WWDC21

Tech Talks

WWDC20

WWDC19

WWDC16