Screengrab (Fastlane) — co to jest, możliwości i automatyzacja zrzutów ekranu

Czym jest Screengrab i do czego służy

Screengrab — to komponent ekosystemu Fastlane przeznaczony do automatycznego tworzenia zrzutów ekranu aplikacji mobilnych. Narzędzie pojawiło się w 2015 roku jako odpowiedź na problem: do publikacji w Google Play i App Store wymagane jest od 4 do 10 zrzutów ekranu na każdy język. Przy obsłudze 30 języków daje to 120–300 ręcznie wykonanych zdjęć.

Problem ręcznego tworzenia zrzutów ekranu

Programista ręcznie uruchamia aplikację na symulatorze lub urządzeniu, przewija do potrzebnego ekranu, wykonuje zrzut ekranu, przenosi go na komputer, przycina i zapisuje w odpowiednim folderze. Procedura jest powtarzana dla każdego języka i każdej orientacji. Według Google Play Console, przeciętna aplikacja aktualizuje się co dwa tygodnie, co zamienia zrzuty ekranu w regularną rutynę.

Zalety automatyzacji

Screengrab rozwiązuje problem radykalnie: programista opisuje scenariusze testów w frameworku UI (Espresso dla Androida, XCTest dla iOS), a Screengrab uruchamia je na wszystkich potrzebnych urządzeniach i językach automatycznie. Fastlane koordynuje proces: kompiluje build, uruchamia testy, zbiera zrzuty ekranu i pakuje je w odpowiednią strukturę folderów.

Rezultat — sto zrzutów ekranu w 10–15 minut zamiast kilku godzin ręcznej pracy. Google zaleca aktualizowanie zrzutów ekranu przy każdej znaczącej zmianie interfejsu, a bez automatyzacji ta rekomendacja jest często ignorowana.

Jak działa Screengrab: architektura i zasada działania

Architektura Screengrab jest zbudowana wokół dwóch kluczowych komponentów: klienta na urządzeniu (screengrab-lib) i runnera, który zarządza uruchamianiem testów i zbieraniem wyników. Na Androidzie używany jest framework testów instrumentalnych, na iOS — XCTest.

Cykl życia jednego uruchomienia

Fastlane wywołuje akcję screengrab, która odczytuje plik konfiguracyjny Screengrabfile. Runner kompiluje testowy APK z podłączoną biblioteką screengrab-lib, instaluje go na podłączonych urządzeniach lub emulatorach i uruchamia testy UI oznaczone adnotacjami do zrzutów ekranu.

# Fastfile — opis lane dla zrzutów ekranu
lane :screenshots do
  capture_android_screenshots(
    output_directory: "fastlane/metadata/android/screenshots",
    locales: ["ru-RU", "en-US", "de-DE"],
    devices: ["pixel_6", "pixel_tablet"],
    use_tests_external_storage: true
  )
end

Struktura plików wyjściowych

Screengrab tworzy hierarchię folderów: język → urządzenie → zrzuty ekranu. Struktura w pełni odpowiada wymaganiom Google Play Console i App Store Connect. App Store wymaga ściśle określonych rozmiarów dla każdego typu urządzenia, a Screengrab generuje zrzuty dokładnie według specyfikacji.

Obsługa wielu urządzeń

Narzędzie potrafi uruchamiać testy równolegle na wszystkich podłączonych urządzeniach i emulatorach. Emulatory Androida uruchamiają się automatycznie, jeśli nie są aktywne. Dla iOS Screengrab używa symulatorów Xcode.

Instalacja i konfiguracja Screengrab dla Androida

Instalacja Screengrab składa się z dwóch części: dodania biblioteki do projektu i konfiguracji pliku konfiguracyjnego. Na Androidzie potrzebny jest framework UI Espresso i biblioteka screengrab-lib z repozytorium Fastlane.

Dodawanie zależności

W build.gradle modułu aplikacji dodawana jest zależność screengrab-lib. Biblioteka dostarcza klasę ScreenCapturer, która wykonuje zrzut ekranu w momencie wywołania.

// build.gradle (moduł: app)
androidTestImplementation(
  'tools.fastlane:screengrab-lib:2.1.0'
)

Pisanie testu ze zrzutami ekranu

Test UI jest oznaczany adnotacją Screengrab.screenshot() w odpowiednich punktach. Każde wywołanie wykonuje zrzut aktualnego ekranu i zapisuje go z podaną nazwą.

import tools.fastlane.screengrab.Screengrab
import tools.fastlane.screengrab.locale.LocaleTestRule

class ScreenshotTest {

    @get:Rule
    val localeTestRule = LocaleTestRule()

    @Test
    fun testTakeScreenshots() {
        Screengrab.screenshot("main_screen")
        // Akcje: kliknij przycisk logowania
        Screengrab.screenshot("login_screen")
    }
}

Konfiguracja Screengrabfile

Plik Screengrabfile przechowuje parametry uruchomienia: listę urządzeń, języki, limity czasu i ścieżkę zapisu. Plik zwykle znajduje się w folderze fastlane obok Fastfile.

Lokalizacja zrzutów ekranu i wiele języków

Lokalizacja — kluczowa możliwość Screengrab, dla której najczęściej jest wybierany. Narzędzie automatycznie przełącza język aplikacji przed każdym uruchomieniem testów i wykonuje zrzuty we wszystkich wskazanych językach.

Konfiguracja języków

Języki są określane w Screengrabfile parametrem locales. Dla każdego języka Screengrab ponownie instaluje aplikację z odpowiednimi zasobami i uruchamia pełny cykl testów. LocaleTestRule na Androidzie automatycznie przełącza lokalizację urządzenia.

# Screengrabfile
locales [
  "ru-RU",
  "en-US",
  "de-DE",
  "fr-FR",
  "es-ES",
  "ja-JP",
  "ko-KR"
]

Struktura folderów dla zlokalizowanych zrzutów ekranu

Screengrab tworzy katalogi według schematu: screenshots/{locale}/{device_name}/{screenshot_name}.png. Ta struktura jest zgodna z wymaganiami Google Play, co pozwala na przesyłanie zrzutów ekranu przez Fastlane deliver jedną komendą.

Dla iOS App Store Connect oczekuje zrzutów ekranu w płaskiej strukturze według języków. Fastlane automatycznie konwertuje hierarchię Screengrab do odpowiedniego formatu podczas publikacji.

Integracja Screengrab z pipeline'em CI/CD

CI/CD — integracja to jedna z głównych zalet Screengrab. Narzędzie uruchamia się z wiersza poleceń i nie wymaga interfejsu graficznego, co czyni je idealnym do kompilacji serwerowych.

GitHub Actions

W środowisku CI należy uruchomić emulator Androida lub symulator iOS, a następnie wywołać lane ze zrzutami ekranu. GitHub Actions obsługuje cachowanie AVD, co przyspiesza kolejne uruchomienia.

Parametry dla CI

W konfiguracji CI ważne jest uwzględnienie ograniczeń pamięci i czasu. Emulatory Androida wymagają co najmniej 2 GB RAM na urządzenie, a pełne uruchomienie na 7 językach i 2 urządzeniach zajmuje 20–40 minut.

# Fastfile — lane dla CI z limitami czasu
lane :ci_screenshots do
  capture_android_screenshots(
    locales: ["en-US", "ru-RU"],
    devices: ["pixel_6"],
    clear_previous_screenshots: true,
    tests_timeout: "600",
    output_directory: "screenshots/ci"
  )
end

Jenkins Pipeline

Dla Jenkinsa używany jest krok sh z wywołaniem bundle exec fastlane. Zaleca się uruchamianie zrzutów ekranu w nocy lub po triggerze po merge'u do głównej gałęzi, aby nie spowalniać cyklu programistycznego.

Screengrab vs alternatywy: porównanie narzędzi

Screengrab — nie jedyne narzędzie do automatyzacji zrzutów ekranu. Istnieją alternatywy z różnymi podejściami: wbudowane narzędzia systemu operacyjnego, komercyjne platformy i biblioteki do zrzutów ekranu w kodzie.

ADB Shell daje pełną kontrolę, ale wymaga pisania skryptów dla każdego scenariusza. XCTest jest wbudowany w Xcode, ale nie zarządza lokalizacją automatycznie. Firebase Test Lab uruchamia testy na rzeczywistych urządzeniach w chmurze, co daje maksymalne pokrycie, ale wymaga opłat za każdą minutę.

Screengrab wygrywa dzięki połączeniu: Fastlane zarządza całym cyklem życia kompilacji — od kompilacji do publikacji. Google Play bezpośrednio przyjmuje strukturę folderów Screengrab przez Fastlane deliver.

Typowe problemy i ich rozwiązania

Podczas pracy z Screengrab programiści najczęściej spotykają się z kilkoma powtarzającymi się problemami. Znajomość typowych błędów skraca czas debugowania przy pierwszym uruchomieniu.

Zrzuty ekranu są puste lub czarne

Problem występuje, gdy Screengrab wykonuje zrzut przed zakończeniem renderowania ekranu. Rozwiązanie — dodać opóźnienie Thread.sleep() przed wywołaniem screenshot() lub użyć IdlingResource z Espresso do oczekiwania na operacje asynchroniczne.

Błąd niezgodności wersji

Biblioteka screengrab-lib musi odpowiadać wersji Fastlane. Fastlane aktualizuje się co miesiąc, a stara biblioteka może nie obsługiwać nowych parametrów konfiguracji. Rozwiązanie — zsynchronizować wersje przez Gemfile i gradle.properties.

Długi czas uruchomienia w CI

Uruchomienie na 30 językach na 5 urządzeniach może zajmować ponad godzinę. Rozwiązanie — podzielić uruchomienia: jedno dla sklepu na wszystkich językach, drugie do potrzeb wewnętrznych na dwóch językach. GitHub Actions pozwala używać macierzy strategii do równoległych uruchomień.

Problemy z emulatorem w CI

Emulator Androida wymaga wirtualizacji sprzętowej, która nie zawsze jest dostępna na serwerach CI. KVM musi być włączony, w przeciwnym razie emulator nie uruchamia się. Rozwiązanie — używać obrazów x86 bez akceleracji GPU lub Firebase Test Lab.