Skia w React Native daje coś, czego zwykłe widoki i proste SVG nie dowożą równie dobrze: szybki, precyzyjny rysunek 2D z animacjami, efektami i pełną kontrolą nad każdym elementem sceny. Ten tekst pokazuje, kiedy takie podejście ma sens, jak je uruchomić bez walki z konfiguracją oraz gdzie pojawiają się ograniczenia, które potrafią zaskoczyć nawet doświadczony zespół.
Najważniejsze rzeczy, które warto sprawdzić przed wdrożeniem
- To rozwiązanie dla grafiki 2D, a nie dla zwykłych ekranów formularzy czy list.
- Obecnie wymagane są React Native 0.79+ i React 19+, a na mobilnych platformach trzeba pilnować też wersji systemu.
- Najwięcej zysku daje przy niestandardowych wykresach, animacjach, shaderach, maskach i efektach wizualnych.
- Skia ma własny renderer, więc część mechanizmów z React Native nie działa tu automatycznie tak samo jak w zwykłym drzewie widoków.
- Na webie działa przez CanvasKit i to oznacza dodatkowy koszt pobrania oraz ładowania.
- Jeśli grafika jest prostsza niż problem, często szybciej i taniej wyjdzie SVG albo klasyczne komponenty React Native.
Co daje Skia w aplikacji mobilnej i kiedy ma sens
W praktyce traktuję Skia jako warstwę do zadań specjalnych. To nie jest kolejna biblioteka do ładniejszego paddingu czy prostszych kart, tylko narzędzie do rysowania, które pozwala wyjść poza standardowe komponenty mobilne i zbudować własny język wizualny: wykresy, wskaźniki, animowane tła, płynne przejścia, maski, gradienty, glassmorphism, a nawet bardzo dopracowane ekrany onboardingowe.
Najważniejsza różnica jest taka, że nie projektujesz już interfejsu wyłącznie z widoków i layoutu. Zaczynasz myśleć jak o scenie graficznej, w której każdy kształt, kolor, filtr i transformacja ma znaczenie. To daje dużą swobodę, ale też wymaga większej dyscypliny, bo łatwo zbudować efektowny ekran, który później trudno utrzymać albo zoptymalizować.
Ja sięgam po to rozwiązanie wtedy, gdy zwykły React Native zaczyna być zbyt sztywny, a SVG zbyt ograniczone. Jeśli potrzebujesz tylko ikonki, ilustracji albo prostego wykresu, nie ma sensu komplikować życia. Jeśli jednak projekt wymaga własnych efektów albo wysokiej płynności przy niestandardowych animacjach, Skia bardzo szybko pokazuje swoją wartość. To prowadzi już prosto do pytania, jak zacząć bez niepotrzebnych tarć.
Jak zacząć bez walki z konfiguracją
Dokumentacja Shopify podaje dziś konkretny próg wejścia: React Native 0.79+, React 19+, na iOS przynajmniej 14, a na Androidzie API 21 lub wyżej. Jeśli pracujesz ze starszym stosem, trzeba zostać przy @shopify/react-native-skia w wersji 1.12.4 lub niższej. To ważne, bo wiele osób zakłada, że wystarczy doinstalować paczkę i reszta „sama się ułoży”, a potem trafia na problemy wersjonowania.
| Obszar | Co warto wiedzieć |
|---|---|
| React Native | Wymagana jest wersja 0.79 lub nowsza |
| React | Wymagana jest wersja 19 lub nowsza |
| iOS | Minimum iOS 14 |
| Android | Minimum API 21, a dla obsługi wideo API 26 |
| Starsze projekty | RN 0.78 i React 18 wymagają starszej gałęzi biblioteki |
| Expo | Najprościej zacząć od szablonu with-skia |
W nowym projekcie najkrótsza droga wygląda tak:
yarn add @shopify/react-native-skiaJeśli startujesz w Expo, sensowniejszy bywa gotowy szablon:
npx create-expo-app my-app -e with-skiaW bare workflow trzeba pamiętać o pod install na iOS oraz o Android NDK po stronie Androida. Dobra wiadomość jest taka, że nie ma tu osobnego skryptu postinstall do pilnowania i nie trzeba kombinować z dodatkowymi zgodami dla menedżerów pakietów. To upraszcza utrzymanie, zwłaszcza w większych repozytoriach.
Jeśli projekt ma wspierać też web, warto zaplanować to od początku, bo w przeglądarce Skia ładuje się przez CanvasKit i nie jest to koszt zerowy. Gdy masz już środowisko pod kontrolą, można przejść do tego, jak w praktyce buduje się samą scenę.
Jak zbudować scenę na canvasie
Podstawą jest Canvas, czyli korzeń całego rysunku. To on zastępuje klasyczne drzewo widoków i pozwala myśleć o UI jak o kompozycji graficznej, a nie liście elementów ekranowych. Skia używa własnego renderera React, więc komponenty rysujące działają w swoim świecie i nie należy zakładać, że wszystko z aplikacji będzie dostępne automatycznie wewnątrz tego drzewa.
Najczęściej pracuję z kilkoma elementami budulcowymi:
- Shapes jak Circle, Rect, Path, Ellipse czy Polygon, gdy potrzebuję prostych i czytelnych form.
- Group, kiedy chcę zastosować transformacje, clipping, wspólne właściwości malowania albo efekty warstwowe.
- Paint i style, gdy zależy mi na kolorze, przezroczystości, trybie mieszania lub obrysie.
- Text przez API Paragraph, jeśli tekst ma być częścią precyzyjnej kompozycji graficznej, a nie zwykłym komponentem UI.
- Images i SVG, gdy chcę osadzić grafikę rastrową albo wektorową w tej samej scenie.
Minimalny przykład wygląda zwykle bardzo prosto:
import React from "react";
import { Canvas, Circle, Group } from "@shopify/react-native-skia";
export function Badge() {
return (
);
}Ten przykład wygląda banalnie, ale dobrze pokazuje sposób myślenia: zamiast budować ekran z kolejnych kontenerów, układasz warstwy i kształty. W bardziej złożonych interfejsach dochodzą jeszcze gradienty, maski, filtry rozmycia i niestandardowe efekty świetlne, które w zwykłym RN byłyby dużo trudniejsze do uzyskania. Gdy scena już działa, naturalnie pojawia się pytanie o animacje i wydajność.
Animacje, które naprawdę odciążają interfejs
Jedna z najmocniejszych stron Skia to połączenie z Reanimated v3+. Zamiast opakowywać komponenty w dodatkowe warstwy, można przekazywać wartości shared i derived bezpośrednio jako właściwości rysunku. To upraszcza kod i zmniejsza liczbę miejsc, w których synchronizacja między JS a UI threadem mogłaby się rozjechać.
W praktyce oznacza to, że dobrze wychodzą tu animowane wykresy, ringi postępu, pulsujące przyciski, dynamiczne gradienty, przejścia stanów czy efekty typu parallax. Jeśli animacja ma wpływać na wygląd elementu graficznego, a nie na cały układ aplikacji, to bardzo często jest to właściwe miejsce na Skia.
Warto jednak pamiętać o jednym rozróżnieniu. Retained mode sprawdza się wtedy, gdy scena jest względnie stała, a zmieniasz głównie wartości jej właściwości. Jeśli natomiast co klatkę generujesz zmienną liczbę komend rysowania, lepsza może być Picture API, czyli podejście bliższe immediate mode. To ma znaczenie w bardziej złożonych dashboardach, edytorach albo rysunkach generowanych dynamicznie.
To jest też miejsce, w którym wielu zespołów popełnia ten sam błąd: zakładają, że samo przeniesienie rysunku do Skia naprawi każdą wydajność. Nie naprawi, jeśli nadal produkujesz zbyt wiele obiektów na każdą klatkę albo przerabiasz całe drzewo bez potrzeby. Skia pomaga, ale nie zastępuje sensownej architektury. Po animacjach dobrze więc spojrzeć na to, gdzie leży granica między Skia, SVG i zwykłymi widokami.
Skia, SVG czy zwykłe widoki React Native
To porównanie warto zrobić bardzo chłodno, bo w praktyce największy błąd polega na używaniu cięższych narzędzi tam, gdzie prostsze rozwiązanie byłoby lepsze. Ja zwykle rozbijam to na trzy poziomy: standardowy React Native dla układu i treści, SVG dla prostych wektorów, a Skia dla przypadków, w których liczy się kontrola, płynność i niestandardowy rendering.
| Rozwiązanie | Najlepiej sprawdza się | Mocne strony | Ograniczenia |
|---|---|---|---|
| Skia | Wykresy, animacje, efekty, własne komponenty wizualne | Duża kontrola, dobra płynność, efekty i shaderowe możliwości | Większa złożoność, dodatkowy koszt rozmiaru aplikacji |
| SVG | Ikony, ilustracje, logo, proste grafiki wektorowe | Łatwe wdrożenie, czytelny model pracy, lekki próg wejścia | Słabsze przy bardzo złożonych animacjach i efektach |
| Standardowe widoki RN | Layout, formularze, treść, klasyczne ekrany aplikacji | Najszybsze w utrzymaniu, naturalne dla zespołu mobile | Mała elastyczność w niestandardowym renderingu |
Jeśli budujesz prosty landing w aplikacji albo ekran z kilkoma ikonami, SVG będzie rozsądniejszy. Jeśli projektujesz rozbudowany pulpit z metrykami albo efektowne przejścia między stanami, Skia zaczyna mieć wyraźną przewagę. A jeśli chodzi tylko o to, żeby ekran był czytelny i szybki, zwykły React Native nadal wygrywa czasem wdrożenia i prostotą utrzymania. Tę decyzję trzeba dopasować do ograniczeń, bo właśnie tam najczęściej pojawiają się niespodzianki.
Ograniczenia, o których lepiej wiedzieć wcześniej
W dokumentacji Shopify podawany jest dość konkretny koszt wejścia: około 4 MB dodatkowego rozmiaru na Androidzie i około 6 MB na iOS, a na webie dochodzi jeszcze 2,9 MB gzipped dla CanvasKit. To nie jest dramat, ale przy aplikacji, która ma ostro walczyć o czas instalacji i wczytania, trzeba to uwzględnić już na etapie decyzji produktowej.
Drugi ważny punkt to osobny renderer React. Oznacza to, że kontekst Reacta nie przechodzi do rysunku tak, jak wiele osób intuicyjnie zakłada. Jeśli więc chcesz korzystać z danych aplikacji w samym canvasie, lepiej przygotować je wcześniej albo jawnie wstrzyknąć ponownie. To drobiazg, który w praktyce potrafi wywołać zaskakująco dużo błędów, jeśli zespół nie ma doświadczenia z takim modelem pracy.
Na webie warto liczyć się z tym, że CanvasKit ładuje się asynchronicznie. To dobrze, bo daje kontrolę nad doświadczeniem użytkownika, ale oznacza też, że trzeba pomyśleć o strategii ładowania, fallbackach i ewentualnym opóźnianiu cięższych ekranów. Dodatkowo, jeśli aplikacja korzysta z wideo, Android wymaga API 26 lub nowszego. W testach też nie przechodzisz przez to bez przygotowania, bo środowisko Jest wymaga dedykowanego setupu, a nie zwykłego mockowania komponentów RN.
Najkrócej mówiąc, Skia daje dużo kontroli, ale za tę kontrolę płaci się większą odpowiedzialnością za środowisko, rozmiar aplikacji i architekturę renderowania. Właśnie dlatego w kolejnym kroku warto ułożyć sobie prostą zasadę decyzji, zamiast wdrażać ją „na wszelki wypadek”.
Jak podejść do tego rozsądnie w projekcie
Gdy planuję użycie tej biblioteki, zaczynam od jednego pytania: czy problem faktycznie dotyczy grafiki, czy tylko estetyki? Jeśli chodzi o estetykę, zwykle wystarczy prostsze narzędzie. Jeśli chodzi o precyzyjny rendering, własną kompozycję efektów albo płynność animacji przy skomplikowanym UI, wtedy Skia przestaje być dodatkiem i staje się uzasadnioną decyzją techniczną.
- Zacznij od jednego ekranu pilotażowego, a nie od przebudowy całej aplikacji.
- Testuj na średnich i słabszych urządzeniach, bo tam różnica między „działa” a „działa dobrze” jest najbardziej widoczna.
- Sprawdź od razu, czy web jest realnym wymaganiem, bo wtedy dochodzi osobna ścieżka ładowania i dodatkowy koszt.
- Nie przenoś do canvasu tego, co równie dobrze działa jako zwykły komponent UI.
- Traktuj animacje jako część projektu technicznego, a nie tylko wizualną ozdobę.
Jeśli miałbym ująć to praktycznie, to zacząłbym od prostego prototypu: jeden canvas, jeden animowany element, jeden efekt graficzny. Dopiero potem sprawdzałbym, czy warto dokładać tekst, gradienty, maski, shader albo bardziej rozbudowaną logikę rysowania. Taki porządek zwykle oszczędza więcej czasu niż najbardziej ambitny plan od pierwszego dnia, bo pozwala szybko odróżnić realną przewagę od efektu „wow”.
