Apple 性能团队在 WWDC26 实验室里说了什么

在 WWDC26，Apple 让自家五位 Power & Performance 工程师上镜头，进行了一小时的开发者现场问答，回答开发者真正会提出的问题：为什么空闲的 SwiftUI 画面仍会耗电、如何模拟一台自己根本没有的旧设备、以及上架 App 里最大的耗电错误究竟是什么。那些精心制作的会议告诉你某个框架如何运作；而 Group Lab 告诉你 Apple 自家团队如何使用它。本文整理出值得留存的实战指引。

关于来源的说明：Apple 发布这段实验室视频时并未附上字幕。我在本机用 Whisper 进行了转录，因此以下每一段实验室引述都是出自该转录的转述，而非 Apple 逐字稿。我依据实验室开场介绍中提到的姓名与职务，并从对话语境推断来标注讲者：Terry 负责性能、Yanni 负责 MetricKit、Kaspar 负责 Instruments、Kunal 负责 CoreOS Power、Marco 负责渲染管线，由 Cole 主持。¹凡是实验室指引触及 Apple 正式记载之处，我都会引用相关文档或对应会议并加以标示。

作为实验室大半建议基础的 untethered power-trace 工作流程，大约从 11:42 开始。

摘要

• 旧的 Objective-C MetricKit 接口正逐步淘汰：MXMetricManager 自 27.0 起正式标记为弃用（deprecated），新的指标与诊断类型仅在新版 Swift API 上推出。²³
• Xcode Organizer 现在提供 Metric Goals，这些基准取自你自己的历史记录，以及 Apple 判定与你相似的 App，涵盖启动、卡顿率、磁盘写入、电池、存储空间与 hitches。⁴
• 团队推荐的耗电工作流程是 Performance Trace 的 Power Profiler 模式：在设备上以 untethered 方式录制一段 .aar trace、分享到你的 Mac，再在 Instruments 中查看 CPU、GPU、显示与网络的耗电 lane。此功能随 iOS 26 推出，而非 iOS 27。⁵
• Apple Intelligence 的工作大多在 Neural Engine 与 Private Cloud Compute 上执行，因此受 CPU 限制的 App 工作往往能与之并行而不发生资源争用。请把后台工作切成小块，让系统能够暂停与恢复。¹
• 团队看到最大的耗电错误是遥测数据不足：开发者之所以优化错了对象，是因为他们从未测量过真正该测量的东西。¹

为什么一场实验室值得转录

Apple 录制的会议都是经过编写、排演与剪辑的；Group Lab 则完全不是。它是工程师即时回应一线开发者问题的现场，而那些答复带着实战经验的质地：那些战场故事、那种「我们常常看到这个」的模式识别、那些对于什么很困难的小小坦承。这种质地，正是精修过的会议会打磨掉的东西。

问题在于，Apple 发布这场实验室时并未附上字幕。为了能引述它，我把视频送进本机语音识别，这意味着专有名词与 API 拼写只能算是近似。在把每一项技术说法陈述为事实之前，我都已对照过 Apple 的文档或对应的 WWDC 会议，并把实验室的原话以清楚标示的转述形式保留下来。请把工程师的说法视为意图与优先级上的权威，并把引用文档视为细节上的正式依据。

现场数据的故事：MetricKit 正在重建

负责 MetricKit 的 Yanni 形容今年是这个框架非常重要的一年，并描述了一次以全新 Swift-first API 为核心、从头打造的重建。他给出的动机是：Swift API 是为 Swift concurrency 而建，并针对新的数据粒度而设计，让开发者不只拿到每日的指标报告，还能取得更短区间内更细的拆解。关键在于，他指出新的诊断与指标类型仅在新版 API 上推出，他把这一点定调为真正该迁移的理由。¹

Apple 的文档佐证了这个说法中更尖锐的一面。MXMetricManager——自 MetricKit 推出以来开发者一直使用的入口点——如今已正式弃用：Apple 的参考页面标记它自 27.0 起弃用，并引导开发者改用 MetricManager。²WWDC26 会议 222 把这种排他性说得很明白：新的指标与诊断类型存在于新版 Swift API 上，不会回填到旧版。³如果你还在调用 MXMetricManager，你不只是停留在较旧的写法上；你已被切断于 Apple 日后新增的一切之外。

实验室也带出一个反复出现的困惑：现场数据从何而来、又该如何解读。Kunal 与 Yanni 把界线划得很清楚：Instruments 提供你在自己桌前对单一设备的深度本机剖析，而 Xcode Organizer 与 MetricKit 则提供来自真实设备上真实用户的汇总现场遥测。两者常常彼此矛盾，而这正是重点所在。Kunal 描述了一些开发者，他们追着一个能在 Instruments 里重现的卡顿不放，而 Organizer 却显示真正最常见的卡顿成因完全是另一回事——某种在桌前永远重现不出来的东西。¹

Organizer 这一侧的新杠杆是 Metric Goals。Kunal 把它标举为他最希望开发者在离开 WWDC 之前先试试的单一功能。会议 258 说明了它的内容：这些是 Organizer「根据你的 App 与其他 App 之间的技术与功能相似性」推导出的建议目标，再结合你自己的历史基准，横跨启动时间、卡顿率、磁盘写入、电池、存储空间与 hitches。⁴实验室用贴近人的方式描述了它的价值。Cole 描述了一位开发者举着一款视频 App 问道：它偏高的耗电是个问题，还是整天播放视频本来就得付出的代价？在 Metric Goals 出现之前，没有人能回答。如今 Organizer 会把你与相似 App 相比，并给你一个可据以推理的基准。¹

还有一条现场数据的卫生守则被提了出来，值得明白说出，因为开发者一再犯错：别自行打造启动计时器。实验室提到有开发者去查看内核 API 中的进程创建时间，并把它当作启动的衡量基准。Yanni 的回应是，MetricKit 与 Organizer 刻意不那样测量启动；它们测量的是用户真正感受到的那段区间。Apple 的文档确认了这个定义：启动时间是「用户点按你的图标，到你的第一个画面被绘制出来之间的毫秒数」，于静态启动画面之后开始计算。⁶你自己的计时器看不到点按的那一刻，因为当下你的进程根本还不存在。Apple 的工具看得到，而且不会为你的 App 增加任何测量开销。

团队真正推荐的耗电工作流程

实验室里最有用的程序性建议，是关于如何抓出那些在你桌前永远不会出现的耗电问题。Kaspar 与 Kunal 一再回到同一个工作流程：untethered trace。

用 Kaspar 的说法，其运作机制是：你与 Instruments 断开连接，在设备上录制一段可持续数小时的 trace，接着把文件分享到你的 Mac，稍后再在 Instruments 中打开分析。好处在于真实世界的条件：你四处走动、经历真正的移动网络切换、让设备变热，并捕捉到实际发生的状况，而非在受控桌前工作会话中发生的状况。Kunal 指出，这是抓出某一类特定 bug 的途径——也就是在不该调度时被调度的后台工作——而当你连着线盯着看时，这类 bug 是看不见的。¹

这个工作流程就是 Performance Trace 的 Power Profiler 模式，而它的来历值得说清楚：它是来自 WWDC25 的 iOS 26 功能，并非 iOS 27 的新东西。Apple 将其记载于「Measuring your app’s power use with Power Profiler」。你在「设置 > Developer > Performance Trace」中启用它，通过 Control Center 控件触发，把生成的 .aar 文件分享到 Mac，再在 Instruments 中查看按子系统拆解、横跨 CPU、GPU、显示与网络 lane 的耗电。⁵实验室把它呈现为他们推荐的首选工具，而非 27 的头条功能。（今年真正的新成员是 lookback collection 工作流程与 metalperftrace 这个 macOS CLI，我在 Metal 机器学习一文中已介绍过。它们是用于不同任务的不同工具；别把它们混为一谈。）

耗电讨论中另有两项技巧值得留存：

• 以 Low Power Mode 作为弱设备的替身。Terry 为那些只拥有新硬件、却需要了解 App 在旧硬件上感受如何的开发者，提供了一个诀窍：开启 Low Power Mode。它会放慢 CPU 以节省电池，从而让那些你原本只会在较旧设备上看到的问题浮现出来。他补充说，这同时也是良好的一般优化做法，因为许多用户会主动使用 Low Power Mode，而你的 App 在那种情况下仍应感觉良好。¹
• 以 Device Conditions 进行热与网络模拟。实验室反复提到一个「condition inducer」，用来强迫 App 进入升高的热状态或劣化的网络连接。Apple 对这项功能的正式名称是 Device Conditions；讲者本人也不确定它在 Xcode 27 中位于何处。它过去一向位于 Devices 窗口中，未来可能会并入 Device Hub。实验室讲者很谨慎地说明它做什么、不做什么：它人为地诱发高温设备的节流行为；它并不会真的把硬件加热。因此你可以观察 App 在热压力下的表现——更多 hitches、更多 hangs——而不必把手机烤熟。¹

还有一条不只出现一次的铁律：绝不要在 Simulator 上剖析。Kaspar 指出，Simulator 跑在你的 Mac 上，因此无论你选择哪台设备，它的性能都无法告诉你任何关于设备性能的事。请用实体设备进行剖析，并依靠 MetricKit 与 Organizer 的现场数据，去覆盖那些你买不齐的设备多样性。¹

性能分流：热管理、AI 资源争用与切块工作

当问题转向分流策略时，有三项指引格外突出。

热管理战术手册。一位开发者问到一款在户外、直射阳光下使用的 ARKit 与 Metal App，设备会持续发热。Kunal 的回答从 API 切入：监听 ProcessInfo.thermalState，当它攀升时就调降体验。¹面板提供的具体杠杆是：请求更轻量的网络资源，让设备花更少时间解码与解析；把较丰富的动画换成较简单的；并在压力下调降帧率或渲染分辨率。Kunal 指出，系统在较高的热状态下本就会节流动画与显示帧率，因此部分缓解是自动发生的，而你再在其上叠加自己的措施。Marco 对此的结语是：推送较少像素就是较少工作，而且「热力学是绕不过去的」。你能控制 App 的运算；你控制不了物理——所以就在属于你的那一块上狠狠优化。¹

Apple Intelligence 的资源争用模型。有个一针见血的问题问道：当系统忙于 Apple Intelligence 的工作时，iOS 27 如何排定 App 后台工作的优先级？Terry 的回答既令人安心又具体：许多 Apple Intelligence 功能在 Neural Engine 或 Private Cloud Compute 上执行，因此若你的 App 在使用 CPU，而某个 AI 工作负载在使用 Neural Engine，两者往往能并行而不争抢同一资源。他建议的防御性做法属于结构层面：把后台工作设置成一个个小块，让系统能够暂停与恢复，而不是一个庞大的单体任务，每次被打断都得从零重启。切块的工作即使在调度器没有照你期望那么频繁地执行你时，仍能持续推进。¹

StateReporting 的基数（cardinality）。新的 MetricKit StateReporting 功能让你能按应用程序状态切分指标，威力强大却也容易被误用。实验室给出一条关于基数的明确规则：不要上报频繁变动的精确值，例如列表中项目的确切数量。请改用分桶——小、中、大——这样你日后就能问「在这个大小范围内，性能有没有退步？」，而不必付出记录每一个不同计数的代价。Yanni 的例子是：一份 1,000 条的列表与一份 1,001 条的列表没有任何有意义的差别，所以记录精确数字纯粹是开销。请界定对你的分析真正重要的边界，并上报所属的桶。¹

特别在启动方面，面板汇聚到一个将各项分流建议串起来的心智模型：找出你绘制第一帧所需的最少数据，只加载那些，其余一切都延后。Terry 警告一个常见的失败：开发者分派出一大堆后台工作，然后阻塞主线程直到全部完成，这会在启动期间冻结整个 App。要判断这是不是你的问题，Kaspar 指向 System Trace 模板的主线程视图，被阻塞的主线程会在那里直接显现。面板还描述了 System Trace 会呈现线程优先级、抢占（preemption）以及一张 context-switch 直方图，不过我无法确认这些是否为 Instruments 27 已记载的功能，因此请把那当作实验室对工具的描述，而非规格。

工具笔记：Foundation Models instrument 与给新手的入门坡道

两则工具笔记为这场实验室收尾。

对于要推出 Foundation Models 功能的开发者，Kaspar 描述了 Instruments 这项工具如何从去年仅有基本 token 计数的指标，成长为一个完整的调试 instrument，可捕捉 prompts 与响应，并显示有多少 token 被缓存。¹综观 WWDC26 各会议的精确面貌是：Foundation Models instrument 会在 trace 期间从设备捕捉 prompt 与响应数据（会议 243，该会议亦注明捕捉可能包含敏感信息，因此在正式环境中是关闭的）。⁷而缓存 token 的计数则通过模型响应上的 usage API 取得（会议 241）。⁸这是两种不同的机制——一种用于 trace 时间轴，一种用于逐响应的计量——阅读你的数字时值得分清楚。

对于新手，面板对于从何处着手的看法是一致的。Marco 建议把 Time Profiler 搭配 flame graph 视图作为第一轮，因为 flame graph 会以可视化方式呈现某个调用栈耗费你多少成本，而不必让你在大纲里读数字。Kaspar 又补上 Top Functions 模式作为下一步——一份最沉重函数的扁平列表，让你一眼就能揪出祸首，而无须在层层嵌套的调用树中爬行。¹而面板最常重复的元建议是：先测量，再优化。Kunal 的说法是，最常见的陷阱是遥测数据不足，使开发者去优化那些带不来真正收获的区域。Terry 在启动与后台工作上的推论是：频率减半发送的网络请求，就是一笔免费的耗电收益。¹在深入任何单一子系统之前，请先看清全貌。

重点整理

给今天就要上架的 iOS 开发者： - 从 MXMetricManager 迁移到新版的 MetricManager Swift API。旧接口自 27.0 起弃用，而新的指标与诊断类型专属于新版 API。²³ - 打开 Xcode Organizer，对照相似 App 基准检查你的 Metric Goals：启动、卡顿、电池、hitches、磁盘写入与存储空间。⁴ - 别再用自己的计时器测量启动；MetricKit 与 Organizer 是从点按图标开始计算，而那一刻你的进程是看不到的。⁶

给性能与耗电分流： - 使用 Power Profiler 的 untethered trace（iOS 26，设置 > Developer > Performance Trace）来抓出那些在你桌前永远重现不出来的后台工作与真实世界耗电问题。⁵ - 在实体设备上剖析，绝不要在 Simulator 上，并以 Low Power Mode 作为你没有的旧硬件之替代。¹ - 监听 ProcessInfo.thermalState，并在压力下调降帧率、分辨率、动画丰富度与网络负荷。¹

给构建 AI 功能的团队： - 把后台工作切块，让调度器能够暂停与恢复；CPU 工作往往能与 Neural Engine 及 Private Cloud Compute 的 AI 工作负载并行而不发生资源争用。¹ - 把 StateReporting 的值分桶（小、中、大）；绝不要上报快速变动的精确计数。¹ - 对于 Foundation Models，阅读 Instruments 工具以取得 prompt 与响应的捕捉（会议 243），并从响应的 usage API 取得缓存 token 的计数（会议 241）。⁷⁸

这场实验室与本系列中更深入的探讨自然成对：MetricKit 与 StateReporting in iOS 27谈如何按 App 状态切分指标、Instruments 27 与 App 响应性谈新的 diffing 与卡顿检测工作流程，以及性能盲点谈为何现场数据与桌前剖析会彼此矛盾。完整的系列中枢是 Apple Ecosystem Series。

参考资料