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。

參考資料