Budowa responsywnej aplikacji aparatu w iOS 27

Zespół Apple zajmujący się wydajnością aparatu skrócił czas uruchamiania o połowę, odraczając wszystko poza wyjściem podglądu: uruchomienie, które trwało blisko sekundy, spada do mniej więcej połowy tego czasu — to dwukrotna poprawa zmierzona na laboratoryjnej tablicy świetlnej¹. Dźwignią jest API Deferred Start, dostępne w iOS 26 i nowszych, a zasada, która za nim stoi, jest bezceremonialna. Najważniejszym pojedynczym czynnikiem decydującym o tym, czy uruchomienie aparatu sprawia wrażenie szybkiego, jest to, jak prędko klatka podglądu pojawia się na ekranie¹.

Ramą dla tego wpisu jest pytanie „co aplikacja AVFoundation musi zrobić, aby działała natychmiastowo”, ponieważ przepaść między aparatem, który technicznie działa, a takim, który sprawia wrażenie gotowego do użycia, to dokładnie ta szczelina, przez którą prześlizguje się spadające domino. Surowiec opisują trzy sesje WWDC26: sesja 303 o responsywnym uruchamianiu i trwałym przechwytywaniu, sesja 304 o przechwytywaniu w wysokiej rozdzielczości bez utraty responsywności oraz sesja 341 o nowym kwadratowym przednim aparacie Center Stage. Łączy je ta sama architektura sesji przechwytywania, więc wdrożenie jednej obniża koszt pozostałych.

W skrócie

• Czteroetapowa sekwencja uruchamiania (start aplikacji, konfiguracja/uruchomienie sesji, inicjalizacja wyjść, strumieniowanie podglądu) większość czasu spędza na inicjalizacji wyjść. Deferred Start odracza każde wyjście poza tym, które renderuje podgląd, skracając uruchamianie o połowę w pomiarze laboratoryjnym Apple¹.
• Aplikacje oparte na AVCaptureVideoPreviewLayer ponownie skompilowane względem iOS 26+ otrzymują automatyczny Deferred Start za darmo; aplikacje z wyjściem danych wideo muszą wdrożyć tryb ręczny, aby uzyskać tę samą korzyść¹.
• Odroczenie wyjścia zdjęć przyspiesza podgląd, ale nie pierwsze przechwycenie, więc warto połączyć je z isResponsiveCaptureEnabled na AVCapturePhotoOutput, aby buforować ujęcie, dopóki przetwarzanie nie będzie gotowe¹.
• Pro Video Storage, nowość w iOS 27, wstępnie przydziela ogólnosystemową pulę pamięci, dzięki czemu zapisy ProRes o wysokiej przepływności pozostają deterministyczne, zamiast zacinać się pod presją systemu plików¹.
• Przedni aparat Center Stage (iPhone 17, iPhone Air, iPhone 17 Pro) to kwadratowy czujnik udostępniany jako przedni .builtInUltraWideCamera; dynamicAspectRatio wykadrowuje dowolne proporcje obrazu z kwadratu bez przebudowy sesji, a AVCaptureSmartFramingMonitor napędza Auto Zoom i Auto Rotate².

Sekwencja uruchamiania ma cztery etapy

Jake, inżynier z zespołu wydajności aparatu Apple, omawia cztery etapy uruchamiania w sesji 303.

Uruchomienie aparatu przebiega przez cztery etapy, a inżynier Apple Jake rozkłada je po kolei¹. Najpierw uruchamia się aplikacja: linker ładuje plik binarny, działają inicjalizatory statyczne, tworzone są sceny UI. Po drugie konfigurowana i uruchamiana jest sesja: inicjalizacja AVCaptureSession, zatwierdzenie konfiguracji i uruchomienie sesji — wszystko to pochłania czas i zasoby systemowe. Po trzecie inicjalizuje się każde AVCaptureOutput, a ten czas skaluje się wraz z liczbą wyjść i ich ustawieniami jakości. Po czwarte rozpoczyna się strumieniowanie podglądu i klatki płyną do aplikacji¹.

Praca nad przyspieszeniem zaczyna się w UI. Należy podzielić uruchamianie na dwie fazy: zasoby krytyczne dla wyświetlenia podglądu oraz zasoby, które mogą poczekać do momentu, aż podgląd zacznie działać¹. W AVCam, klasycznej przykładowej aplikacji aparatu z AVFoundation, podgląd aparatu i przycisk migawki to jedyne elementy, których ktoś potrzebuje w chwili uruchomienia; studnia obrazu i selektor trybów mogą pojawić się później. Zasada uogólnia się poza UI. Każdy zasób tworzony przed wyrenderowaniem podglądu wydłuża czas uruchamiania¹.

Sama sesja to kolejny punkt nacisku. Ponieważ AVCaptureSession koordynuje każdy obiekt przechwytywania, Jake tworzy ją jako pierwszą, gdy tylko wątek główny zakończy konfigurację UI. Tworzenie sesji blokuje jednak wątek główny, dlatego należy zlecić jej utworzenie poza wątkiem głównym, aby działało równolegle z konfiguracją sceny UI i pozwoliło uniknąć zawieszenia¹. Ta sama ostrożność dotyczy startRunning() i stopRunning(): oba są wywołaniami blokującymi, a wywołanie ich na wątku głównym zawiesi aplikację¹. Warto z góry zatwierdzić jedną konfigurację, zamiast zatwierdzać kilka, ponieważ każda zmiana konfiguracji wydłuża uruchamianie¹.

Deferred Start: dwukrotne przyspieszenie

Inicjalizacja wyjść to najdroższa część uruchamiania, a większość wyjść jest w tym momencie martwym balastem. Aby wyrenderować podgląd, aplikacja potrzebuje tylko warstwy podglądu lub pojedynczego wyjścia; wyjście pliku filmowego i wyjście zdjęć nie wnoszą nic do pierwszej klatki¹. Deferred Start to wykorzystuje. Odracza inicjalizację wyjść do zakończenia uruchamiania, więc przed wyświetleniem pierwszej klatki inicjalizuje się tylko wyjście podglądu¹.

Każde AVCaptureOutput oraz AVCaptureVideoPreviewLayer mają właściwość isDeferredStartEnabled; ustawienie jej na true odracza dane wyjście — należy odroczyć wszystko poza tym, które renderuje podgląd¹. Istnieją dwa tryby decydowania o tym, kiedy uruchamia się odroczona praca. W trybie automatycznym system sam wybiera najlepszy moment, krótko po pojawieniu się podglądu, i wywołuje dwa wywołania zwrotne delegata, aby aplikacja mogła to śledzić: sessionWillRunDeferredStart przed rozpoczęciem inicjalizacji oraz sessionDidRunDeferredStart po jej zakończeniu¹. Aplikacje ponownie skompilowane względem SDK iOS 26 lub nowszego domyślnie otrzymują tryb automatyczny, z automaticallyRunsDeferredStart ustawionym już na 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

Tryb ręczny oddaje kontrolę z powrotem aplikacji. Należy ustawić automaticallyRunsDeferredStart na false, wykonać dowolną pracę startową, która musi nastąpić wcześniej (odczyt preferencji, budowa niekrytycznego UI), a następnie wywołać runDeferredStartWhenNeeded(), aby zasygnalizować systemowi, że może kontynuować¹. Tryb ręczny ma znaczenie zwłaszcza dla jednej architektury: aplikacji, które renderują podgląd przez AVCaptureVideoDataOutput. Deferred Start nie stosuje się automatycznie do wyjścia danych, więc takie aplikacje wdrażają ręczny Deferred Start, aby uzyskać tę samą korzyść w uruchamianiu — zwykle uruchamiając go po wyświetleniu pierwszej klatki (Jake śledzi prezentację przez CAMetalLayer)¹.

Apple zweryfikowało wynik na laboratoryjnej tablicy świetlnej, porównując dwa telefony przechwytujące rozszerzający się wzór LED. Telefon z włączonym Deferred Start uchwycił wzór, gdy świeciły zarówno czerwone, jak i zielone diody LED; telefon bez niego zakończył uruchamianie dopiero wtedy, gdy zielone diody niemal zgasły¹. Zmierzone uruchomienie bez Deferred Start trwało blisko sekundy; z nim skróciło się o połowę — dwukrotna poprawa, a złożone sesje przechwytywania zyskują jeszcze więcej¹.

Grupuj zmiany zakłócające, aby graf przebudował się tylko raz

Za dyscypliną pojedynczej konfiguracji z sekwencji uruchamiania stoi mechanizm, który opisał inżynier aparatu z panelu laboratoryjnego WWDC26. AVCaptureSession koordynuje graf obiektów przechwytywania, a za każdym razem, gdy ustawiamy właściwość wymuszającą zmianę zakłócającą, sesja ponownie rozwiązuje ten graf⁵. Zmiana konfiguracji zwykle oznacza zmianę więcej niż jednej rzeczy naraz — przełączenie z trybu zdjęć na tryb wideo albo zejście aktywnego formatu do niższej rozdzielczości — więc ustawianie każdej właściwości z osobna wymusza przebudowę grafu na każdym kroku⁵. Należy opakować całą partię w beginConfiguration() i commitConfiguration(), a graf rozwiąże się ponownie dokładnie raz, przy zatwierdzeniu, niezależnie od tego, czy partia zawiera jedną zmianę, czy dwadzieścia⁵. Panelista porównał tę parę do transakcji bankowej: beginConfiguration() ją otwiera, wypłata i wpłata pozostają w toku, a commitConfiguration() rozlicza je razem⁵.

Deferred Start czysto komponuje się z jeszcze jedną dźwignią sprzed uruchomienia. Panel potwierdził, że Deferred Start i tablica przygotowanych ustawień zdjęć (setPreparedPhotoSettingsArray(_:completionHandler:) na AVCapturePhotoOutput) są ortogonalne i komplementarne — jedna odracza gotowość wyjścia, aby podgląd pojawił się jako pierwszy, podczas gdy druga wstępnie przydziela zasoby najgorszego przypadku potoku zdjęć, możliwe do złożenia bez konfliktu⁵.

Szybki podgląd to nie szybkie przechwytywanie

Odroczenie wyjścia zdjęć ma haczyk, który warto wprost nazwać: podgląd startuje znacznie wcześniej, ale czas do pierwszego przechwycenia pozostaje taki sam, ponieważ system wciąż musi dokończyć inicjalizację odroczonego wyjścia zdjęć, zanim będzie można rozpocząć przechwytywanie¹. Podgląd jest gotowy, użytkownik dotyka migawki, a ujęcie i tak przepada.

Rozwiązaniem jest isResponsiveCaptureEnabled na AVCapturePhotoOutput. Właściwość dodaje buforowanie między rozpoczęciem przechwytywania a momentem, w którym zaczyna się przetwarzanie, dzięki czemu można uchwycić chwilę nawet wtedy, gdy wyjście zdjęć nie jest jeszcze w pełni gotowe¹. W demonstracji domina Apple telefon z responsywnym przechwytywaniem działającym obok Deferred Start uchwycił czyste ujęcie spadających kostek domina, podczas gdy telefon kontrolny całkowicie je przegapił¹. To połączenie jest zalecanym wzorcem: wdrożyć Deferred Start z jakościowym wyjściem zdjęć, utrzymać szybkie uruchamianie i pozwolić, by responsywne przechwytywanie pokryło okno, zanim wyjście zdjęć zakończy inicjalizację¹.

Szybkie przechwytywanie w wysokiej rozdzielczości

Mohit, inżynier z zespołu Camera Software Apple, demonstruje fast capture prioritization na boisku do koszykówki w sesji 304.

Sesja 304 rozszerza wątek responsywności na serie w wysokiej rozdzielczości. Mechanizmem jest isFastCapturePrioritizationEnabled na AVCapturePhotoOutput — istniejąca właściwość, a nie nowa: gdy jest włączona, system wykrywa wielokrotne przechwycenia w krótkich odstępach i dostosowuje jakość zdjęcia z najwyższego ustawienia jakości do zrównoważonego, które potrzebuje mniej czasu zarówno na przechwycenie, jak i na przetwarzanie⁴. Nowa część przychodzi wraz z systemem. Począwszy od iOS 27 na iPhone 16 i iPhone 17, system przetwarza też te zrównoważone szybkie przechwycenia później, używając odroczonego przetwarzania zdjęć — potoku działającego w tle z WWDC23, który kończy zdjęcie bez blokowania kolejnego przechwycenia (odrębnego od API uruchamiania Deferred Start powyżej)⁴. W demonstracji koszykarskiej Apple różnicą było jedno zablokowane przechwycenie wobec pięciu responsywnych ujęć tej samej akcji, gdy włączono odroczone przetwarzanie, responsywne przechwytywanie i fast capture prioritization naraz⁴.

Ta sama sesja aktualizuje tabelę pokrycia wysokiej rozdzielczości. Obsługa przechwytywania 24 MP i 48 MP rozszerza się na aparat teleobiektywowy w iPhone 16 Pro oraz aparat ultraszerokokątny w iPhone 17, a opcja 18 MP istnieje wyłącznie na przednim aparacie Center Stage w iPhone 17⁴. Ustawienie priorytetyzacji warunkuje to, o co można poprosić: 12 MP działa na wszystkich trzech poziomach priorytetyzacji, jednoklatkowe 48 MP wymaga zrównoważonego lub jakościowego, a wieloklatkowe scalone formaty 18 MP i 24 MP wymagają priorytetyzacji jakościowej ze względu na dłuższe przetwarzanie⁴. Odroczone przetwarzanie sprawia, że te wieloklatkowe scalenia są praktyczne w responsywnej aplikacji, ponieważ ciężka praca odbywa się w tle, bez współdzielenia pamięci z sesją przechwytywania⁴.

Renderowanie podglądu: warstwa kontra wyjście danych

Podgląd mogą napędzać dwa wyjścia, a wybór decyduje o tym, ile jeszcze trzeba zrobić. AVCaptureVideoPreviewLayer pokazuje dokładnie to, co widzi aparat, bez pracy na klatkę w aplikacji: automatycznie obsługuje mapowanie tonów HDR, utrzymuje niski narzut CPU i GPU oraz stroi się pod wyświetlanie o niskim opóźnieniu¹. Kompromisem jest to, że nie oferuje dostępu do pojedynczych klatek¹. (Stronę HDR tego automatycznego mapowania tonów omawia szczegółowo wpis o AVFoundation HDR i Apple Log, który zagłębia się w potok przechwytywania i wyświetlania.)

AVCaptureVideoDataOutput jest alternatywą, gdy priorytetem jest przetwarzanie pojedynczych klatek. Zajmuje miejsce warstwy podglądu jako podstawowe wyjście wyświetlania i daje aplikacji kontrolę nad przepływem klatek: niestandardowe nakładki UI na klatkę, integracja z Metal, analiza klatek¹. Kosztem jest wspomniane wyżej ręczne wdrożenie Deferred Start oraz reguła dyscypliny: utrzymywać krótką pracę na klatkę, aby uniknąć gubienia klatek i zachować płynność doświadczenia¹. Należy używać warstwy podglądu, gdy trzeba jedynie pokazać obraz; po wyjście danych warto sięgnąć, gdy rzeczywiście przetwarza się klatki.

Utrzymanie wydajności pod presją

Większość pracy nad aparatem odbywa się przy biurku, w kontrolowanym środowisku, ale ludzie używają aplikacji w gorący, słoneczny dzień, a system dławi się, gdy urządzenie się nagrzewa¹. Dwa API kosztu pozwalają aplikacji to przewidzieć. Koszt sprzętowy zwraca wartość między 0 a 1, reprezentującą udział wykorzystanego sprzętu sesji; powyżej 1 oznacza, że system nie jest w stanie obsłużyć tej konfiguracji¹. Koszt rośnie wraz z liczbą aparatów, aktywnymi formatami (1080p kontra 4K), liczbą klatek na sekundę oraz tym, czy format jest binowany. Koszt sprzętowy zakłada maksymalną liczbę klatek formatu, więc aplikacja działająca przy 30 kl./s w formacie 60 kl./s powinna ustawić nadpisanie liczby klatek, aby obniżyć raportowany koszt¹.

Koszt presji systemowej również zwraca wartość od 0 do 1, reprezentującą koszt bieżącego stanu, a przekroczenie 1 czyni konfigurację nie do utrzymania¹. Wzorzec wdrożenia: po zatwierdzeniu konfiguracji sprawdzić, czy koszt sprzętowy pozostaje równy 1 lub niższy, a następnie obserwować systemPressureState urządzenia AVCaptureDevice i zarejestrować program obsługi zmian¹. W miarę wzrostu presji program obsługi obniża liczbę klatek urządzenia przechwytującego, dławi pracę GPU lub Apple Neural Engine i minimalizuje pracę UI¹.

Pro Video Storage: deterministyczne zapisy ProRes

Sesja 303 przedstawia Pro Video Storage, nowość w iOS 27, dla przechwytywania wideo o wysokiej przepływności.

Tradycyjne wejście-wyjście systemu plików jest niedeterministyczne: system żongluje konkurującymi operacjami, fragmentacją pamięci i zużyciem nośnika, więc czas zapisu jest zmienny¹. Przechwytywanie o wysokiej przepływności, takie jak ProRes, potrzebuje trwałego, szerokopasmowego wejścia-wyjścia, aby nagrywać bez gubienia klatek, a zmienne czasy to dokładnie niewłaściwa właściwość. Pro Video Storage, nowość w iOS 27, rozwiązuje ten problem, śledząc i zarządzając wstępnie przydzieloną pamięcią dla przechwytywania o wysokiej przepływności. To zasób ogólnosystemowy, współdzielony przez wszystkie aplikacje, który wpina się w istniejące API nagrywania filmów¹.

Aplikacje włączają tę funkcję, ustawiając usesProVideoStorage na AVCaptureMovieFileOutput lub na AVAssetWriter przy nagrywaniu z wyjścia danych wideo¹. Pamięć obsługuje wtedy alokację i wejście-wyjście plików, utrzymując spójną wydajność zapisu dla kodeków o wysokiej przepływności. Sekwencja wdrożenia: Pro Video Storage jest singletonem, więc należy uzyskać go przez współdzielony akcesor i potwierdzić obsługę; zbudować wyjście pliku filmowego, sesję, połączenia i wybrany format; sprawdzić isProVideoStorageSupported na wyjściu pliku filmowego; potwierdzić, że pamięć nie jest zajęta zmianą rozmiaru ani obsługą tworzenia lub usuwania plików; a następnie włączyć ją i rozpocząć nagrywanie¹. Podczas przechwytywania nagranie zapisuje się do wstępnie przydzielonej puli i przenosi się do docelowej lokalizacji po zakończeniu przechwytywania¹. Ustawienia aparatu pozwalają teraz ludziom kontrolować, ile pamięci przydzielić, metoda remainingCapacity raportuje, ile pozostało, a metoda otwierania ustawień przenosi użytkownika do tego interfejsu z poziomu aplikacji¹.

Przedni aparat Center Stage jest kwadratowy

Tracy, inżynier z zespołu Camera Software Apple, przedstawia kwadratowy przedni aparat Center Stage w sesji 341.

Tradycyjne czujniki przednich aparatów mają proporcje 4:3, które blokują kadrowanie do orientacji telefonu. Przedni aparat Center Stage w iPhone 17, iPhone Air i iPhone 17 Pro wykorzystuje kwadratowy czujnik obrazu w parze z obiektywem 95 stopni — najszersze pole widzenia w jakimkolwiek przednim aparacie iPhone’a². Inżynier Apple Tracy ujmuje korzyść: kwadratowy kształt pozwala użytkownikowi wybrać dowolne proporcje obrazu, wykonując selfie w orientacji pionowej lub poziomej bez obracania telefonu, co zachowuje pewny chwyt jedną ręką oraz wyśrodkowany obraz z naturalnym kontaktem wzrokowym².

Konfiguracja sesji jest konwencjonalna dla AVFoundation³. Należy utworzyć AVCaptureSession, znaleźć aparat jako AVCaptureDevice z typem urządzenia przedni .builtInUltraWideCamera, opakować go w AVCaptureDeviceInput, dodać AVCaptureVideoPreviewLayer do podglądu oraz AVCapturePhotoOutput do zdjęć; sesja niejawnie tworzy obiekty AVCaptureConnection między zgodnymi typami mediów².

Elementem konstrukcyjnym jest dynamicAspectRatio na AVCaptureDevice, dostępne począwszy od iOS 26. Ustawienie tej właściwości wykadrowuje wybrane proporcje obrazu z kwadratowego czujnika bez przebudowy sesji ani przerywania podglądu, więc przełączenie jest płynne². Właściwość obsługuje pięć proporcji obrazu (3:4, 4:3, 9:16, 16:9 i 1:1) w formatach kwadratowych od 1280 aż do 4032, z jednym ograniczeniem: format zdjęcia 4032 obsługuje tylko 3:4 i 4:3, ponieważ to one zachowują najwyższą rozdzielczość².

// 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()

Każdy format ogłasza swoje supportedDynamicAspectRatios, a ustawienie proporcji zwraca znacznik czasu pierwszego bufora, w którym zmiana wchodzi w życie². Zwrócony znacznik czasu nie jest dekoracją: dla nagrywania wideo to szew, który pozwala zakończyć jeden klip i rozpocząć następny w nowych proporcjach obrazu.

Auto Zoom, Auto Rotate i kompensacja czujnika

AVCaptureSmartFramingMonitor (iOS 26 i nowsze, uzyskiwany z aparatu) zasiada na dynamicAspectRatio i napędza Auto Zoom oraz Auto Rotate². Monitor podaje okresowe rekomendacje kadrowania na podstawie automatycznego wykrywania twarzy i wzroku, z których każda niesie proporcje obrazu i współczynnik zoomu, jakie aplikacja może zastosować lub zignorować; ponieważ celuje w przechwytywanie zdjęć, rekomenduje tylko wtedy, gdy aktywny jest format zdjęcia 4032². Domyślnie nie rekomenduje niczego, więc należy ustawić enabledFramings (na wszystkie supportedFramings lub wybrany podzbiór), a następnie obserwować recommendedFraming przez KVO i zastosować każdą rekomendację. Kolejność ma znaczenie dla płynnego przejścia: najpierw ustawić proporcje obrazu, potem współczynnik zoomu². Monitor można uruchomić, gdy sesja działa; wyłączenie automatycznego kadrowania oznacza wyrejestrowanie KVO i wywołanie stopMonitoring².

Jedna pułapka poprawności przychodzi wraz z nowym czujnikiem. Wcześniejsze przednie aparaty iPhone’a montowały czujnik w orientacji Landscape Left, więc selfie w orientacji pionowej docierało w natywnej orientacji czujnika, niosąc znacznik EXIF żądający obrotu o 270 stopni przy odtwarzaniu. Czujnik Center Stage jest zamontowany w orientacji Portrait, więc aplikacje polegające na starych wartościach obrotu renderowałyby zdjęcia bokiem lub do góry nogami². AVCapturePhotoOutput obsługuje to domyślnie przez kompensację orientacji czujnika: fizycznie obraca przetworzone zdjęcia HEIC, JPEG i nieskompresowane oraz aktualizuje metadane EXIF, aby wynik trafiał w Landscape Left jak wcześniej, pozwalając istniejącej logice obrotu nadal działać². Dwa zastrzeżenia: kompensacja nigdy nie dotyczy Bayer RAW ani Apple ProRAW, a Apple zaleca przetestowanie z wyłączoną kompensacją (przez cameraSensorOrientationCompensationEnabled) dla najlepszej wydajności, potwierdzając, że orientacja pozostaje poprawna².

Center Stage dla wideo i połączeń

Przy nagrywaniu wideo dynamicAspectRatio działa tak samo, ale ścieżki filmu QuickTime wymagają, aby wszystkie próbki współdzieliły wymiary, więc zmiana proporcji w trakcie przechwytywania zatrzymuje nagrywanie². Przy AVCaptureMovieFileOutput nagrywanie zatrzymuje się automatycznie przy zmianie; przy AVCaptureVideoDataOutput w połączeniu z AVAssetWriter znacznik czasu zakończenia setDynamicAspectRatio jest punktem cięcia, by zakończyć jedno nagranie i rozpocząć kolejne w nowych proporcjach². Nagrania zyskują też dwa świadome twarzy tryby kinowej stabilizacji na tym aparacie, cinematicExtended i cinematicExtendedEnhanced, które priorytetyzują utrzymanie stabilności obiektu nad tłem².

Połączenia wideo mają najprostszą ścieżkę. Center Stage jest już aktywny dla aplikacji konferencyjnych korzystających z trybu działania w tle Voice over IP, przełączany przez użytkownika z menu Efekty Wideo w Centrum sterowania². Aplikacje bez tego trybu działania w tle wdrażają API Center Stage bezpośrednio: jest włączane na proces (jak Portret, Studyjne oświetlenie i Gesty), więc należy ustawić tryb kontroli (cooperative, aby zezwolić na przycisk w aplikacji, lub app), następnie ustawić isCenterStageEnabled na true, a kadrowanie utrzyma wszystkich wyśrodkowanych². Jeszcze jedno usprawnienie połączeń wideo jest dostarczane domyślnie wyłączone: tryb stabilizacji o niskim opóźnieniu w czasie rzeczywistym, włączany przez ustawienie preferredVideoStabilizationMode połączenia na lowLatency².

Wskazówki dotyczące wdrożenia

Trzy sesje nagradzają wdrożenie warstwowe.

Dla każdej aplikacji aparatu AVFoundation: Najpierw wdrożyć Deferred Start. Jeśli renderuje się podgląd przez AVCaptureVideoPreviewLayer i kompiluje ponownie względem SDK iOS 26+, tryb automatyczny jest włączony za darmo; należy to zweryfikować, potwierdzając, że automaticallyRunsDeferredStart ma wartość true i że każde wyjście inne niż podgląd ma isDeferredStartEnabled = true¹. Warto połączyć to z isResponsiveCaptureEnabled na wyjściu zdjęć, aby szybki podgląd był też użyteczną migawką¹.

Dla potoków wyjścia danych i Metal: Rezygnuje się z darmowej korzyści. Należy wdrożyć ręczny Deferred Start, uruchomić runDeferredStartWhenNeeded() po wyświetleniu pierwszej klatki i utrzymywać krótką pracę na klatkę¹. Warto podłączyć obserwację systemPressureState, aby potok degradował się łagodnie na rozgrzanym urządzeniu¹.

Dla ProRes i wideo o wysokiej przepływności: Należy wdrożyć Pro Video Storage w iOS 27, aby trwałe zapisy stały się deterministyczne, warunkując na isProVideoStorageSupported i sprawdzeniu zajętości przed nagrywaniem¹.

Dla aplikacji przedniego aparatu i selfie na iPhone 17 / Air / 17 Pro: Należy wykryć przedni .builtInUltraWideCamera, udostępnić Tap to Rotate przez dynamicAspectRatio i nałożyć AVCaptureSmartFramingMonitor dla Auto Zoom i Auto Rotate. Warto pozostawić kompensację orientacji czujnika włączoną, o ile nie zmierzono powodu, by ją wyłączyć, i pamiętać, że nigdy nie dotyka RAW².

FAQ

O ile szybsze faktycznie staje się uruchamianie dzięki Deferred Start?

Apple zmierzyło około dwukrotne przyspieszenie na laboratoryjnej tablicy świetlnej: uruchomienie trwające blisko sekundy spadło do mniej więcej połowy tego czasu z włączonym Deferred Start, a złożone sesje przechwytywania mogą poprawić się jeszcze bardziej¹. Korzyść bierze się z inicjalizowania tylko wyjścia podglądu przed pierwszą klatką, z odroczeniem każdego innego wyjścia do momentu pojawienia się podglądu¹.

Czy otrzymam Deferred Start automatycznie?

Jeśli aplikacja renderuje podgląd przez AVCaptureVideoPreviewLayer i kompiluje się ponownie względem SDK iOS 26 lub nowszego, to tak: tryb automatyczny jest włączony, a automaticallyRunsDeferredStart domyślnie ma wartość true¹. Aplikacje, które renderują podgląd przez AVCaptureVideoDataOutput, nie otrzymują tego automatycznie i muszą wdrożyć ręczny Deferred Start, aby uzyskać tę samą korzyść w uruchamianiu¹.

Dlaczego moje pierwsze zdjęcie wciąż jest wolne, nawet z Deferred Start?

Odroczenie wyjścia zdjęć przyspiesza podgląd, ale nie pierwsze przechwycenie, ponieważ system wciąż kończy inicjalizację odroczonego wyjścia zdjęć, zanim będzie można rozpocząć przechwytywanie¹. Należy ustawić isResponsiveCaptureEnabled na AVCapturePhotoOutput, aby buforować przechwytywanie, dzięki czemu chwila zostaje zarejestrowana nawet zanim wyjście zdjęć będzie w pełni gotowe¹.

Jak znaleźć przedni aparat Center Stage w kodzie?

Należy użyć AVCaptureDevice.DiscoverySession, żądając typu urządzenia .builtInUltraWideCamera w pozycji .front; przedni aparat Center Stage jest udostępniany jako to ultraszerokokątne urządzenie przednie w iPhone 17, iPhone Air i iPhone 17 Pro². Stamtąd można ustawić dynamicAspectRatio, aby wykadrować dowolne obsługiwane proporcje obrazu z kwadratowego czujnika bez przebudowy sesji².

Czy stara logika obrotu przedniego aparatu zepsuje się na nowym czujniku?

Może się zepsuć, ponieważ czujnik Center Stage jest zamontowany w orientacji Portrait, a nie w historycznej Landscape Left, więc nieskompensowane bufory pojawiałyby się bokiem lub do góry nogami². AVCapturePhotoOutput domyślnie stosuje kompensację orientacji czujnika dla przetworzonych zdjęć HEIC, JPEG i nieskompresowanych (nigdy RAW), więc istniejące wartości obrotu nadal działają, o ile nie wyłączy się cameraSensorOrientationCompensationEnabled².

Klaster Apple Ecosystem

Ten wpis mieści się w pasie aparatu i przechwytywania: przepływ pracy AVFoundation HDR i Apple Log dla profesjonalnego przechwytywania i wyświetlania wideo; trzy powierzchnie aplikacji iOS dla tego, gdzie przechwytywanie pasuje w architekturze aplikacji; z czego zbudowane jest SwiftUI dla warstwy UI, która hostuje podgląd; oraz macierz platform Apple dla tego, które funkcje gdzie trafiają. Centrum stanowi seria Apple Ecosystem. Kontekst iOS-z-agentami-AI znajduje się w przewodniku po programowaniu agentów iOS.

Bibliografia