在 iOS 27 中构建响应迅速的相机应用

Apple 的相机性能团队通过推迟除预览输出之外的所有工作，将相机启动时间缩短了一半：原本接近一秒的启动降到了大约一半，在实验室灯板上测得两倍的提升¹。背后的关键是 Deferred Start API，从 iOS 26 起可用，其原理直截了当。让相机启动感觉快速的最重要因素，是预览帧出现在屏幕上的速度有多快¹。

这篇文章的切入点是「一个 AVFoundation 应用要做什么才能让人感觉即时可用」，因为相机在技术上已经运行与它让人感觉随时可拍之间的差距，正是一块倒下的多米诺骨牌所穿过的那道缝隙。三场 WWDC26 讲座覆盖了这一领域：session 303 讲响应迅速的启动与持续拍摄，session 304 讲在不牺牲响应性的前提下进行高分辨率拍摄，session 341 讲全新的方形 Center Stage 前置相机。它们通过同一套拍摄会话架构相互连接，因此采纳其中一项会让其他几项的实现成本更低。

TL;DR

• 四阶段启动序列（应用启动、会话配置/启动、输出初始化、预览流送）中大部分时间花在初始化输出上。Deferred Start 推迟除负责渲染预览的那一个之外的所有输出，在 Apple 的实验室测量中将启动时间缩短一半¹。
• 基于 AVCaptureVideoPreviewLayer 的应用在针对 iOS 26+ 重新编译后可免费自动获得 Deferred Start；使用 video data 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 在 session 303 中逐一讲解了这四个启动阶段。

一次相机启动会经历四个阶段，Apple 的工程师 Jake 按顺序逐一拆解¹。第一，应用启动：链接器加载二进制文件，静态初始化器运行，UI 场景被创建。第二，会话被配置并启动：初始化 AVCaptureSession、提交配置、启动会话，这些都会消耗时间和系统资源。第三，每个 AVCaptureOutput 进行初始化，这部分时间随输出的数量及其质量设置而增加。第四，预览开始流送，画面帧流向应用¹。

让这一切变快的工作从 UI 开始。把启动拆成两个阶段：显示预览所必需的资源，以及可以等到预览跑起来之后再加载的资源¹。在 AVFoundation 的经典示例相机应用 AVCam 中，相机预览和快门按钮是用户在启动那一刻唯一需要的元素；图像缩略图和模式选择器可以随后淡入。这个原则不止适用于 UI。任何在预览渲染之前创建的资源都会增加启动时间¹。

会话本身是下一个压力点。由于 AVCaptureSession 要协调每一个拍摄对象，Jake 会在主线程完成 UI 设置后立刻先创建它。但创建会话会阻塞主线程，所以应把它的创建调度到主线程之外，与 UI 场景设置并行执行，以免造成卡顿¹。同样的注意事项也适用于 startRunning() 和 stopRunning()：两者都是阻塞调用，在主线程上调用它们会让应用卡死¹。一开始就提交单个配置，而不要分多次提交，因为每一次重新配置都会延长启动时间¹。

Deferred Start：两倍的胜利

初始化输出是启动中最耗时的部分，而其中大多数输出在那一刻都是无用的负担。要渲染预览，应用只需要一个预览图层或单个输出；影片文件输出和照片输出对第一帧毫无贡献¹。Deferred Start 正是利用了这一点。它把输出初始化推迟到启动结束之后，因此在第一帧显示之前只有预览输出会被初始化¹。

每个 AVCaptureOutput 以及 AVCaptureVideoPreviewLayer 都带有一个 isDeferredStartEnabled 属性；把它设为 true 即可推迟该输出，并推迟除负责渲染预览的那一个之外的所有输出¹。决定推迟的工作何时运行有两种模式。在自动模式下，系统会挑选最佳时机——通常在预览出现后不久——并触发两个委托回调以便应用追踪：初始化开始前的 sessionWillRunDeferredStart，以及完成后的 sessionDidRunDeferredStart¹。针对 iOS 26 或更高版本 SDK 重新编译的应用默认采用自动模式，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

手动模式把控制权交还给应用。将 automaticallyRunsDeferredStart 设为 false，先完成任何必须优先进行的启动工作（读取偏好设置、构建非关键 UI），然后调用 runDeferredStartWhenNeeded() 告诉系统它可以继续了¹。手动模式对一种架构尤为重要：用 AVCaptureVideoDataOutput 渲染预览的应用。Deferred Start 不会自动作用于 data output，所以这类应用要采纳手动 Deferred Start 才能获得同样的启动提升，通常在第一帧呈现后触发一次（Jake 通过一个 CAMetalLayer 来追踪呈现时机）¹。

Apple 在实验室灯板上验证了结果，对比两部手机拍摄一个不断扩展的 LED 图案。启用了 Deferred Start 的手机在红色和绿色 LED 都亮起时就捕捉到了图案；未启用的那部直到绿色 LED 几乎熄灭才完成启动¹。计时来看，没有 Deferred Start 的启动接近一秒；启用后启动时间缩短一半，提升了两倍，复杂的拍摄会话提升幅度还会更大¹。

把破坏性变更打包，让对象图只重建一次

启动序列中「单次配置」的纪律背后有一套机制，WWDC26 实验室座谈中的一位相机工程师把它讲透了。AVCaptureSession 协调着一张由拍摄对象组成的图，每当你设置一个会引发破坏性变更的属性时，会话就会重新解析这张图⁵。重新配置通常意味着一次改动不止一处——从照片模式切换到视频模式，或把当前激活的格式降到更低分辨率——所以逐个单独设置属性会让对象图在每一步都重建⁵。把整批改动包裹在 beginConfiguration() 和 commitConfiguration() 之间，对象图就只在提交时精确地重新解析一次，无论这一批是一处改动还是二十处⁵。这位嘉宾把这对方法比作一笔银行交易：beginConfiguration() 开启交易，取款和存款都处于待定状态，commitConfiguration() 把它们一起结算⁵。

Deferred Start 还能与另一个启动前的手段干净地组合。座谈嘉宾确认，Deferred Start 与预设照片设置数组（AVCapturePhotoOutput 上的 setPreparedPhotoSettingsArray(_:completionHandler:)）彼此正交且互补：前者推迟输出就绪以便预览先出现，后者预先分配最坏情况下静态照片管线所需的资源，两者可组合且互不冲突⁵。

快速预览不等于快速拍摄

推迟照片输出有一个值得直说的代价：预览启动得早得多，但首次拍摄的耗时不变，因为系统在能开始拍摄之前，仍然必须完成对被推迟的照片输出的初始化¹。预览已经出现，用户按下快门，可瞬间却已错过。

解决办法是 AVCapturePhotoOutput 上的 isResponsiveCaptureEnabled。该属性在「开始拍摄」与「处理真正开始」之间增加了缓冲，因此即便照片输出尚未完全就绪，用户也能抓住那个瞬间¹。在 Apple 的多米诺骨牌演示中，同时运行响应式拍摄与 Deferred Start 的手机干净利落地拍下了倒下的骨牌，而对照组手机则完全错过了¹。这种搭配正是推荐的做法：用高质量照片输出采纳 Deferred Start，保持启动迅速，再让响应式拍摄覆盖照片输出完成初始化之前的那段窗口¹。

快速连拍的高分辨率拍摄

Apple 相机软件团队的工程师 Mohit 在 session 304 中于篮球场上演示了 fast capture prioritization。

session 304 把响应性的故事延伸到了高分辨率连拍。其机制是 AVCapturePhotoOutput 上的 isFastCapturePrioritizationEnabled，这是一个已有属性而非新属性：启用后，系统会检测短时间内的多次连续拍摄，并把照片质量从最高质量设置调整为均衡设置，后者无论拍摄还是处理所需的时间都更少⁴。新的部分随系统而来。从 iOS 27 起，在 iPhone 16 和 iPhone 17 上，系统还会通过 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 前置相机上⁴。prioritization 设置决定了你能请求什么：12MP 在全部三个 prioritization 级别都可用，单帧 48MP 需要均衡或质量级别，而多帧融合的 18MP 和 24MP 格式由于处理时间更长，则要求质量级别的 prioritization⁴。正是 deferred processing 让这些多帧融合在响应迅速的应用中变得切实可行，因为繁重的工作在后台进行，不与拍摄会话共享内存⁴。

渲染预览：图层还是 data output

有两种输出可以驱动预览，而这一选择决定了你还得额外做多少事。AVCaptureVideoPreviewLayer 精确呈现相机所见，应用无需做任何逐帧工作：它自动处理 HDR 色调映射，保持较低的 CPU 和 GPU 开销，并为低延迟显示进行调优¹。代价是它不提供逐帧访问¹。（关于这种自动色调映射中的 HDR 部分，AVFoundation HDR 与 Apple Log 一文深入讲解了拍摄与显示管线。）

当逐帧处理是首要任务时，AVCaptureVideoDataOutput 是另一种选择。它取代预览图层成为主要的显示输出，并把对帧流的控制权交给应用：逐帧的自定义 UI 叠加、Metal 集成、帧分析¹。代价是上文提到的手动 Deferred Start 采纳，外加一条纪律规则：让逐帧工作保持简短，以避免丢帧并保持体验流畅¹。当你只需要展示画面时使用预览图层；当你确实要处理帧时再选用 data output。

在压力下持续保持性能

大多数相机开发都在受控环境中的桌面前进行，但人们会在炎热的晴天使用应用，而设备升温时系统会进行节流¹。两个开销 API 让应用能预见这一点。Hardware cost 返回一个介于 0 和 1 之间的值，表示会话所占用硬件的比例；高于 1 意味着系统无法支撑该配置¹。开销随相机数量、激活的格式（1080p 还是 4K）、帧率以及格式是否经过 binned 而上升。Hardware cost 假定采用格式的最高帧率，因此在 60 fps 格式上以 30 fps 运行的应用应设置帧率上限来降低所报告的开销¹。

System pressure cost 同样返回 0 到 1，表示当前状态的开销，越过 1 就会使配置难以为继¹。采纳方式是：提交配置后，检查 hardware cost 保持在 1 或以下，然后观察 AVCaptureDevice 的 systemPressureState 并为其变化注册一个处理程序¹。随着压力上升，处理程序会降低拍摄设备的帧率，限制 GPU 或 Apple Neural Engine 的工作，并尽量减少 UI 工作¹。

Pro Video Storage：确定性的 ProRes 写入

session 303 介绍了 iOS 27 新增、面向高数据率视频拍摄的 Pro Video Storage。

传统的文件系统 I/O 是非确定性的：系统要兼顾相互竞争的操作、内存碎片和存储磨损，因此写入时机会有波动¹。像 ProRes 这样的高数据率拍摄需要持续的高带宽 I/O 才能录制而不丢帧，而时机不稳定恰恰是最糟糕的特性。iOS 27 新增的 Pro Video Storage 通过为高数据率拍摄追踪并管理预先分配的存储来解决这一问题。它是一个所有应用共享的系统级资源，并接入现有的影片录制 API¹。

应用通过在 AVCaptureMovieFileOutput 上设置 usesProVideoStorage 来选择启用，或者在从 video data output 录制时在 AVAssetWriter 上设置¹。随后存储会负责分配和文件 I/O，让高数据率编解码器的写入性能保持稳定。采纳顺序是：Pro Video Storage 是一个单例，因此通过它的共享访问器获取并确认是否支持；构建影片文件输出、会话、连接以及所选格式；检查影片文件输出上的 isProVideoStorageSupported；确认存储没有正忙于调整大小或处理文件的创建或删除；然后启用它并开始录制¹。拍摄期间，录制会写入预先分配的存储池，并在拍摄结束后移动到最终位置¹。相机设置现在允许用户控制分配多少存储，remainingCapacity 方法会报告剩余量，还有一个打开设置的方法可以把用户从应用带到那个界面¹。

Center Stage 前置相机是方形的

Apple 相机软件团队的工程师 Tracy 在 session 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²。该监视器基于自动的人脸与视线检测，定期给出构图建议，每条建议都带有一个应用可应用或忽略的宽高比和缩放系数；由于它面向照片拍摄，因此只在 4032 照片格式处于激活状态时才会给出建议²。默认情况下它不建议任何内容，所以要设置 enabledFramings（设为全部 supportedFramings，或所选的子集），然后对 recommendedFraming 进行键值观察并应用每条建议。顺序对平滑过渡很重要：先设置宽高比，再设置缩放系数²。该监视器可以在会话运行时启动；关闭自动构图意味着注销 KVO 并调用 stopMonitoring²。

新传感器带来了一个关于正确性的陷阱。早期 iPhone 前置相机以 Landscape Left 安装传感器，所以一张竖幅自拍会以传感器原生朝向到达，并携带一个要求在播放时旋转 270 度的 EXIF 标签。Center Stage 传感器以 Portrait 方式安装，因此依赖旧旋转值的应用会把照片渲染成侧着或上下颠倒²。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 后台模式的会议类应用，Center Stage 已默认激活，由用户从控制中心的「视频效果」菜单切换²。没有该后台模式的应用则直接采纳 Center Stage API：它按进程启用（与人像、影棚光效和手势一样），所以要设置一个控制模式（cooperative 以允许应用内按钮，或 app），然后把 isCenterStageEnabled 设为 true，构图便会让每个人都保持居中²。还有一项默认关闭的视频通话升级：一种实时低延迟稳定模式，通过把连接的 preferredVideoStabilizationMode 设为 lowLatency 来启用²。

采纳建议

这三场讲座奖励分层式的采纳。

对每一个 AVFoundation 相机应用： 首先采纳 Deferred Start。如果你用 AVCaptureVideoPreviewLayer 渲染预览并针对 iOS 26+ SDK 重新编译，自动模式即可免费开启；通过确认 automaticallyRunsDeferredStart 为 true 且每个非预览输出都设置了 isDeferredStartEnabled = true 来验证它¹。再在照片输出上搭配 isResponsiveCaptureEnabled，让快速的预览同时也是可用的快门¹。

对 data output 和 Metal 管线： 你放弃了那份免费的胜利。采纳手动 Deferred Start，在第一帧呈现后触发 runDeferredStartWhenNeeded()，并让逐帧工作保持简短¹。接好 systemPressureState 观察，让管线在发热的设备上优雅降级¹。

对 ProRes 和高数据率视频： 在 iOS 27 上采纳 Pro Video Storage 让持续写入具备确定性，并在录制前以 isProVideoStorageSupported 和忙碌检查作为前置门槛¹。

对 iPhone 17 / Air / 17 Pro 上的前置相机与自拍应用： 发现前置 .builtInUltraWideCamera，通过 dynamicAspectRatio 暴露 Tap to Rotate，并叠加 AVCaptureSmartFramingMonitor 实现 Auto Zoom 与 Auto Rotate。除非你已测得需要关闭的理由，否则保持传感器朝向补偿开启，并记住它永远不会触及 RAW²。

FAQ

Deferred Start 实际上能让启动快多少？

Apple 在实验室灯板上测得大约两倍的提速：原本接近一秒的启动在启用 Deferred Start 后降到大约一半，复杂的拍摄会话还能提升更多¹。提速来自在第一帧之前只初始化预览输出，把其他每个输出都推迟到预览出现之后¹。

我会自动获得 Deferred Start 吗？

如果你的应用用 AVCaptureVideoPreviewLayer 渲染预览并针对 iOS 26 或更高版本 SDK 重新编译，那么会：自动模式已开启，automaticallyRunsDeferredStart 默认为 true¹。用 AVCaptureVideoDataOutput 渲染预览的应用不会自动获得，必须采纳手动 Deferred Start 才能拿到同样的启动提升¹。

为什么即便用了 Deferred Start，我的第一张照片还是很慢？

推迟照片输出能加快预览，但加快不了首次拍摄，因为系统在能开始拍摄之前仍会完成对被推迟的照片输出的初始化¹。在 AVCapturePhotoOutput 上设置 isResponsiveCaptureEnabled 来缓冲拍摄，这样即便照片输出尚未完全就绪，那个瞬间也会被记录下来¹。

我该如何在代码中找到 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 工作流讲专业视频的拍摄与显示；一个 iOS 应用的三个层面讲拍摄在应用架构中的位置；SwiftUI 由什么构成讲承载预览的 UI 层；Apple 平台矩阵讲哪些功能落在哪里。中枢是 Apple 生态系统系列。关于「iOS 搭配 AI 智能体」的背景，参见 iOS 智能体开发指南。

参考资料