Automatyzacja zrzutów ekranu: kompletny przewodnik po zasobach

Typowa premiera aplikacji mobilnej obejmuje 6–10 zrzutów ekranu na rozmiar urządzenia, w 4–8 rozmiarach urządzeń, w 8–20 językach. Matematyka szybko wymyka się spod kontroli: niewielka premiera to 200–800 zrzutów ekranu, a duża wielojęzyczna premiera może z łatwością przekroczyć 2000. Pierwsza wersja zajmuje projektantowi tydzień. Piąta wersja, po tym jak marketing przeszedł przez iteracje podpisów, też zajmuje projektantowi tydzień. Istnieje wyraźny moment, w którym żaden zespół o aktywnym tempie produktu nie nadąża już ręcznie.

Automatyzacja jest jedynym wyjściem. Gdy jesteś w stanie renderować pełną siatkę programowo, zamieniasz tydzień projektanta na wydanie na zadanie CI, które wykonuje się w 90 sekund. To właśnie odblokowuje pętlę o wysokiej prędkości, w której wypuszczasz zmiany w UI i aktualizacje sklepu w tym samym wydaniu — zamiast pozwalać, by zrzuty ekranu w sklepie permanentnie zostawały o kwartał lub więcej w tyle za działającą aplikacją.

Dojrzały potok ma cztery ruchome części: wersjonowane źródło prawdy (definicje szablonów w Git, zwykle jako YAML lub JSON), warstwę danych (ciągi tekstowe, zrzuty ekranu i obrazy produktu, które wypełniają szablony), silnik renderowania (usługa zamieniająca szablon i dane w wyjście PNG/JPEG w każdym wymaganym rozmiarze) oraz cel dostarczania (App Store Connect API, Google Play Publishing API lub bucket z zasobami, z którego korzysta zespół ofertowy). Każdą warstwę można wymieniać niezależnie.

Ciekawe decyzje projektowe pojawiają się na łączeniach. Jak wersjonujesz szablon? Czy renderowane wyjście trafia do repozytorium, czy regenerujesz je przy każdym uruchomieniu CI? Czy buforujesz rendery po haszu treści? Jak podglądasz zmiany podczas review PR bez uruchamiania pełnego potoku? Poniższe odnośniki omawiają każdą z tych kwestii dogłębnie.

W automatyzacji zrzutów ekranu istnieją dwa obozy architektoniczne: usługi renderowania API, które przyjmują specyfikację szablonu i produkują wyjście za pomocą zarządzanego silnika renderowania, oraz samodzielne potoki przeglądarek headless (Puppeteer, Playwright, Cypress), które robią zrzut ekranu strony i przetwarzają wynik. Oba podejścia działają; kompromisy są realne.

Potoki przeglądarek headless są elastyczne, ale ciężkie operacyjnie: utrzymujesz farmę przeglądarek, system zarządzania czcionkami, czcionki zastępcze dla każdego języka, logikę ponawiania dla zawodnych renderów oraz kolejkę. Renderowanie API zdejmuje to wszystko z barku, korzystając z usługi dostrojonej specjalnie do zastosowania zrzutów ekranu. Dla większości zespołów renderowanie API jest szybsze do skonfigurowania i szybsze w przeliczeniu na render; przeglądarki headless są właściwym wyborem, gdy zrzuty ekranu zawierają ciężkie elementy DOM lub funkcje CSS, których silnik szablonów nie potrafi odwzorować.

fastlane od ponad dekady pozostaje de facto łańcuchem narzędzi automatyzacji dla iOS i ma dwie istotne ścieżki dla zrzutów ekranu: wbudowaną akcję snapshot (która używa XCUITests do przechwytywania zrzutów ekranu z symulatora) oraz frameit (która opakowuje przechwycone zrzuty ekranu w ramki urządzeń). Dla testów na symulatorze to wciąż działa, ale ma ograniczenia: gramatyka projektowa jest zdeterminowana tym, co aplikacja potrafi wyrenderować w zautomatyzowanym UITeście, a nie tym, co zespół marketingu chce wypuścić, a język szablonów frameit jest ograniczony.

Nowoczesny wzorzec to używanie fastlane jako orkiestratora (uploady do App Store Connect, podbijanie wersji, dystrybucja przez TestFlight) i usługi renderowania API takiej jak Screenshots.live jako producenta właściwych plików zrzutów ekranu. fastlane ma pierwszorzędne wsparcie dla wtyczek, więc możesz dorzucić wtyczkę do zrzutów ekranu, która renderuje i przesyła je w tej samej ścieżce.

Trzy rozsądne wzorce. (1) Przy każdym pushu do main: regenerujesz zrzuty ekranu spekulatywnie, przechowujesz je jako artefakty buildu i awansujesz dopiero przy tagach wydań. Szybka informacja zwrotna, lekko marnotrawne. (2) Tylko przy tagach wydań: najczystsze, ale regresje zrzutów ekranu wychwytujesz dopiero po zablokowaniu wersji. (3) Na osobnym workflow tylko dla zrzutów ekranu, który uruchamia się, gdy zmieniają się pliki szablonów: najlepsze dla zespołów z silnym podziałem między inżynierią produktu a wzrostem.

Niezależnie od wybranego wzorca traktuj pliki zrzutów ekranu jak każdy inny generowany artefakt: nie wrzucaj ich do Git. Źródło prawdy żyje w szablonach, a nie w wyrenderowanych PNG-ach. To pojedynczy największy błąd, który zespoły popełniają, dokładając automatyzację zrzutów ekranu do istniejącego repozytorium.

Nowoczesny potok automatyzacji powinien obejmować sprawdzenia różnic pikseli lub haszy percepcyjnych na renderowanym wyjściu. Celem jest wychwycenie cichych awarii: czcionka, która spadła do zastępczej, tłumaczenie, które się przelało, zasób obrazu, który zwrócił 404. Narzędzia takie jak BackstopJS, Percy i Chromatic można przystosować do zrzutów ekranu w sklepie, albo można napisać małe zadanie diff, które zwraca błąd CI, gdy render przekracza próg.

To także moment, w którym wielojęzyczna automatyzacja staje się ciekawa: wyrenderowanie 60 zrzutów ekranu jest w porządku, ale ręczne sprawdzenie 60 pod kątem przepełnienia tekstu jest niemożliwe. To zautomatyzowane sprawdzenia wizualne sprawiają, że wielojęzyczna automatyzacja jest naprawdę bezpieczna na dużą skalę.