高解析照片不是只把尺寸拉大：用 AVFoundation 管好畫質、速度與記憶體
這場 session 說明 app 如何拍攝 24MP / 48MP、RAW、ProRAW 與 exposure-bracketed 照片，並用 responsive capture、deferred processing 和 fast capture prioritization 避免快門被處理流程卡住。
高解析拍攝的核心不是「要求最大尺寸」，而是先配置 session、預先準備資源，再把處理延後或重疊，讓使用者連拍時不錯過瞬間。
這支影片在拆四個相機 app 會踩到的決策
12MP、24MP、48MP 代表不同 pipeline
12MP 通常是標準高解析輸出；24MP 會把 12MP 多幀 HDR 與 48MP 細節合成；48MP 則是從 Quad sensor 取 full-resolution 單幀，細節更高但處理和資源需求也更明顯。
Processed、brackets、RAW、ProRAW 不是同一種用途
fully processed 適合大多數使用者；exposure brackets 給 HDR 或多曝光選擇；Bayer RAW 給後製；ProRAW 則把 RAW 彈性和 iPhone computational photography 結合。
session commit 前要把最大需求說清楚
maxPhotoQualityPrioritization 與支援的 maxPhotoDimensions 會影響可用資源。commit 後再改會觸發昂貴的 pipeline reconfiguration。
最高畫質可能讓下一張照片被卡住
高解析照片可能需要數秒處理。responsive capture 讓下一次 capture 不必等上一張完成 processing；deferred processing 則先交付 proxy，最後成品留給系統背景處理。
導入高解析拍攝的建議順序
用 photo preset 建立 capture session
影片明確提醒，只有 photo preset 支援 24MP 與 48MP 照片。若 app 用其他 preset 起步，後面要求高解析會直接撞到能力限制。
從 active format 查支援尺寸
使用 supportedMaxPhotoDimensions 找出目前 format 可用的 photo dimensions。不要假設所有鏡頭、所有裝置都能提供相同的最大尺寸。
在 commit 前完成 photo output 配置
把 maxPhotoQualityPrioritization 和最大尺寸需求放進 session configuration。這一步是在替後續每次拍攝預留可能需要的資源範圍。
每次 capture 再指定品質與尺寸
在 AVCapturePhotoSettings 設定 maxPhotoDimensions 與 photoQualityPrioritization。實際輸出尺寸要從 AVCaptureResolvedSettings 回讀，因為 request 不等於 guarantee。
對 48MP 模式預先 prepare settings
若 UI 讓使用者切到 48MP，應盡早呼叫 setPreparedPhotoSettingsArray。真正拍攝時建立新的 settings 物件，但配置要和 prepare 時一致。
重點 1：24MP 是「畫質與檔案大小」的折衷，不只是中間尺寸
影片把 24MP 講得很清楚：它先用 Quad sensor combined pixels 生成 12MP multi-frame fused HDR image，再由 Photonic Engine 與 48MP full sensor resolution 的細節結合。結果是解析度比 12MP 高一倍，但檔案大小只約增加 50%。
因此 app 設計不能只做「最大尺寸」開關。24MP、48MP、RAW、ProRAW 和 fully processed 的使用者期待不同，應該映射到不同 UI 模式、檔案管理與處理時間提示。
重點 2：品質優先順序其實是產品策略
photoQualityPrioritization 有 speed、balanced、quality 三種。speed 最快但處理最少；balanced 在常見情境給出較佳速度與品質平衡；quality 處理最久但影像品質最好。這不是單純工程參數，而是 app 想優先保住「瞬間」還是「單張最佳品質」的產品選擇。
AVCaptureResolvedSettings.photoProcessingTimeRange 可讓 app 預估照片何時交付，不要讓使用者只看到無意義 spinner。重點 3：responsive capture 和 deferred processing 解決的是「下一張」
高解析照片的痛點不是只在第一張處理慢，而是 processing stage 會阻擋下一次 capture，形成 shot-to-shot delay。啟用 responsive capture 後，上一張只要 capture stage 完成，下一張就可以開始；app 可觀察 captureReadiness 決定快門何時可按。
deferred photo processing 更進一步：系統先透過 didFinishCapturingDeferredPhotoProxy 交付輕量 proxy，最後照片在使用者要求或系統條件合適時才完成背景處理。這讓高品質 multi-frame fusion 不必吃掉同一條互動路徑的記憶體與時間。
風險與遷移注意事項
第一，鏡頭能力要按裝置與 active format 查，不要用固定機型表寫死。第二，commit 後才改 output 配置會重建 pipeline，容易造成體感卡頓。第三，prepare settings 不能直接拿來 capture，要重建相同配置的新 settings。第四，fast capture prioritization 會在快速連拍時把最高品質調整為 balanced，產品文案要避免承諾每張都必然是最高品質。
- 0124MP 與 48MP 是不同 pipeline，不只是不同數字；選項設計要反映畫質、檔案大小與處理時間。
- 02session commit 前配置最大需求，每次 capture 再選尺寸與品質；實際結果以 resolved settings 為準。
- 03responsive capture、deferred processing、fast capture prioritization 是讓高畫質拍攝不阻塞下一張照片的關鍵。
- 04導入時要測鏡頭差異、光線差異、連拍、背景處理、proxy 與最終照片交付時間。