在 iOS 27 中打造反應靈敏的相機 App

Apple 的相機效能團隊延遲了預覽輸出以外的所有作業，將相機啟動時間砍半：原本接近一秒的啟動降到大約一半，這是在實驗室燈板上實測得到的兩倍提升¹。背後的關鍵是 Deferred Start API，自 iOS 26 起可用，而它的核心原理直截了當——讓相機啟動感覺迅速的最重要因素，就是預覽畫面在螢幕上出現的速度有多快¹。

本文的切入框架是「一個 AVFoundation App 要做哪些事才能讓人覺得它瞬間就緒」，因為一台技術上已在運作的相機，和一台讓人覺得隨時可用的相機之間的落差，正是一塊倒下的骨牌會溜過去的那道縫隙。三場 WWDC26 議程涵蓋了這個主題：議程 303 談反應靈敏的啟動與持續拍攝、議程 304 談如何在不犧牲反應速度的前提下進行高解析度拍攝，議程 341 則談全新的方形 Center Stage 前置相機。它們透過同一套擷取工作階段架構彼此串連，因此採用其中一項，會讓其餘各項的導入成本更低。

TL;DR

• 四階段啟動流程（App 啟動、工作階段設定／啟動、輸出初始化、預覽串流）絕大部分時間都花在初始化各個輸出上。Deferred Start 會延後除了負責繪製預覽的那個輸出之外的所有輸出，在 Apple 的實驗室實測中把啟動時間砍半¹。
• 以 AVCaptureVideoPreviewLayer 為基礎的 App 只要重新針對 iOS 26 以上版本編譯，就能免費自動獲得 Deferred Start；採用 video data output 的 App 則必須改用手動模式，才能拿到同樣的提升¹。
• 延後 photo output 會加快預覽，卻不會加快首次拍攝，因此要搭配 AVCapturePhotoOutput 上的 isResponsiveCaptureEnabled，在處理就緒前先緩衝這張照片¹。
• iOS 27 新增的 Pro Video Storage 會預先配置一個系統層級的儲存集區，讓高資料速率的 ProRes 寫入維持確定性，而不會在檔案系統爭用下出現卡頓¹。
• Center Stage 前置相機（iPhone 17、iPhone Air、iPhone 17 Pro）是一顆方形感光元件，以前置 .builtInUltraWideCamera 的形式呈現；dynamicAspectRatio 可在不重建工作階段的情況下，從方形畫面裁切出任意長寬比，而 AVCaptureSmartFramingMonitor 則驅動 Auto Zoom 與 Auto Rotate²。

啟動流程分為四個階段

Apple 相機效能團隊的工程師 Jake 在議程 303 中逐一說明這四個啟動階段。

相機啟動會經歷四個階段，Apple 工程師 Jake 依序拆解了它們¹。第一是 App 啟動：連結器載入二進位檔、靜態初始化器執行、UI 場景被建立。第二是設定並啟動工作階段：初始化 AVCaptureSession、提交設定，以及啟動工作階段，這些都會消耗時間與系統資源。第三是每個 AVCaptureOutput 進行初始化，這段時間會隨著輸出的數量與其品質設定而增加。第四是預覽開始串流，畫面影格流向 App¹。

要讓這一切變快，工作得從 UI 開始。把啟動拆成兩個階段：顯示預覽所必需的資源，以及可以等到預覽運作之後再處理的資源¹。在 AVFoundation 的經典範例相機 App「AVCam」中，相機預覽和快門按鈕是使用者一啟動就立刻需要的唯二元素；影像縮圖井和模式選擇器可以稍後再淡入。這項原則的適用範圍不只 UI——任何在預覽繪製之前建立的資源，都會增加啟動時間¹。

工作階段本身是下一個施壓點。由於 AVCaptureSession 協調著每一個擷取物件，Jake 會在主執行緒完成 UI 設定後第一時間就建立它。但建立工作階段會阻塞主執行緒，因此要把它的建立工作分派到主執行緒之外，與 UI 場景設定平行進行，以避免卡住¹。同樣的注意事項也適用於 startRunning() 和 stopRunning()：兩者都是阻塞呼叫，在主執行緒上呼叫它們會讓 App 卡住¹。一開始就提交單一一份設定，而不是分次提交多份，因為每一次重新設定都會拉長啟動時間¹。

Deferred Start：兩倍的勝利

初始化各個輸出是啟動過程中最耗時的部分，而那一刻大多數輸出其實都是無用的負擔。要繪製預覽，App 只需要一個預覽圖層或單一輸出；movie file output 和 photo output 對第一張影格毫無貢獻¹。Deferred Start 正是利用這一點。它把輸出初始化延後到啟動完成之後，因此在第一張影格顯示之前，只有預覽輸出會進行初始化¹。

每個 AVCaptureOutput 和 AVCaptureVideoPreviewLayer 都帶有一個 isDeferredStartEnabled 屬性；把它設為 true 即可延後該輸出，並延後除了負責繪製預覽的那一個之外的所有輸出¹。決定延後作業何時執行有兩種模式。在自動模式下，系統會挑選最佳時機——通常就在預覽出現後不久——並觸發兩個委派回呼，讓 App 得以追蹤：初始化開始前的 sessionWillRunDeferredStart，以及完成後的 sessionDidRunDeferredStart¹。重新針對 iOS 26 以上版本 SDK 編譯的 App 會預設採用自動模式，automaticallyRunsDeferredStart 已經設為 true¹。

// Automatic mode — defer everything but the preview layer
session.beginConfiguration()
session.automaticallyRunsDeferredStart = true      // true by default on iOS 26+ SDK

photoOutput.isDeferredStartEnabled = true           // defer the photo output
// videoPreviewLayer renders preview, so it is NOT deferred

session.commitConfiguration()
session.startRunning()                              // call off the main thread

手動模式則把控制權交還給 App。把 automaticallyRunsDeferredStart 設為 false，先完成任何必須優先處理的啟動工作（讀取偏好設定、建構非關鍵的 UI），再呼叫 runDeferredStartWhenNeeded() 告訴系統可以繼續¹。手動模式對某一種架構特別重要：以 AVCaptureVideoDataOutput 繪製預覽的 App。Deferred Start 不會自動套用到 data output，因此這類 App 必須採用手動 Deferred Start 才能取得同樣的啟動提升，通常會在第一張影格呈現之後才觸發（Jake 透過 CAMetalLayer 來追蹤呈現時機）¹。

Apple 在實驗室燈板上驗證了這個結果，比較兩支拍攝逐漸擴大的 LED 圖樣的手機。啟用 Deferred Start 的那支在紅色與綠色 LED 都還亮著時就捕捉到了圖樣；沒啟用的那支則要等綠色 LED 幾乎都已熄滅後才完成啟動¹。計時來看，未啟用 Deferred Start 的啟動接近一秒；啟用後，啟動時間砍半，提升達兩倍，而複雜的擷取工作階段提升幅度甚至更大¹。

把破壞性的變更批次處理，讓物件圖只重建一次

啟動流程中那條「單一設定」的紀律，背後有一套機制，由 WWDC26 實驗室專家小組中的一位相機工程師講清楚了。AVCaptureSession 協調著一張由擷取物件構成的物件圖，每當您設定一個會迫使產生破壞性變更的屬性，工作階段就會重新解析這張圖⁵。重新設定通常意味著一次更動不只一件事，例如從照片模式切換到錄影模式，或把使用中的格式降到較低解析度，因此分別逐一設定每個屬性，會讓物件圖在每一步都重建一次⁵。把整個批次包進 beginConfiguration() 和 commitConfiguration() 之間，物件圖就只會在提交時恰好重新解析一次，無論這個批次裝著一項變更還是二十項⁵。這位小組成員把這一對方法比喻成一筆銀行交易：beginConfiguration() 開啟交易，提款和存款都維持在待處理狀態，而 commitConfiguration() 把它們一起結清⁵。

Deferred Start 還能和另一個啟動前的調控手段乾淨地組合在一起。小組確認 Deferred Start 與 prepared-photo-settings 陣列（AVCapturePhotoOutput 上的 setPreparedPhotoSettingsArray(_:completionHandler:)）彼此正交且互補——一個延後輸出就緒、讓預覽先出現，另一個則預先配置最壞情況下的靜態照片管線資源，兩者可組合而不衝突⁵。

快速預覽不等於快速拍攝

延後 photo output 有一個值得直說的陷阱：預覽會早很多開始，但首次拍攝的時間並沒有變短，因為系統仍必須先完成初始化被延後的 photo output，拍攝才能開始¹。預覽出現了，使用者按下快門，但那個瞬間還是錯過了。

解法是 AVCapturePhotoOutput 上的 isResponsiveCaptureEnabled。這個屬性會在啟動拍攝與處理真正開始之間加入緩衝，因此即使 photo output 尚未完全就緒，使用者也能捕捉到那一刻¹。在 Apple 的骨牌示範中，同時跑著反應靈敏拍攝與 Deferred Start 的那支手機，乾淨俐落地拍下了倒下的骨牌，對照組那支則完全錯失¹。這組搭配正是建議的模式：對品質型 photo output 採用 Deferred Start，維持啟動快速，再讓反應靈敏拍攝補上 photo output 完成初始化之前的那段空窗¹。

連拍式的高解析度拍攝

Apple 相機軟體團隊的工程師 Mohit 在議程 304 中於籃球場上示範 fast capture prioritization。

議程 304 把反應靈敏這條主線延伸到高解析度連拍。其機制是 AVCapturePhotoOutput 上的 isFastCapturePrioritizationEnabled，這是一個既有屬性而非新屬性：啟用後，系統會偵測短時間內的多張連續拍攝，並把照片品質從最高品質設定調整為平衡，因為平衡所需的拍攝與處理時間都較少⁴。新的部分隨作業系統一起到來。自 iPhone 16 和 iPhone 17 上的 iOS 27 起，系統還會稍後再以 deferred photo processing 處理那些平衡的快速拍攝——這條源自 WWDC23 的背景管線會在不阻塞下一次拍攝的情況下完成一張照片（與前述的 Deferred Start 啟動 API 是兩回事）⁴。在 Apple 的籃球示範中，把 deferred processing、反應靈敏拍攝和 fast capture prioritization 全部啟用後，同一個動作的差別就是一張被阻塞的拍攝對上五張反應靈敏的連拍⁴。

同一場議程也更新了高解析度的支援對照表。24MP 與 48MP 拍攝支援延伸到了 iPhone 16 Pro 的望遠相機和 iPhone 17 的超廣角相機，另有一個 18MP 選項僅存在於 iPhone 17 的 Center Stage 前置相機上⁴。優先順序設定決定了您能要求什麼：12MP 在三個優先順序層級都可用，單張 48MP 需要平衡或品質，而多張融合的 18MP 與 24MP 格式則因處理時間較長而需要品質優先⁴。正是 deferred processing 讓那些多張融合在反應靈敏的 App 中變得可行，因為繁重的工作在背景進行，不必與擷取工作階段共用記憶體⁴。

繪製預覽：圖層對上 data output

有兩種輸出可以驅動預覽，而這個選擇決定了您還得額外做多少事。AVCaptureVideoPreviewLayer 會原原本本地顯示相機所見，App 端不需要做任何逐影格的工作：它會自動處理 HDR 色調對應、維持低 CPU 與 GPU 負擔，並針對低延遲顯示進行調校¹。代價是它不提供任何逐影格的存取¹。（關於那套自動色調對應的 HDR 部分，AVFoundation HDR 與 Apple Log 一文深入說明了擷取與顯示管線。）

當逐影格處理才是重點時，AVCaptureVideoDataOutput 就是替代方案。它取代預覽圖層成為主要的顯示輸出，並讓 App 掌控影格的流動：逐影格的自訂 UI 疊加、Metal 整合、影格分析¹。代價是前面提到的手動 Deferred Start 採用，外加一條紀律規則：讓逐影格的工作保持簡短，以避免掉影格並維持流暢的體驗¹。當您只需要顯示畫面時，就用預覽圖層；當您真的要處理影格時，再動用 data output。

在壓力下維持效能

大多數相機開發都發生在桌前的受控環境裡，但人們會在炎熱的大晴天使用 App，而系統會隨著裝置升溫而降頻¹。有兩個成本 API 能讓 App 預見這件事。Hardware cost 會回傳一個介於 0 與 1 之間的值，代表工作階段所用硬體的占比；高於 1 表示系統無法支撐這份設定¹。這個成本會隨著相機數量、使用中的格式（1080p 對上 4K）、影格率，以及格式是否經過 binned 而上升。Hardware cost 假設的是某個格式的最高影格率，因此一個以 30 fps 運作於 60 fps 格式上的 App，應該設定影格率覆寫值以降低回報的成本¹。

System pressure cost 同樣回傳 0 到 1，代表目前狀態的成本，一旦越過 1，這份設定就無法持續¹。採用模式如下：提交設定後，先確認 hardware cost 維持在 1 或以下，再觀察 AVCaptureDevice 的 systemPressureState 並為其變化註冊一個處理常式¹。隨著壓力上升，處理常式會降低擷取裝置的影格率、節流 GPU 或 Apple Neural Engine 的工作量，並把 UI 工作降到最低¹。

Pro Video Storage：確定性的 ProRes 寫入

議程 303 介紹了 iOS 27 新增、專為高資料速率影片拍攝而設的 Pro Video Storage。

傳統的檔案系統 I/O 是非確定性的：系統得同時兼顧彼此競爭的作業、記憶體碎裂以及儲存裝置的耗損，因此寫入時機會有所變動¹。像 ProRes 這類高資料速率的拍攝，需要持續的高頻寬 I/O 才能在不掉影格的情況下錄製，而變動的時機正是最不該出現的特性。iOS 27 新增的 Pro Video Storage，透過追蹤並管理為高資料速率拍攝預先配置的儲存空間來解決這個問題。它是一項所有 App 共享的系統層級資源，並接入既有的影片錄製 API¹。

App 透過在 AVCaptureMovieFileOutput 上設定 usesProVideoStorage 來選擇加入，或在從 video data output 錄製時於 AVAssetWriter 上設定¹。接著儲存機制會處理配置與檔案 I/O，讓高資料速率編解碼器的寫入效能維持一致。採用順序如下：Pro Video Storage 是單例，因此要透過它的共享存取器取得並確認支援；建構 movie file output、工作階段、連線與所選格式；檢查 movie file output 上的 isProVideoStorageSupported；確認儲存機制並未忙於調整大小，或正在處理檔案的建立或刪除；然後啟用它並開始錄製¹。拍攝期間，錄製內容會寫入預先配置的集區，並在拍攝結束後移到最終位置¹。相機設定現在也讓使用者得以控制要配置多少儲存空間，remainingCapacity 方法會回報剩餘量，另有一個開啟設定的方法可從 App 把使用者帶到那個 UI¹。

Center Stage 前置相機是方形的

Apple 相機軟體團隊的工程師 Tracy 在議程 341 中介紹方形的 Center Stage 前置相機。

傳統前置相機的感光元件是 4x3 長寬比，把取景鎖定在手機方向上。iPhone 17、iPhone Air 和 iPhone 17 Pro 上的 Center Stage 前置相機，採用一顆方形影像感光元件搭配 95 度鏡頭，是任何一款 iPhone 前置相機中最廣的視野²。Apple 工程師 Tracy 點出了它的好處：方形外形讓使用者得以選擇任意長寬比，不必旋轉手機就能拍直幅或橫幅自拍，既能維持穩固的單手握持，也能保有置中、自然對視的影像²。

工作階段的設定是常規的 AVFoundation 做法³。建立一個 AVCaptureSession，以前置 .builtInUltraWideCamera 裝置類型把相機找出來成為 AVCaptureDevice，將它包進 AVCaptureDeviceInput，加入一個用於預覽的 AVCaptureVideoPreviewLayer 和一個用於拍照的 AVCapturePhotoOutput；工作階段會在相容的媒體類型之間隱式地形成各個 AVCaptureConnection²。

建構的基本元件是 AVCaptureDevice 上的 dynamicAspectRatio，自 iOS 26 起可用。設定這個屬性會從方形感光元件裁切出所選的長寬比，而不必重建工作階段或中斷預覽，因此切換是無縫的²。這個屬性在從 1280 到 4032 的方形格式上支援五種長寬比（3x4、4x3、9x16、16x9 和 1x1），但有一項限制：4032 的照片格式僅支援 3x4 和 4x3，因為唯有這兩者能保留最高解析度²。

// Tap to Rotate using dynamicAspectRatio
let discovery = AVCaptureDevice.DiscoverySession(
    deviceTypes: [.builtInUltraWideCamera],
    mediaType: .video,
    position: .front
)
guard let device = discovery.devices.first else { return }

// Find a format that supports the desired ratio
guard let format = device.formats.first(where: {
    $0.supportedDynamicAspectRatios.contains(.ratio4x3)
}) else { return }

try device.lockForConfiguration()
device.activeFormat = format
let timestamp = device.setDynamicAspectRatio(.ratio4x3)  // returns first-buffer timestamp
device.unlockForConfiguration()

每種格式都會公告它的 supportedDynamicAspectRatios，而設定長寬比後會回傳變更生效的第一張緩衝影格的時間戳²。這個回傳的時間戳不是裝飾用的：對影片錄製而言，它正是讓您結束一段片段、並以新的長寬比開始下一段的接縫。

Auto Zoom、Auto Rotate 與感光元件補償

AVCaptureSmartFramingMonitor（iOS 26 以上版本，從相機取得）座落在 dynamicAspectRatio 之上，驅動 Auto Zoom 與 Auto Rotate²。這個監測器會根據自動的臉部與視線偵測，定期給出取景建議，每一則都帶有一個長寬比和一個縮放倍率供 App 選擇套用或忽略；由於它針對的是照片拍攝，因此只有在 4032 照片格式使用中時才會提出建議²。它預設不建議任何東西，因此要設定 enabledFramings（設為全部的 supportedFramings，或選定的子集），再以 key-value 觀察 recommendedFraming 並套用每一則建議。順序攸關轉場是否平順：先設定長寬比，再設定縮放倍率²。監測器可在工作階段運作期間啟動；關閉自動取景則意味著取消註冊 KVO 並呼叫 stopMonitoring²。

這顆新感光元件帶來一個關於正確性的陷阱。較早期的 iPhone 前置相機把感光元件安裝在 Landscape Left，因此一張直幅自拍會以原生感光元件方向送達，並夾帶一個要求播放時旋轉 270 度的 EXIF 標籤。Center Stage 的感光元件則安裝在 Portrait，因此仰賴舊有旋轉值的 App 會把照片渲染成側躺或上下顛倒²。AVCapturePhotoOutput 預設透過感光元件方向補償來處理這點：它會實際旋轉 HEIC、JPEG 和未壓縮的已處理照片，並更新 EXIF 中繼資料，讓輸出像以前一樣落在 Landscape Left，使既有的旋轉邏輯得以繼續運作²。兩點注意事項：補償絕不會套用到 Bayer RAW 或 Apple ProRAW，而且 Apple 建議在關閉補償的情況下（透過 cameraSensorOrientationCompensationEnabled）進行測試以求最佳效能，確認方向仍維持正確²。

用於影片與通話的 Center Stage

對影片錄製而言，dynamicAspectRatio 的運作方式相同，但 QuickTime 的影片軌要求所有取樣共用相同尺寸，因此在拍攝中途更改長寬比會停止錄製²。使用 AVCaptureMovieFileOutput 時，錄製會在變更時自動停止；使用 AVCaptureVideoDataOutput 搭配 AVAssetWriter 時，setDynamicAspectRatio 完成時的時間戳就是切點，用來結束一段錄製並以新的長寬比開始另一段²。在這顆相機上，錄製還多了兩種能感知臉部的電影級穩定模式，cinematicExtended 和 cinematicExtendedEnhanced，它們會以維持主體穩定為優先，高於背景²。

視訊通話的路徑最簡單。對於使用 Voice over IP 背景模式的會議 App，Center Stage 已經啟用，使用者可從控制中心的「視訊效果」選單切換它²。沒有那個背景模式的 App 則直接採用 Center Stage API：它以每個處理程序為單位啟用（就像人像、攝影棚燈光和手勢那樣），因此先設定一個控制模式（cooperative 以允許 App 內按鈕，或 app），再把 isCenterStageEnabled 設為 true，取景就會讓每個人都保持置中²。還有一項視訊通話的升級預設為關閉：一種即時的低延遲穩定模式，透過把連線的 preferredVideoStabilizationMode 設為 lowLatency 來啟用²。

採用指引

這三場議程會回報一套分層的採用方式。

對每一個 AVFoundation 相機 App 而言： 先採用 Deferred Start。如果您以 AVCaptureVideoPreviewLayer 繪製預覽並重新針對 iOS 26 以上版本 SDK 編譯，自動模式就會免費開啟；請藉由確認 automaticallyRunsDeferredStart 為 true、且每個非預覽輸出都有 isDeferredStartEnabled = true 來驗證它¹。再搭配 photo output 上的 isResponsiveCaptureEnabled，讓快速的預覽同時也是一個可用的快門¹。

對 data output 與 Metal 管線而言： 您放棄了那份免費的勝利。請採用手動 Deferred Start，在第一張影格呈現後觸發 runDeferredStartWhenNeeded()，並讓逐影格的工作保持簡短¹。接上 systemPressureState 觀察，讓管線在發燙的裝置上能優雅地降級¹。

對 ProRes 與高資料速率影片而言： 在 iOS 27 上採用 Pro Video Storage 讓持續寫入維持確定性，錄製前要以 isProVideoStorageSupported 與忙碌檢查作為前置條件¹。

對 iPhone 17 / Air / 17 Pro 上的前置相機與自拍 App 而言： 探索前置 .builtInUltraWideCamera，透過 dynamicAspectRatio 提供 Tap to Rotate，並疊上 AVCaptureSmartFramingMonitor 以實現 Auto Zoom 與 Auto Rotate。除非您已實測出關閉的理由，否則就讓感光元件方向補償保持開啟，並記得它絕不會碰到 RAW²。

常見問答

Deferred Start 實際上能把啟動加快多少？

Apple 在實驗室燈板上實測約為兩倍：一個接近一秒的啟動，在啟用 Deferred Start 後降到大約一半，而複雜的擷取工作階段還能改善更多¹。這份提升來自在第一張影格之前只初始化預覽輸出，把其餘所有輸出延後到預覽出現之後¹。

我會自動獲得 Deferred Start 嗎？

如果您的 App 以 AVCaptureVideoPreviewLayer 繪製預覽並重新針對 iOS 26 以上版本 SDK 編譯，那就會：自動模式會開啟，且 automaticallyRunsDeferredStart 預設為 true¹。以 AVCaptureVideoDataOutput 繪製預覽的 App 不會自動獲得，必須採用手動 Deferred Start 才能拿到同樣的啟動提升¹。

為什麼即使用了 Deferred Start，我的第一張照片還是很慢？

延後 photo output 會加快預覽，卻不會加快首次拍攝，因為系統在拍攝能開始之前，仍會先完成初始化被延後的 photo output¹。請在 AVCapturePhotoOutput 上設定 isResponsiveCaptureEnabled 來緩衝這次拍攝，讓那一刻即使在 photo output 完全就緒之前也能被記錄下來¹。

我該如何在程式碼中找到 Center Stage 前置相機？

使用一個 AVCaptureDevice.DiscoverySession，在 .front 位置請求 .builtInUltraWideCamera 裝置類型；在 iPhone 17、iPhone Air 和 iPhone 17 Pro 上，Center Stage 前置相機就是以那個前置超廣角裝置的形式呈現²。接著，設定 dynamicAspectRatio 即可從方形感光元件裁切出任意支援的長寬比，而不必重建工作階段²。

舊的前置相機旋轉邏輯會在新感光元件上失效嗎？

有可能，因為 Center Stage 的感光元件安裝在 Portrait，而非過往的 Landscape Left，所以未經補償的緩衝影格會顯示成側躺或上下顛倒²。AVCapturePhotoOutput 預設會對 HEIC、JPEG 和未壓縮的已處理照片（絕不含 RAW）套用感光元件方向補償，因此既有的旋轉值會繼續運作，除非您停用 cameraSensorOrientationCompensationEnabled²。

Apple 生態系叢集

本文位於相機與擷取這條主線上：用於專業影片擷取與顯示的 AVFoundation HDR 與 Apple Log 工作流程；說明擷取在 App 架構中位置的 iOS App 的三個面；談承載預覽的 UI 層的 SwiftUI 是由什麼構成的；以及說明各項功能落在何處的 Apple 平台矩陣。樞紐是 Apple 生態系系列。關於 iOS 結合 AI 代理的脈絡，請參閱 iOS Agent 開發指南。

參考資料