Co zespół wydajności Apple powiedział podczas labu na WWDC26

Podczas WWDC26 Apple posadziło przed kamerą pięciu własnych inżynierów Power & Performance na godzinę sesji pytań i odpowiedzi z deweloperami na żywo i odpowiadało na pytania, które deweloperzy faktycznie zadają: dlaczego bezczynny ekran SwiftUI nadal rozładowuje baterię, jak udawać stare urządzenie, którego się nie posiada, oraz na czym naprawdę polega największy błąd dotyczący zużycia energii we wdrożonych aplikacjach. Dopracowane sesje wyjaśniają, jak działa dany framework. Group Lab pokazał natomiast, jak korzystają z niego własne zespoły Apple. Ten artykuł zbiera praktyczne wskazówki warte zachowania.

Uwaga o źródłach: Apple opublikowało nagranie tego labu bez napisów. Transkrybowałem je lokalnie za pomocą Whispera, więc każdy cytat z labu poniżej jest parafrazą tej transkrypcji, a nie dosłowną transkrypcją Apple. Wypowiedzi przypisuję mówcom na podstawie imion i ról podanych we wprowadzeniach do labu, wywnioskowanych z kontekstu rozmowy: Terry odpowiada za wydajność, Yanni za MetricKit, Kaspar za Instruments, Kunal za CoreOS Power, a Marco za potok renderowania, natomiast Cole prowadzi spotkanie.¹ Tam, gdzie wskazówki z labu dotykają czegoś, co Apple formalnie dokumentuje, cytuję dany dokument lub odpowiadającą mu sesję i zaznaczam to.

Bezprzewodowy przepływ pracy ze śladem poboru mocy, który stanowi podstawę dużej części porad z labu, zaczyna się około 11:42.

TL;DR

• Stara, oparta na Objective-C powierzchnia MetricKit odchodzi do lamusa: MXMetricManager jest formalnie wycofany (deprecated) od 27.0, a nowe typy metryk i diagnostyki dostarczane są wyłącznie w nowym API Swift.²³
• Xcode Organizer oferuje teraz Metric Goals — punkty odniesienia czerpane z własnej historii oraz z aplikacji, które Apple uznaje za podobne do twojej, obejmujące uruchamianie, częstość zawieszeń (hang), zapisy na dysk, baterię, pamięć masową oraz zacięcia (hitches).⁴
• Przepływem pracy dla energii, który zaleca zespół, jest tryb Power Profiler w Performance Trace: zarejestruj na urządzeniu bezprzewodowy ślad .aar, udostępnij go na swojego Maca i odczytaj w Instruments tory poboru mocy CPU, GPU, wyświetlacza oraz sieci. Ta funkcja pojawiła się wraz z iOS 26, a nie iOS 27.⁵
• Praca Apple Intelligence wykonuje się głównie na Neural Engine oraz w Private Cloud Compute, więc praca aplikacji obciążająca CPU często może działać równolegle bez rywalizacji. Należy dzielić zadania w tle na fragmenty, aby system mógł je wstrzymywać i wznawiać.¹
• Największym błędem dotyczącym energii, jaki widzi zespół, jest niewystarczająca telemetria: deweloperzy optymalizują niewłaściwą rzecz, ponieważ nigdy nie zmierzyli właściwej.¹

Dlaczego warto transkrybować lab

Nagrane sesje Apple są napisane według scenariusza, przećwiczone i zmontowane. Group Lab nie jest żadną z tych rzeczy. To inżynierowie reagujący w czasie rzeczywistym na pytania pracujących deweloperów, a ich odpowiedzi niosą fakturę doświadczenia z terenu: anegdoty z pola walki, rozpoznawanie wzorców w stylu „widzimy to bez przerwy”, drobne przyznania się do tego, co jest trudne. Właśnie tę fakturę dopracowana sesja zeszlifowuje.

Problem w tym, że Apple opublikowało lab bez napisów. Aby w ogóle móc go cytować, trzeba było przepuścić nagranie przez lokalne rozpoznawanie mowy, co oznacza, że nazwy własne i pisownia API wychodzą z tego przybliżone. Każde twierdzenie techniczne zostało skonfrontowane z dokumentacją Apple lub odpowiadającą mu sesją WWDC, zanim podałem je jako fakt, a same słowa z labu zachowuję wyraźnie oznaczone jako parafraza. Ujęcie inżynierów należy traktować jako wiarygodne co do intencji i priorytetów, a cytaty jako źródło odniesienia co do szczegółów.

Historia danych z terenu: MetricKit jest przebudowywany

Yanni, który pracuje nad MetricKit, nazwał ten rok bardzo dużym dla frameworka i opisał gruntowną przebudowę wokół nowego API w pierwszej kolejności opartego na Swift. Podana przez niego motywacja: API Swift jest zbudowane pod Swift concurrency i zostało zaprojektowane z myślą o nowej ziarnistości danych, dzięki której deweloperzy otrzymują nie tylko dzienny raport metryk, lecz także drobniejsze rozbicia w krótszych przedziałach. Co kluczowe, zaznaczył, że nowe typy diagnostyki i metryk dostarczane są tylko w nowym API, co przedstawił jako prawdziwy powód do migracji.¹

Dokumentacja Apple potwierdza ostrzejszą krawędź tego twierdzenia. MXMetricManager, punkt wejścia, z którego deweloperzy korzystają od czasu pojawienia się MetricKit, jest teraz formalnie wycofany: strona referencyjna Apple oznacza go jako wycofany w 27.0 i kieruje deweloperów do używania MetricManager w zamian.² Sesja 222 z WWDC26 jasno wyraża tę wyłączność: nowe typy metryk i diagnostyki żyją w nowym API Swift i nie są przenoszone wstecz do starego.³ Jeśli nadal wywołujesz MXMetricManager, nie jesteś jedynie w starszym stylu — jesteś odcięty od wszystkiego, co Apple doda w przyszłości.

Lab ujawnił też powracające zamieszanie co do tego, skąd biorą się dane z terenu i jak je czytać. Kunal i Yanni wyraźnie wytyczyli granicę: Instruments daje głębokie lokalne profilowanie na jednym urządzeniu na biurku, podczas gdy Xcode Organizer i MetricKit dają zagregowaną telemetrię z terenu od prawdziwych użytkowników na prawdziwych urządzeniach. Te dwa źródła często się rozchodzą i właśnie ta rozbieżność jest sednem. Kunal opisał deweloperów ścigających zawieszenie, które potrafią odtworzyć w Instruments, podczas gdy Organizer pokazuje, że faktyczną główną przyczyną zawieszeń jest coś zupełnie innego — coś, czego nigdy nie da się odtworzyć przy biurku.¹

Nową dźwignią po stronie Organizera są Metric Goals. Kunal wskazał je jako tę jedną funkcję, którą najbardziej chciał, by deweloperzy wypróbowali przed wyjazdem z WWDC. Sesja 258 wyjaśnia, czym są: zalecane wartości docelowe, które Organizer wyprowadza „na podstawie podobieństw technicznych i funkcjonalnych między twoją aplikacją a innymi aplikacjami”, połączone z twoimi własnymi historycznymi punktami odniesienia, obejmujące czas uruchamiania, częstość zawieszeń, zapisy na dysk, baterię, pamięć masową oraz zacięcia.⁴ Lab ujął tę wartość w ludzkich kategoriach. Cole opisał dewelopera, który podnosi aplikację wideo i pyta, czy jej wysoki pobór mocy to problem, czy po prostu koszt odtwarzania wideo przez cały dzień. Przed Metric Goals nikt nie potrafił odpowiedzieć. Teraz Organizer porównuje cię z podobnymi aplikacjami i daje punkt odniesienia, od którego można rozumować.¹

Pojawił się jeszcze jeden element higieny danych z terenu i warto powiedzieć go wprost, bo deweloperzy wciąż się tu mylą: nie buduj własnego stopera uruchamiania. Lab przytoczył deweloperów badających API jądra w poszukiwaniu czasu utworzenia procesu i używających go jako punktu odniesienia dla uruchamiania. Odpowiedź Yanniego brzmiała, że MetricKit i Organizer celowo nie mierzą uruchamiania w ten sposób — mierzą przedział, który użytkownik faktycznie odczuwa. Dokumentacja Apple potwierdza tę definicję: czas uruchamiania to „liczba milisekund między dotknięciem przez użytkownika ikony a narysowaniem pierwszego ekranu”, mierzona po statycznym ekranie powitalnym.⁶ Twój własny stoper nie może zobaczyć momentu dotknięcia, ponieważ twój proces jeszcze nie istnieje. Narzędzia Apple potrafią to zrobić i nie dodają przy tym żadnego narzutu pomiarowego do twojej aplikacji.

Przepływ pracy dla energii, który zespół naprawdę zaleca

Najbardziej użyteczna wskazówka proceduralna z labu dotyczyła tego, jak wyłapać problemy z energią, które nigdy nie pojawiają się przy biurku. Kaspar i Kunal wracali wciąż do jednego przepływu pracy: bezprzewodowego śladu.

Mechanika, w ujęciu Kaspara, polega na odłączeniu się od Instruments, zarejestrowaniu na urządzeniu śladu, który może działać przez wiele godzin, a następnie udostępnieniu pliku na swojego Maca i otwarciu go w Instruments, by przeanalizować później. Korzyścią są warunki rzeczywiste: poruszasz się, doświadczasz prawdziwych przełączeń komórkowych, pozwalasz urządzeniu się nagrzać i przechwytujesz to, co faktycznie się dzieje, zamiast tego, co dzieje się w kontrolowanej sesji przy biurku. Kunal wskazał to jako sposób na wyłapanie konkretnej klasy błędów — zadań w tle zaplanowanych wtedy, gdy nie powinny być — które są niewidoczne, dopóki jesteś podłączony i obserwujesz.¹

Ten przepływ pracy to tryb Power Profiler w Performance Trace i warto być precyzyjnym co do jego pochodzenia: to funkcja iOS 26 z WWDC25, a nie nowość iOS 27. Apple dokumentuje ją pod hasłem „Measuring your app’s power use with Power Profiler”. Włączasz ją w Ustawienia > Deweloper > Performance Trace, uruchamiasz za pomocą kontrolki w Centrum sterowania, udostępniasz powstały plik .aar na swojego Maca i odczytujesz w Instruments pobór mocy z rozbiciem na podsystemy w torach CPU, GPU, wyświetlacza oraz sieci.⁵ Lab przedstawił ją jako zalecane rozwiązanie pierwszego wyboru, a nie jako nagłówek 27. (Prawdziwym nowym krewnym w tym roku jest przepływ kolekcji lookback oraz CLI macOS metalperftrace, które omówiłem w artykule o uczeniu maszynowym z Metal. To różne narzędzia do różnych zadań — nie należy ich mylić.)

Z dyskusji o energii warto zachować jeszcze dwie techniki:

• Tryb niskiego poboru mocy jako namiastka słabszego urządzenia. Terry zaproponował sztuczkę dla deweloperów, którzy posiadają tylko nowy sprzęt, ale muszą wiedzieć, jak aplikacja sprawuje się na starym sprzęcie: włącz tryb niskiego poboru mocy. Spowalnia on procesory, by oszczędzać baterię, co wydobywa problemy, które inaczej widziałbyś tylko na starszym urządzeniu. Dodał, że pełni to także rolę dobrej ogólnej praktyki optymalizacyjnej, ponieważ wielu użytkowników z wyboru korzysta z trybu niskiego poboru mocy, a twoja aplikacja powinna dobrze się tam sprawować.¹
• Device Conditions do symulacji termicznej i sieciowej. Lab wielokrotnie wspominał o „condition inducer”, służącym do wymuszenia na aplikacji podwyższonego stanu termicznego lub pogorszonego łącza sieciowego. Oficjalna nazwa tej funkcji w Apple to Device Conditions; sam mówca nie był pewien, gdzie znajduje się ona w Xcode 27. Historycznie mieściła się w oknie Devices i może zostać włączona do Device Hub. Mówca z labu uważał na to, co ta funkcja robi, a czego nie robi: sztucznie wywołuje zachowanie dławiące (throttling) gorącego urządzenia; nie rozgrzewa faktycznie sprzętu. Możesz więc zaobserwować, jak twoja aplikacja zachowuje się pod presją termiczną — więcej zacięć, więcej zawieszeń — bez pieczenia telefonu.¹

Oraz kategoryczna zasada, która padła nie raz: nigdy nie profiluj na Simulatorze. Kaspar zauważył, że Simulator działa na twoim Macu, więc jego wydajność nie mówi nic o wydajności urządzenia, niezależnie od tego, które urządzenie wybierzesz. Profiluj na fizycznym urządzeniu i opieraj się na danych z terenu z MetricKit i Organizera, by pokryć różnorodność urządzeń, której nie da się kupić.¹

Segregacja wydajności: przegrzewanie, rywalizacja z AI i praca dzielona na fragmenty

Gdy pytania skierowały się ku strategii segregacji (triage), wyróżniły się trzy wskazówki.

Podręcznik termiczny. Pewien deweloper zapytał o aplikację ARKit i Metal używaną na zewnątrz w bezpośrednim słońcu, gdzie urządzenie nieustannie się nagrzewa. Odpowiedź Kunala zaczęła się od API: nasłuchuj ProcessInfo.thermalState i wycofuj się z bogactwa doświadczenia, gdy wartość rośnie.¹ Konkretne dźwignie zaproponowane przez panel: żądaj lżejszych zasobów sieciowych, by urządzenie spędzało mniej czasu na dekodowaniu i parsowaniu, zamieniaj bogatsze animacje na prostsze oraz obniżaj liczbę klatek lub rozdzielczość renderowania pod presją. Kunal zauważył, że system w wyższych stanach termicznych już dławi liczbę klatek animacji i wyświetlacza, więc część ulgi przychodzi automatycznie, a swoją nakładasz na to z wierzchu. Końcowe słowa Marca w tej sprawie: wypychanie mniejszej liczby pikseli to mniej pracy, a „termodynamiki nie da się obejść”. Kontrolujesz obliczenia swojej aplikacji; nie kontrolujesz fizyki, więc optymalizuj ostro tę część, która należy do ciebie.¹

Model rywalizacji Apple Intelligence. Wnikliwe pytanie dotyczyło tego, jak iOS 27 ustala priorytety zadań w tle aplikacji, gdy system jest zajęty pracą Apple Intelligence. Odpowiedź Terry’ego była uspokajająca i konkretna: wiele funkcji Apple Intelligence działa na Neural Engine lub w Private Cloud Compute, więc jeśli twoja aplikacja używa CPU, podczas gdy obciążenie AI korzysta z Neural Engine, oba mogą często działać równolegle bez rywalizacji o ten sam zasób. Defensywny ruch, który zalecił, jest strukturalny: konfiguruj zadania w tle w małe fragmenty, aby system mógł je wstrzymywać i wznawiać, zamiast jednego monolitycznego zadania, które musi zaczynać od zera za każdym razem, gdy zostanie przerwane. Praca dzielona na fragmenty robi postępy nawet wtedy, gdy planista nie uruchamia cię tak często, jak byś chciał.¹

Liczność (cardinality) w StateReporting. Nowa funkcja StateReporting w MetricKit pozwala kroić metryki według stanu aplikacji, co jest potężne i łatwe do nadużycia. Lab podał jasną zasadę dotyczącą liczności: nie raportuj często zmieniających się dokładnych wartości, takich jak precyzyjna liczba elementów na liście. Zamiast tego pogrupuj je w przedziały — mały, średni, duży — aby móc później zapytać „czy w tym zakresie rozmiaru wydajność się pogorszyła?” bez ponoszenia kosztu rejestrowania każdej odrębnej liczby. Przykład Yanniego: lista 1000 elementów i lista 1001 elementów nie wnoszą żadnej istotnej różnicy, więc zapisywanie dokładnej liczby to czysty narzut. Zdefiniuj granice, które mają znaczenie dla twojej analizy, i raportuj przedział.

Co do samego uruchamiania, panel zbiegł się w jednym modelu myślowym, który spina porady o segregacji: ustal minimum danych potrzebnych do narysowania pierwszej klatki, wczytaj tylko to, a całą resztę odłóż. Terry przestrzegł przed częstym błędem polegającym na odpaleniu sterty pracy w tle, a następnie zablokowaniu głównego wątku do czasu, aż wszystko się zakończy, co zamraża całą aplikację podczas uruchamiania. Aby sprawdzić, czy to twój problem, Kaspar wskazał widok głównego wątku w szablonie System Trace, gdzie zablokowany główny wątek pokazuje się wprost. Panel opisał też, że System Trace wydobywa priorytety wątków, wywłaszczanie (preemption) oraz histogram przełączeń kontekstu; nie udało mi się jednak potwierdzić, że są to udokumentowane funkcje Instruments 27, więc potraktuj to jako opis narzędzia podany przez lab, a nie jako specyfikację.

Notatki o narzędziach: instrument Foundation Models i wejście dla początkujących

Lab dopełniają dwa punkty dotyczące narzędzi.

Dla deweloperów wdrażających funkcje Foundation Models Kaspar opisał, jak narzędzie Instruments urosło z zeszłorocznych prostych metryk liczby tokenów do pełnoprawnego instrumentu debugowania, który przechwytuje prompty i odpowiedzi oraz pokazuje, ile tokenów jest buforowanych.¹ Precyzyjny obraz w poprzek sesji WWDC26: instrument Foundation Models przechwytuje dane promptów i odpowiedzi z urządzenia przez cały czas trwania śladu (sesja 243, która zaznacza też, że przechwytywanie może obejmować informacje wrażliwe, więc w produkcji jest wyłączone).⁷ Liczby buforowanych tokenów przychodzą przez API usage w odpowiedziach modelu (sesja 241).⁸ Dwa różne mechanizmy — jeden dla osi czasu śladu, drugi dla rozliczania na poziomie pojedynczej odpowiedzi — warte rozróżnienia, gdy czytasz swoje liczby.

Dla początkujących panel był spójny co do tego, od czego zacząć. Marco zalecił Time Profiler z widokiem flame graph jako pierwsze podejście, ponieważ flame graph pokazuje wizualnie, ile kosztuje cię dany stos wywołań, zamiast zmuszać do odczytywania liczb w konspekcie. Kaspar dodał tryb Top Functions jako kolejny krok — płaską listę najcięższych funkcji, dzięki której można wychwycić winowajców jednym spojrzeniem, bez przemierzania głęboko zagnieżdżonego drzewa wywołań.¹ A najczęściej powtarzana metaporada panelu: mierz, zanim zoptymalizujesz. W ujęciu Kunala: najczęstszą pułapką jest niewystarczająca telemetria, która prowadzi deweloperów do optymalizowania obszarów nieprzynoszących żadnych realnych zysków. Wniosek Terry’ego co do uruchamiania i pracy w tle: żądanie sieciowe wysyłane o połowę rzadziej to darmowy zysk energetyczny. Spójrz na cały obraz, zanim zanurzysz się w którykolwiek pojedynczy podsystem.¹

Kluczowe wnioski

Dla deweloperów iOS wdrażających dziś: - Przejdź z MXMetricManager na nowe API Swift MetricManager. Stara powierzchnia jest wycofana od 27.0, a nowe typy metryk i diagnostyki są wyłączne dla nowego API.²³ - Otwórz Xcode Organizer i zestaw swoje Metric Goals z punktami odniesienia podobnych aplikacji dla uruchamiania, zawieszeń, baterii, zacięć, zapisów na dysk i pamięci masowej.⁴ - Przestań mierzyć uruchamianie własnym stoperem; MetricKit i Organizer mierzą od dotknięcia ikony, czego twój proces nie może zobaczyć.⁶

Dla segregacji wydajności i energii: - Użyj bezprzewodowego śladu Power Profiler (iOS 26, Ustawienia > Deweloper > Performance Trace), aby wyłapać problemy z zadaniami w tle i z energią w warunkach rzeczywistych, które nigdy nie odtwarzają się przy biurku.⁵ - Profiluj na fizycznym urządzeniu, nigdy na Simulatorze, i używaj trybu niskiego poboru mocy jako zastępnika starego sprzętu, którego nie posiadasz.¹ - Nasłuchuj ProcessInfo.thermalState i obniżaj liczbę klatek, rozdzielczość, bogactwo animacji oraz obciążenie sieci pod presją.¹

Dla zespołów budujących funkcje AI: - Dziel pracę w tle na fragmenty, aby planista mógł ją wstrzymywać i wznawiać; praca CPU często może działać równolegle z obciążeniami AI na Neural Engine i w Private Cloud Compute bez rywalizacji.¹ - Grupuj wartości StateReporting w przedziały (mały, średni, duży); nigdy nie raportuj szybko zmieniających się dokładnych liczb.¹ - Dla Foundation Models korzystaj z narzędzia Instruments do przechwytywania promptów i odpowiedzi (sesja 243) oraz pobieraj liczby buforowanych tokenów z API usage w odpowiedziach (sesja 241).⁷⁸

Ten lab łączy się naturalnie z głębszymi analizami w serii: MetricKit i StateReporting w iOS 27 o krojeniu metryk według stanu aplikacji, Instruments 27 a responsywność aplikacji o nowych przepływach porównywania (diffing) i wykrywania zawieszeń oraz martwy punkt wydajności o tym, dlaczego dane z terenu i profilowanie przy biurku się rozchodzą. Pełnym centrum serii jest Apple Ecosystem Series.

Bibliografia