为不良网络环境和温度条件而设计

晚上好

欢迎你们参加主题为 “针对恶劣的网络和 温度条件进行设计” 的大会 无论你是刚开始开发你的第一个 App 或者已经是一个 经验丰富的 App 开发者 我们都希望你的设计 具有世界级的体验 你的 App 有潜力 可以被数百万人 在许多不同的情况下使用 其中许多人没有使用 超高速的 4G 网络 一些人可能身处更炎热的环境中

我们做了一定程度的测试 但是你是否做了足够的工作 来了解那些用户 如何与你的 App 进行交互 如果你做了这些 你又是否提供了最好的体验

优秀的 App 即使在具有挑战性的现实环境中 也能很好地工作 而做到这一点在设计层面上是比较困难的 这就是为什么 我们在这里与你分享一些技巧 以及 Xcode 中全新的工具来实现它 我是 Alex Kara 我是 Ilya Veygman 我们致力于提升 iOS 系统的性能 使它能在现实世界中 良好 可靠且一致地运行 iOS 会对不断变化的网络 和温度条件做出反应 我们希望你的 App 能够同样做到这点 这样你就能以你设计的方式 体验你的 App

今天 我们要谈论 一些令人兴奋的内容 首先 我们将深入探讨 真实世界的设备条件 以及它们与设计过程的契合之处

接下来 我们将向你展示 如何使用新的和现有的开发者工具 改进 App 在不同网络连接下的行为

最后 我们将展示 一个全新的方法来优化 你的 App 在不同温度条件下的性能

我想让你想象一下 你如何以及在哪里使用 iOS 你不只是在家里 或办公室使用你的设备 你到哪里都带着它们 去海滩 去公园 在地铁上 在汽车上 进行长途旅行

这些地方可能伴随着 充足的阳光或热量 抑或是很弱的网络连接

现在 想象一下你的用户 他们很有可能 会在这样的环境中使用你的 App 你需要考虑如何将其 与你的开发 和测试环境进行比较

你可能正在办公室 或实验室中进行大部分 或所有的开发和测试 这些场所都具有 快速 可靠的网络连接 和气候控制 这无疑是一件好事 我们都想要一个 可控的工作环境

但这些情况 与世界各地的用户 在与你的 App 交互时 所面临的情况并不相同 这种差异可能会使得你 在看到用户 对你的 App 发出抱怨时 将其视为一次性的故障或特例 除此之外 这些 设备还可能进行多任务处理

你的用户可能正坐在 汽车的副驾驶座位上 一边播放音乐 一边通过无线网络连接到 CarPlay 并获知转弯方向 他们可能在咖啡店 给 iPhone 充电 并将其作为 Mac 的个人热点 或者 他们可能在 App 运行 3D 渲染 或其他复杂的后台处理时 使用 ARKit 通过摄像头识别 App 中的对象 这一切告诉我们 所有这些场景都能造成 你的设备更高负载地工作并获得热量

虽然你的 App 的功能 可能在隔离的测试环境中 运行得很好 但是你是否考虑过 在这些非常真实和常见的例子中 App 的性能可能会有所不同 对用户来说的 一个潜在痛点是 他们一直在试图与一个 只针对你的工作环境而设计的 App 进行交互 他们会对此有怎样的意见

我们已经注意到 App Store 上的一些评论 提到了在某些情况下 App 低于预期的性能 很棒的 App 但有时却不够好用 无论是在火车上 炎热的地方 还是在公路旅行中 这可能是你的用户 记住你的 App 的最重要的方式 他们可能不想在经历了 一场糟糕的体验后再次使用它 我们知道 当人们在阳光直射下 或者在隧道中使用手机时 他们希望你的 App 能够继续工作 我们也知道人们并不总是处于 最佳的网络环境中

如果你的开发条件并不具有代表性 或者是一个净室条件 那么这一点就很容易被忽略

所以我们想要 把这些情况考虑进去 我们希望你能够提供一个一致的 而不是低于预期的使用体验 你会在你的反馈中 发现身处 3G 网络环境中的用户 或者在你的 App 中发现一个问题 并注意到你的设备温度升高 你可能会认为 这些都是预期中的不良行为 但这些并不是极端情况 这些其实都是你和用户 将要面对的真实情况 为了更好地处理它们 你将需要正确的开发者工具 以及更好地应用它们的过程 让我们从网络连接开始 如果你将网络 用于 App 中的主要功能或后台工作 那么你可能已经在代码中决定 在所使用的网络类型中 进行相应的操作

如果网络通话时间过长 你可能会选择暂停

对于你的用户 他们中的一些人可能正在使用 3G 网络 如果他们的现实情况确实如此 那么即使下载需要更长的时间 他们也会很乐意等待下载完成

但你对于暂停的决定 并没有尊重他们的意愿 即使他们很乐意等待 但当他们发现 App 没有任何进展时 他们肯定会感到惊讶 这些决定累积起来 就会成为用户体验的一部分

当用户启动你的 App 时 他们不希望看到网络微调器 不是持续稳定地下载 就是完全地停止下载 这可能是你在 App 启动期间 进行网络调用时提供的体验 但如果你在 LTE 上 或者高速 Wi-Fi 上运行 App 时 即使是在进行性能测试 你也会觉得结果不错 一段时间后 特别是如果有其他的 App 能够在相同的条件下正常运行 那么你的用户可能会对这个界面十分厌倦 甚至完全放弃你的 App 你的 App 应该 在即使没有网络连接的条件下 依然可以正常启动 如果我想用一个 提前关闭的 App 获取重要新闻 我可能会注意到 在较慢的网络连接上 内容无法加载 如果我使用其他 App 并注意到它们不会在 同样的情况下失败 那么我会认为 这个 App 很难使用 或者有 Bug 如果你在测试中 标记出网络调用 或显式跳过它们 那么你的开发或测试就有可能跳过这种情况

因此 你应该查看一下 Xcode 的 Scheme 编辑器 看看是否设置了 用于单元测试的环境变量

当你将 App 作为单元 测试主机运行时 你可能会使用它来防止在 App 启动期间发生不必要的工作 对于单元测试 为了优化执行速度 你可以跳过一些工作 比如启动后台网络请求 但是你需要确保 你仍然在其他地方 处理这些情况

XC 测试将等到 App 委托 完成启动方法返回后 才开始运行测试 如果你在这里 使用环境变量 你需要检查你跳过的代码 对于单元测试的正常运行 是否确实不是必需的 如果你正在标记 或完全跳过网络调用 那么你需要确保 在开发过程的 其他地方包含了这些情况 以及实际的网络类型 为此 我们需要考虑 什么才是一个好的测试模型 在本周早些时候的 测试和 Xcode 会议上 我们介绍了 Pyramid 模型 以及它是如何构建 可维护的自动化测试套件

一个好的测试模型平衡了 完整性 质量和执行速度 并由大量集中的 单元测试组成 这些地方可以进行优化 以获得快速的执行时间 因为我们想在这里隔离特性 所以在净室条件下 运行这些是没有问题的 你可能正在使用这些 来寻找函数回归

还有一些 针对 App 中离散类集的 集成测试 集成测试检查 App 的子系统 是否从用户的角度协同工作

由于这些测试结果 更紧密地反映实际的使用情况 因此它们可能会增加方差 因此 你应该准备好 更深入地分类失败原因 而不是仅仅认为 这些测试是不可靠的 最后 该套件还附带了 用户界面测试或 UI 测试 这些测试以一种 非常类似于用户与 App 交互的方式运行 App 在这里 你可以验证 App 的所有部分 都已连接起来 并与诸如网络的外部资源 进行了正确的交互 这就是最有代表性的测试 与此同时 这可能是你在结果中 看到最大方差的地方 正因为这样 你可能会更倾向于关注单元测试 这可能会导致 你对 App 的行为 产生错误的安全感

如果应用得当 这个测试模型可以让你全面地了解 App 的代码库是如何工作的

这对于测试覆盖率非常好 但是你需要注意 在集成和 UI 套件中 可能遗漏的测试

将你的注意力 完全放在单元测试上 意味着在净室条件下测试 虽然这有助于你找到回归 但是也可能导致你忽略了 你可以为用户的实际行为 所进行的改进 人们很容易养成 净室测试的习惯 因为它给了我们许多 我们喜欢看到的测试品质 可重复的结果 低方差 这些都意味着 测试片的减少 我们希望你的 App 的 功能和性能优势 能够转化为现实的情况 因此你将需要 具有这些特性的 正确的开发工具

方差可能是反映现实的一个结果 与你在测试和分类 源代码中那些 棘手的边界情况时相比 它应该得到同样的关注

当你将 Pyramid 模型 应用于开发工作流的不同部分时 你将找到正确的位置 创建为你和你的团队工作的质量检查点 比如确保在你合并之前通过 所有的单元测试 这样你就可以尽早找到回归

尽管集成测试和 UI 测试 可能不适合作为早期检查点 因为在实际环境中 会产生方差 但它们必须在你的进程中 存有一席之地 如果你确保 你在适当的时间运行它们 你将能够描述 你的 App 的行为 并找到你可以 进行的改进和行为进步 现在 我们已经为 实际情况测试腾出了空间 你可以回头继续并将注意力集中在 你之前可能跳过的测试上 比如网络测试

我们已经看到了一些 实现这一点的方法 比如使用定制路由器来调节网络基础设施 如果处理得当 这确实可以取得成功 但是这也很难操作 尤其如果你是一个 刚刚开始起步的开发者 即使你有一个良好的测试模型 和对分流的强烈关注 为了进行现实情况的测试 你也需要优秀 可靠的开发工具 因此 如果你使用 macOS 开发你的 App 我们建议你下载和使用 Network Link Conditioner.prefPane 你可以使用它 来改变网络类型 并查看你的 App 在 3G 或 EDGE 等网络下的行为

在 iOS 上 Network Link Conditioner 可以在 你的用于开发的设备中的 开发者设置菜单中找到 从这里开始 你可以在争用预置 或更具代表性的预置之间更改网络类型 并为它们设计 App 而不需要设置或更改 网络基础设施 这是一个可靠 且可重复的设备支持的方式 从而在不同的网络环境中运行你的 App

如果你有自定义需求 还可以为你想要设计的 特定类型的带宽 包丢失和延迟 创建自定义预置 这对于检查 App 在特定环境中的行为非常有用 在 Xcode 11 中 我们为设备和模拟器窗口 提供了在各种不同的网络类型中 激活的功能 这样你就可以轻松可靠地启动 并在设计过程中 考虑到现实情况 你将在窗口的下方 看到一个新的设备状态部分 在这里 你可以让你的设备处在 更具代表性的状态

如果你想要一个网络链接 你将看到以往的所有网络类型 以及新的配置文件 以便你改变网络质量

这意味着你可以 让你的设备和 App 在 2G 或 EDGE 3G 或 LTE 或者不同类型的 Wi-Fi 网络上运行 你甚至可以选择 网络类型的质量 比如好的 EDGE 网络 或普通的 3G 网络 人们确实在使用这样的网络连接 所以我希望你能发现 能帮助你查看 App 如何与用户交互 并寻找可以改进行为的地方

一旦选择了 要激活的条件 轻点 “设备” 窗口中的 “开始” 这些条件是系统范围内的 所以你会发下 一切都开始做出不同的反应 包括你的 App

在具有激活条件的设备上 你将看到一个新的 灰色状态指示器

尽管激活一个网络类型 会影响整个系统 但是网络的 UI 指示器 将保持不变

你还应该知道 激活的网络条件 将是你的网络类型的上限 你的网络性能将与现实情况下 同等网络类型的性能持平 并无法得到提升

在设备中 如果你点按灰色状态图标 你将看到一个提示符 指示活动条件 以及一个选项来停止该条件 如果你的设备 与 Xcode 断开连接 则该条件将自动停止

为了向你展示 如何使用网络连接设备条件 来查找 App 中可以改进的地方 我将请 Ilya 回到舞台 我们经常预期我们的 App 会在一个略差的网络连接中 表现失常 但重要的是 你要问问自己 这种行为是否真的有必要那么糟糕 它能得到改善吗 在不利或不同的网络环境下 我们是否能取得一些进步

这里有一个令人兴奋的示例 App 我们可以启动它 来查看在理想的实验室条件下 网络连接的基本行为

这个 App 探测 我们为这个演示设置的端点 从而查看连接需要的时间 我们看到这个连接 平均需要 150 毫秒 我们可以把这想象成类似于 要求安全登录 或从网站上传输内容 这看起来很棒 如果我们在实验室做 UI 测试 我们会假设一切都很顺利 没有问题 现在 让我们看看 如果从 Xcode 设备窗口中打开 Network Link Conditioner 会发生什么

在本例中 这是一个普通的 3G 网络连接

让我们看看现在发生了什么

当我们再次运行探测器时 我们看到它花费的时间更长 在本例中 平均超过 750 毫秒 这并不令人惊讶 毕竟 3G 网络 比 LTE 或 Wi-Fi 等网络要慢

要注意的重要一点是 正如我们之前所说 这是许多用户将看到的实际网络 我们能做些什么 来改善他们的这种体验呢 你可能注意到 在运行探测器按钮上面有两个开关 在 Optima 60NS 和 TLS 1.3 中是禁用的 让我们打开它们 看看会发生什么 当我们打开它们 并再次运行探测器时 我们看到了一个立即的改善 大约快了 33% 在激活 Network Link Conditioner 后 简单地测试这个 App 我们明确地看到 当我们使用 3G 等 速度较慢的网络 且与 Wi-Fi 或 LTE 等速度较快的网络相比时 出现了显著的性能损失

这告诉我们 我们应该考虑这些新特性 并使用它们 来主动地提高 在现实的网络条件下的性能

在运行 Network Link Conditioner 之后 我们注意到一些 以前并没有发现过的 低于预期的性能 你可以做出一些设置 来积极改善整体的体验

首先 设定合理的超时 也就是说 当你停止进程时超时 而不仅是当进程需要太长时间时超时 正如我们之前所说的 如果你的用户使用 3G 网络 你愿意等待更长的时间来加载内容 对他们来说 任意的超时将是更糟糕的用户体验 除此之外 一定要使用 HTTP/2 并尽可能避免可达性检查 相反 只要尝试使用网络 并尽你所能确保你的 App 在尽可能多的网络条件下 运行良好 要了解更多关于相关的改进 请参见去年 WWDC 的这两个会议 以及本周早些时候 “网络进展”的 1 和 2 两部分内容

接下来 调节 你需要开始考虑你的 App 中 实际的网络使用情况 你需要使用 网络连接设备条件 来描述你的 App 在这种使用情况下的行为 并问问自己 这种性能是不是可接受的 是否有机会更好 我们建议你至少使用 3G 网络进行测试 并寻找你可以进行的改进 你需要改变网络类型和它的质量 来查看你是否仍然 提供了良好的体验 然后通过将此作为 集成和 UI 测试运行的一部分 来锁定这些性能优势 现在 我想谈谈 温度的变化

人们喜欢在阳光明媚的日子里 在户外使用电子设备 他们可能会在咖啡店 当 iPhone 进行无线充电时 使用个人热点

在这些情况下 设备会开始升温 这是正常的行为 一些热能的情况 会导致 iOS 设备 为了调节温度 而改变其行为或性能 温度的变化有 很多原因 无论是 设备做了更多的工作 还是直接暴露在阳光下 等环境影响 抑或是其他因素

所有这些都是正常的场景 iOS 子系统 会对温度变化做出反应 以调节这些变化造成的影响 然而 你的 App 却不能 在不断变化的温度下 正常地运行 你也并未解决这个问题

当某些阈值 被超过时 例如 如果设备长时间 被留在炎热的汽车中 用户可能会看到这个温度警告界面 此时它们就不能再 与你的 App 交互了 发生这种情况的部分原因是 为用户提供 必要时拨打 紧急电话的关键能力

系统正在竭尽所能 来限制它的能量作用 这将影响热量和电池寿命 你的 App 也是系统的 后台常驻 App 你也同样需要考虑它的能量作用 这是很重要的

为此 当你 处于不同的热状态时 你可以开始动态地改变 你的 App 的行为 通过防御性的设计 你可以通过关闭后台工作 来减少你的 App 的能量作用 这会造成更高的热状态

你可以注册 热状态变化通知 查看设备 向你的 App 报告的状态 并考虑正常的场景 比如设备升温 因为系统知道它应该 如何应对温度升高 但你的 App 知道 更多关于它正在做的工作的细节 以及这些工作应该如何 在保持良好体验的同时 对更高的热状态做出反应

那么 让我们来看看 你们可能会看到的这些热状态

在标准状态下 设备处于正常的工作温度 不需要你的 App 采取任何纠正措施 在第一种状态下 我们建议你主动 启动一些节能措施 这样你就不会显著造成 继续的能量整体增长

当 iOS 看到热状态处于 Fair 时 我们开始暂停 照片分析等可自由支配的后台工作 当设备报告了 Serious 的热状态时 系统性能将受到影响 你的 App 应该开始采取 更强的节能措施 减少 CPU 使用 图形和 I/O 这时 你应该使用 低质量的视觉效果 我们对系统采取的一些措施 包括降低 ARKit App 和 FaceTime 的帧率 以降低它们的整体强度 如果用户正在 从 iCloud 备份中恢复 他们会发现 iCloud 会暂停到这个状态 直到设备冷却下来

在热状态 Critical 时 你的 App 应该停止使用 相机等外部设备 如果你的 App 出现在 电池用量列表的首位 用户甚至可能会 考虑删除你的 App 你的 App 应该与系统一起 对这些变化做出动态反应 这样你就可以 在保持低能耗的同时 继续保持良好的体验

要了解更多状态案例 以及我们的建议 你可以查看我们的文档 Ilya 现在将为给你们展示一个例子 如何对这些状态 做出动态反应 我将向你们展示 一个示例 ARKit App 它基于我们现有的 示例代码的修改版本 能够在增强现实中处理 3D 交互 和 UI 控件 当我在 Apple Park 散步时 它也在做一些 繁复的后台工作 在这里 你可以看到 App 正在 Nominal 热状态下运行 你可以看到 红色的焦点方块 变成了实体 找到一个表面 让我放下一把漂亮的椅子和一盏灯 然后坐在椅子上面看书 现在你可以看到 相机的移动非常平稳 一切都十分正常 一切都如常地运转 让我们再看一下这个 App 但是现在我已经在外面 待了很长时间了 我一直坐在阳光下 外面很炎热 设备也开始升温

你会注意到两件事 首先 帧率不如 以前那么好了 其次 尽管我几乎是直接对准地面 但焦点方块 却没能找到一个表面 这对你的用户来说 不是一个很好的体验 而且可能会让他们感到有点沮丧 那么 我们能做些什么呢

首先 你需要注册 ProcessInfo.theremalStateDidChangeNotification

当你收到热状态更改通知时 读取实际的热状态 然后做出相应的反应 根据你的状态 你应该启用或禁用某些特性 以确保平滑的性能 或者你认为重要的任何度量 这是一个如何注册热状态 然后读取热状态的例子 你应该如何选择 对热状态作出反应

在这个场景中 我在 Nornimal 和 Fair 热状态下 启用了所有特性 在这个例子中 我打开了人脸跟踪 人物分割 和运动模糊 当热状态增加 Serious 时 我禁用人脸跟踪和帧语义 但我留下了运动模糊 在 Critical 时 我会关掉所有特性 现在我们已经 对热状态做出了反应 让我们再看看这个 App 在同样的场景下工作得怎样 我们同样在外面待了很长时间 但是能看到它现在好多了 焦点方块能够找到一个表面 我可以像以前一样 放下我的椅子和台灯 我也可以读一会书 编写防御代码 以及对热状态变化做出反应 确实很有帮助 但是你想提前知道 它是否像你预期的那样工作

一般来说 我们可以提前测试 App 在不同温度下的性能 换句话说 你应该测试你的防御代码

但是为了做到这一点 我们应该怎么处理呢

谢谢你 Ilya 问题是 不是所有人都能获得热成像

就像网络条件一样 我们认识到 对于验证 App 行为的挑战 以及现有方法中 存在很大的方差 我们注意到 人们正在使用一些 我们不推荐的方法 比如运行一个虚拟 CPU 负载 使设备升温 扔掉第一个小时的结果 然后在设备高温的时候分析 App 行为 我们一直在努力为此 提供一个开发工具 我们提出了一种可靠的方法 来改变设备上报告的热状态 而不需要对设备 进行物理加热 同时仍能保证其安全使用 我们在 Xcode 11 中 将这种方式构建到设备条件中

从相同的设备 和模拟器窗口中 你可以激活高温条件 使你的设备 达到不同的热状态 而不需要达到 物理意义上的温度条件 现在 你可以快速 轻松地 让你的设备报告 处于 Fair 的状态 来测试你的主动节能措施 热状态 Serious 来检查你是否可靠地 降低了你的资源使用和能量作用 热状态 Critical 来查看你对外部设备的使用 是否真的停止

运行其中一个 会使设备的行为完全像 它真的处于那个热状态一样 但在你开始使用这些之前 你需要知道 它们在你的设备上是如何工作的 Ilya 谢谢你 Alex 我将向你展示 更多关于底层的情况 你可以在这里看到一个图表 它代表了设备的 实际热状态 如果有的话 活动状态 以及设备的 实际触觉温度 它用右上角的温度计表示 想象一下你桌上的基准设备 它处在室温条件下 你没有任何激活条件 并且你已经有一段时间没有使用它了 在这里 热状态是 Nominal 如果你现在 激活 Serious 热配置 设备将随着时间的推移 从 Nominal 经过 Fair 最终达到 Serious 这个过程需要几秒钟 就像在现实生活中 如果你订阅了热状态通知 你会在达到 Fair 和 Serious 状态时 收到通知 现在 有两件重要的 事情需要注意 首先 你的设备实际上 并没有因此而升温 或改变温度 其次 这并不能 固定你的热状态 它的作用就像基准板一样 让我来解释一下这是什么意思 假设你的设备 处于这种状态 你运行了一些繁重的计算 或者你只是把它放在太阳下一段时间

基础温度实际上升高了 这台设备摸起来升温了

不管原因是什么 热状态也会从 Serious 增加到 Critical

这是一种预防措施 以确保你的系统仍然安全运行 即使你在这个热条件下 进行非常繁重的测试 如果你停止使用你的设备 或让它冷却下来 热状态将回到 Serious 并保持在那里 直到你撤销设置的条件 在这之后 设备将从 Serious 经过 Fair 最终降到 Nornimal 在所有这些情况下 你都将收到热状态用户通知 在 Xcode 11 中 这个热状态信息 在调试导航器中的能量计中是可见的

这里有两条热状态轨道 都位于能量作用区域的底部 最底部的轨道 显示设备的实际热状态 颜色编码便于分辨 在这里 你可以看到热状态 随着激活条件的变化 先上升然后下降 你可以看到 在这个场景中 每个方向都花费了大约 10 秒的时间

如果存在 则顶部轨道显示活跃的热设备状态

为了向你展示 更多关于 Xcode 的调试和优化 以及可以使用的工具 我将有请 Jay 上台

大家好 我是 Jay 我是 Core OS 中 能量技术团队的一员 我将向你展示 在设备受到温度限制时 App 的行为 以及你可以对此做些什么

作为演示 我们将使用一个 Fox 2 App 的修改版 它是几年前为 SceneKit 公开发布的示例

让我们开始吧 我有一个设备 在没有任何活跃的热条件下 运行这个 App 让我们看看它是如何加载的

这是这个 App 的样子

首先 让我们看看 屏幕的左下角

那是 FPS 我们可以看到 FPS 一直保持超过 30 让我们看看这个 App 的细节 这款 App 的动画效果十分不错 让我们看看 App 内部的所有细节 细节十分丰富

如果你看 右边的绿色宝石 它上面有一个光源 阴影很大

如果你观察运动的物体 它们有光源从里面发光 它们投影在狐狸身上 也有很大的阴影 让我们看看熔岩 烟雾从里面冒出来 GPU 在背景融合方面 处理得很好 同时 还有很多 微小的火粒子迸射出来 这是一个很好的用户体验 用户非常喜欢使用这样的 App 如果你在运行性能测试 它们都是绿色的 让我们调整到一个热条件 看看会发生什么 我有另一台设备 在运行同样的 App 但处在 Serious 热条件下 我们看看会发生什么 我要切换到这个设备 现在 如果你 看屏幕的左下角 FPS 已经降到 17 我们几乎损失了一半的性能 如果你观察移动的物体 就会发现它们 不像以前那么顺滑了 如果你观察移动的平台 或移动的岩石 它们也不像以前那么顺滑了 我们能做些什么来解决这个问题呢

我们继续修改了 App 来监听热状态的变化

当热状态发生变化时 App 将动态地响应 并减少它所支持的功能 让我们看看它是如何工作的 我在顶部 有一个小的调试 UI 可以将它切换成静态或动态 现在我要将它切换为动态

如果你现在看屏幕底部 我们又接近了 20 FPS 场景看起来很像 但是我们去掉了一些细节 我们去掉了从熔岩中冒出的烟 我们减少了一些火粒子 但是正如你看到的 App 的响应仍然很好

这就是我们要找的 现在 让我们来看看 为了实现这一点我们必须做的代码更改

当你处于 Nominal 或者 Fair 状态时 我们不需要做任何事情 你可以在 App 上 启用所有功能 我们有 HDR 我们有景深 我们有柔和的阴影 我们也将后期处理设置为高

但如果达到了 Serious 状态 我们就要有所行动了 我们需要禁用 HDR 我们还将阴影从柔化变为斑点 我们还将后期处理设置为中等 当我们处在 Critical 状态时 还要进一步设置 Critical 是一种非常高的热状态 我们禁用了尽可能多的功能 我们禁用了 HDR 禁用景深 我们禁用了阴影 以及后期处理

所有这些都将有助于 保持 App 随时响应 现在 让我们看看一些 用来调节温度的工具

这是一个采取在 同一 App 上的 Instrument 堆栈 分为带有和不带有优化 它们都是在 Serious 热条件下被捕获的 让我们看看 FPS 轨道 这是显示在同一帧中的时间 我们来解码一下 当显示器显示一个帧时 GP 正在绘制下一个帧 CP 正在为后面的帧创建指令 如果不进行任何优化 GP 就无法 及时交付帧 显示器就会一直显示相同的帧 这就是卡顿的样子 这时你的 App 开始滞后 如果你注意到 在优化之后 帧之间的间隔是一致的 除了使用 Instrument 你还应该使用 Xcode 能量计 你应该把注意力集中在 你的 App 的平均能量作用上 能量作用越大 电池损耗越高 你的 App 导致 热状态上升的可能性就越大 如果你看没有优化的情况 我们有一个 非常高的能量作用 但伴随着优化的启用 我们就能够降低能量作用 这意味着 当设备运行该 App 时 该 App 不会导致 热状态上升

有请 Alex 和 Ilya 进行总结

谢谢你 Jay

如果你想了解更多 关于 Xcode 中的调试 以及其他 可以为你的开发过程 带来真实场景的内容 例如环境覆盖 请查看本周早些时候的这个会议

我们了解了 人们会在真实的环境下 使用你的 App 比如 3G 网络或高温状态 也了解了在这些情况下 提供真正可能的 最佳体验的重要性

以及一个典型的开发 和测试工作流 如何自然地引导你 进入净室条件 以避免片状的测试和高方差 我们了解了 在 Xcode 11 中新的设备条件 可以让你快速轻松地将 测试设备置于 不佳的网络或温度状态 这意味着你不再需要 等待一个小时让设备真正升温 也不再需要 扔掉某些测试结果 这是一种很好的方式 确保你正在设计的代码 以及它所带来的 所有优秀性能和特性 都能够转化为现实情况中 用户的实际体验

为了总结 请使用 Test Pyramid 模型 来组织你的自动化测试套件 并准备在你 将实际情况引入测试时 对结果进行分类 只跳过单元测试中 真正不必要的代码 这里有一个行动的号召

别忘了使用 Network Link Conditioner 一定要激活设备条件 查看 App 的行为 并添加测试运行 从而发现你可能错过的异常行为

我们再次建议你 至少使用不同质量的 3G 网络类型进行测试 查看你的 App 在 Serious 的 热状态下是如何工作的 我们非常兴奋地看到那些 你使用我们提供的设备条件 所进行的改进 我们也很想听听你的意见 联系开发者支持 或者在此会议之后 访问 Xcode 实验室 获取更多信息 请参见我们的会议链接 非常感谢你 我们希望你有一个开心的 WWDC 之旅 [掌声]