React Native 0.82 - Nowa Era

Nieoficjalne Tłumaczenie Beta

Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt. Znalazłeś błąd? Zgłoś problem →

Z dumą ogłaszamy wydanie React Native 0.82: pierwszej wersji React Native działającej w całości na Nowej Architekturze.

To kamień milowy dla React Native i wierzymy, że rozpoczyna on nową erę. W przyszłych wersjach usuniemy pozostały kod Architektury Legacy, aby zmniejszyć rozmiar instalacji i uprościć bazę kodu.

Dodatkowo wersja 0.82 zawiera eksperymentalną opcję użycia nowszej wersji Hermesa o nazwie Hermes V1. Włączamy również kilka funkcji Reacta poprzez aktualizację do wersji React 19.1.1 oraz dodajemy obsługę API węzłów DOM.

Najważniejsze zmiany

• Tylko Nowa Architektura

• Eksperymentalny Hermes V1

• React 19.1.1

• API węzłów DOM

Tylko Nowa Architektura

W React Native 0.76 ogłosiliśmy, że Nowa Architektura stała się domyślną architekturą React Native.

Od tego czasu Nowa Architektura została przetestowana i udoskonalona, dlatego z pełnym przekonaniem czynimy ją jedyną architekturą w tej i przyszłych wersjach React Native.

Oznacza to, że próba ustawienia newArchEnabled=false na Androida lub instalacja CocoaPods z RCT_NEW_ARCH_ENABLED=0 na iOS zostaną zignorowane - aplikacja nadal będzie działać na Nowej Architekturze.

Jak przeprowadzić migrację

Jeśli nie migrowałeś jeszcze projektu na Nową Architekturę, zalecamy najpierw migrację do React Native 0.81 lub Expo SDK 54. To ostatnie wersje umożliwiające korzystanie z Architektury Legacy. Zawierają one ostrzeżenia i optymalizacje wydajnościowe specjalnie zaprojektowane, aby ułatwić przejście na Nową Architekturę.
Następnie włącz Nową Architekturę w wersji 0.81 i zweryfikuj poprawność działania aplikacji.
Gdy już korzystasz z Nowej Architektury w wersji 0.81, możesz bezpiecznie zaktualizować do React Native 0.82, który uniemożliwia włączenie Architektury Legacy.

Jeśli migrację blokuje niezgodna zależność strony trzeciej, zalecamy bezpośredni kontakt z maintainerami biblioteki.

Jeśli migrację blokuje błąd w rdzeniu React Native, zachęcamy do kontaktu poprzez nasz issue tracker.

Warstwy interoperacyjności i kompatybilność bibliotek 3P

Warstwy interoperacyjności pozostaną w bazie kodu w przewidywalnej przyszłości. Wszystkie klasy i funkcje wymagane przez te warstwy nie zostaną usunięte w najbliższym czasie. O dalszych planach usuwania Warstw Interoperacyjności poinformujemy w przyszłości.

Potwierdziliśmy również, że biblioteki stron trzecich oferujące wsteczną kompatybilność z obiema architekturami będą nadal działać z wersją 0.82, gdzie Nowa Architektura jest jedyną dostępną.

Usuwanie klas Architektury Legacy

Aby zapewnić kompatybilność wsteczną i ograniczyć łamanie zmian, nie usuwamy w tej wersji żadnych API Architektury Legacy z rdzenia React Native. Usunięcie Architektury Legacy pozwoli znacząco zmniejszyć całkowity rozmiar paczki, dlatego proces usuwania rozpocznie się od następnej wersji React Native.

Więcej informacji można znaleźć w RFC0929: Usunięcie starszej architektury React Native.

Eksperymentalny Hermes V1

React Native 0.82 dodaje obsługę eksperymentalnej wersji Hermes V1.

Hermes V1 to kolejny etap ewolucji Hermesa. Testowaliśmy go wewnętrznie w naszych aplikacjach i teraz nadszedł czas, aby społeczność również go wypróbowała. Zawiera ulepszenia kompilatora i maszyny wirtualnej, które zwiększają wydajność Hermesa.

Z wstępnych testów i benchmarków wynika, że Hermes V1 przewyższa obecną wersję Hermesa w różnych scenariuszach. Zaobserwowaliśmy poprawę w czasie ładowania pakietów i TTI (czas do interaktywności). Stopień poprawy zależy w dużej mierze od specyfiki aplikacji.

W przypadku aplikacji Expensify — rzeczywistej i złożonej aplikacji — zaobserwowaliśmy następujące poprawy:

Metric	Android (low end device)	iOS
Bundle Load Time	3.2% faster	9% faster
Total TTI	7.6% faster	2.5% faster
Content TTI	7.2% faster	7.5% faster

Dla Total TTI mierzyliśmy czas od załadowania pakietu do momentu wyrenderowania pierwszej ekranu w aplikacji i osiągnięcia przez nią interaktywności.

Dla Content TTI mierzyliśmy czas potrzebny na osiągnięcie interaktywności komponentu, licząc od pierwszego wyrenderowania danego komponentu.

Hermes V1 nie zawiera jeszcze kompilacji JS-to-native (wcześniej znanej jako „Static Hermes”) ani kompilacji JIT, która została zaprezentowana podczas React Native EU 2023. Nadal testujemy te funkcje i podzielimy się więcej informacjami w miarę postępów.

Jak włączyć Hermes V1

informacja

Ponieważ Hermes V1 jest w fazie eksperymentalnej, aby go wypróbować, należy zbudować React Native ze źródeł. Gdy Hermes V1 stanie się domyślną wersją w przyszłej wersji React Native, to ograniczenie zostanie zniesione.

Aby wypróbować Hermes V1 we własnym projekcie, wykonaj następujące kroki:

1. Wymuś, aby menedżer pakietów rozpoznał eksperymentalną wersję pakietu kompilatora Hermes V1, modyfikując odpowiednią sekcję pliku package.json (obecna konwencja wersjonowania obowiązuje tylko w fazie eksperymentalnej Hermes V1):

yarn

"resolutions": {
    "hermes-compiler": "250829098.0.1"
}

npm

"overrides": {
    "hermes-compiler": "250829098.0.1"
}

2. Włącz Hermes V1 dla Androida, dodając hermesV1Enabled=true w pliku android/gradle.properties:

android/gradle.properties

hermesV1Enabled=true

Dodatkowo skonfiguruj React Native do budowania ze źródeł, edytując plik android/settings.gradle:

android/settings.gradle

  includeBuild('../node_modules/react-native') {
      dependencySubstitution {
          substitute(module("com.facebook.react:react-android")).using(project(":packages:react-native:ReactAndroid"))
          substitute(module("com.facebook.react:react-native")).using(project(":packages:react-native:ReactAndroid"))
          substitute(project(":packages:react-native:ReactAndroid:hermes-engine")).using(module("com.facebook.hermes:hermes-android:250829098.0.1"))
      }
  }

3. Włącz Hermes V1 dla iOS, instalując pody z ustawioną zmienną środowiskową RCT_HERMES_V1_ENABLED=1.

RCT_HERMES_V1_ENABLED=1 bundle exec pod install

Należy pamiętać, że Hermes V1 nie jest kompatybilny z prekompilowanymi wersjami React Native, dlatego upewnij się, że nie używasz flagi RCT_USE_PREBUILT_RNCORE podczas instalacji podów.

4. Aby potwierdzić, czy twoja aplikacja używa Hermes V1, wykonaj następujący kod w konsoli aplikacji lub DevTools. Kod ten zwróci wersję Hermesa, która powinna odpowiadać wersji określonej w kroku 1 (250829098.0.1):

// expecting "250829098.0.1" in Hermes V1
HermesInternal.getRuntimeProperties()['OSS Release Version'];

React 19.1.1

Ta wersja React Native zawiera najnowszą stabilną wersję Reacta: React 19.1.1.

Ta wersja Reacta zawiera pełne wsparcie dla tzw. owner stacks w React Native. Wcześniej, w React Native 0.80, kiedy dodaliśmy obsługę wersji 19.1.0, wspomnieliśmy, że owner stacks nie były w pełni obsługiwane w przypadku używania wtyczki Babel @babel/plugin-transform-function-name. Ta wersja znosi to ograniczenie i umożliwia korzystanie z owner stacks wszystkim użytkownikom React Native.

BEFORE	AFTER

React 19.1.1 poprawia również niezawodność useDeferredValue i startTransition w granicach Suspense dla React Native. Te kluczowe funkcje Reacta, zaprojektowane w celu zwiększenia responsywności aplikacji, wcześniej błędnie wyświetlały komponent zastępczy (fallback) przy użyciu razem z granicą Suspense w React Native. W React 19.1.1 działają one zgodnie z oczekiwaniami w React Native, dostosowując swoje zachowanie do tego znanego ze środowiska webowego.

Interfejsy API węzłów DOM

Począwszy od React Native 0.82, natywne komponenty będą udostępniać węzły podobne do DOM przez refy.

Wcześniej natywne komponenty dostarczały obiekty specyficzne dla React Native z ograniczonymi metodami takimi jak measure czy setNativeProps. Po tym wydaniu będą udostępniać węzły implementujące podzbiór interfejsu DOM do nawigacji po drzewie UI, pomiaru układu i innych operacji znanych ze środowiska webowego. Przykład:

function MyComponent(props) {
  const ref = useRef();

  useEffect(() => {
    const element = ref.current;

    // New methods
    element.parentNode;
    element.parentElement;
    element.childNodes;
    element.children;
    const bounds = element.getBoundingClientRect();
    const doc = element.ownerDocument;
    const maybeElement = doc.getElementById('some-view');

    // Legacy methods are still available
    element.measure((x, y, width, height, pageX, pageY) => {
      /* ... */
    });
  }, []);

  return <View ref={ref} />;
}

Dodatkowo, będzie to umożliwiać dostęp do liściowych węzłów tekstowych (tworzonych przez komponent Text) oraz węzłów dokumentu reprezentujących główne węzły React Native.

Jest to zmiana wstecznie kompatybilna, ponieważ nowe węzły nadal będą implementować starsze metody (takie jak measure).

Więcej informacji można znaleźć w naszej dokumentacji.

Inne zmiany

Interfejsy API wydajności Web (Canary)

React Native implementuje teraz podzbiór interfejsów API wydajności dostępnych w środowisku webowym:

• High Resolution Time: definiuje performance.now() i performance.timeOrigin.

• Performance Timeline: definiuje PerformanceObserver oraz metody dostępu do wpisów wydajności w obiekcie performance (getEntries(), getEntriesByType(), getEntriesByName()).

• User Timing: definiuje performance.mark i performance.measure.

• Event Timing API: definiuje typy wpisów event raportowane do PerformanceObserver.

• Long Tasks API: definiuje typy wpisów longtask raportowane do PerformanceObserver.

Umożliwiają śledzenie różnych aspektów wydajności aplikacji w czasie rzeczywistym (dla telemetrii) i będą widoczne w panelu wydajności w React Native DevTools (dostępne w przyszłej wersji React Native).

Obecnie są dostępne tylko na poziomie wydania canary, a jako stabilne zostaną wydane w przyszłej wersji React Native.

Zoptymalizowany typ buildu debug dla Androida

Począwszy od React Native 0.82, będzie można używać typu buildu debugOptimized, aby przyspieszyć proces rozwoju aplikacji.

Dotychczas Android tworzył dwa domyślne warianty buildów:

• debug, używany domyślnie podczas rozwoju, który umożliwia łączenie się z różnymi narzędziami debugującymi, takimi jak React Native DevTools, Metro, debuger JVM Androida oraz debuger C++

• release, używany podczas publikowania aplikacji do produkcji. Jest w pełni zoptymalizowany, z zastosowaniem zaciemniania i optymalizacji, co utrudnia debugowanie.

Ponieważ większość programistów React Native nie będzie potrzebować używać debugera C++ podczas rozwoju, wprowadziliśmy typ buildu debugOptimized.

Dzięki debugOptimized animacje i ponowne renderowanie będą szybsze, ponieważ uruchamiasz build React Native z włączonymi kilkoma optymalizacjami C++. Jednocześnie nadal będzie można używać React Native Dev Tools do debugowania kodu JavaScript.

Podczas używania debugOptimized nie będzie można korzystać z natywnych debugerów C++, ale nadal będzie to możliwe w przypadku użycia typu buildu debug.

Aby uruchomić wariant debugOptimized dla swojej aplikacji, wywołaj:

Community CLI

npx react-native run-android --mode debugOptimized

Expo

npx expo run:android --variant debugOptimized

informacja

Typ buildu debugOptimized został również przeniesiony do React Native 0.81 i Expo SDK 54.

Można zobaczyć debugOptimized w działaniu w tych przykładach, w których renderujemy kilka animacji na ekranach.

Build uruchomiony z debug działa z ~20 klatkami na sekundę, a ten z debugOptimized osiąga ~60 klatek na sekundę:

debug	debugOptimized

Zmiany łamiące kompatybilność

Nieprzechwycone odrzucenia obietnic będą teraz zgłaszać console.error

Po ulepszeniu zgłaszania nieprzechwyconych błędów JavaScript w poprzedniej wersji, będziemy teraz również zgłaszać nieprzechwycone obietnice za pomocą tego mechanizmu:

Z powodu błędu były one wcześniej całkowicie pomijane i ignorowane, więc należy się spodziewać, że niektóre istniejące wcześniej błędy ujawnią się po aktualizacji do React Native 0.81. Z tego powodu wcześniej istniejące błędy mogą również pojawić się w raportach błędów JavaScript przesyłanych do twojego backendu i spowodować nagły wzrost nowych raportów.

Inne zmiany łamiące kompatybilność

Ogólne

• Przeniesiono ReactNativeFeatureFlags do src/private

  • Ogólnie rzecz biorąc, nie należy w ogóle zależeć od ReactNativeFeatureFlags, ponieważ jest to prywatne API.

• Zaktualizowano typ Appearance.setColorScheme() tak, aby nie przyjmował już wartości nullowalnych

  • W szczególnych przypadkach, gdy trzeba zresetować schemat kolorów, użyj 'unspecified' zamiast null/undefined.

iOS

• Przeniesiono RCTDisplayLink z dala od starszego API RCTModuleData, ponieważ planujemy je usunąć w przyszłości.

Android

• Usunięto klasę com.facebook.react.bridge.JSONArguments, ponieważ była przypadkowo public

• Oznaczono jako przestarzałe MessageQueueThreadPerfStats

  • Oznaczyliśmy to API jako przestarzałe i zastąpiliśmy je atrapą. Nie należy już polegać na statystykach z tego API, ponieważ dostarczane statystyki nie były wiarygodne.

• Zaktualizowano Gradle z wersji 8.x do 9.0.0

  • Lista wszystkich zmian w następnej głównej stabilnej wersji Gradle 9.0.0 jest dostępna tutaj, ale oczekujemy, że nie będzie to miało żadnego wpływu na użytkowników.

C++

• Usunięto nagłówki zapewniające kompatybilność wsteczną dla CallbackWrapper.h / LongLivedObject.h
  • Poprawne dyrektywy include to #include <react/bridging/LongLivedObject.h> oraz #include <react/bridging/CallbackWrapper.h>.
  • Nie należy używać starych dyrektyw include w postaci #import <ReactCommon/….h>

Przeczytaj pełną listę zmian łamiących kompatybilność w dzienniku zmian dla wersji 0.82.

Podziękowania

React Native 0.82 zawiera ponad 868 commitów od 93 współtwórców. Dziękujemy za waszą ciężką pracę!

Specjalne podziękowania kierujemy do członków społeczności, którzy wnieśli znaczący wkład w tę wersję:

• Dawid Małecki i Jakub Piasecki za pomoc we wdrażaniu Hermesa V1.

• Krystof Woldrich za wsparcie w naprawie problemu z pomijaniem nieprzechwyconych odrzuceń obietnic.

• Riccardo Cipolleschi za wsparcie w napisaniu powyższych akapitów o React 19.1.1 i Hermesie V1.

• Rubén Norte za wsparcie przy pisaniu paragrafów dotyczących DOM API i Performance API.

• Tomasz Zawadzki za wsparcie przy benchmarkingu debugOptimized.

Aktualizacja do wersji 0.82

Do sprawdzenia zmian w kodzie między wersjami React Native w istniejących projektach użyj React Native Upgrade Helper, a także zapoznaj się z dokumentacją aktualizacji.

Aby utworzyć nowy projekt:

npx @react-native-community/cli@latest init MyProject --version latest

Jeśli używasz Expo, React Native 0.82 będzie dostępny w wydaniach expo@canary.

Następny SDK, SDK 55, zostanie dostarczony wraz z kolejną stabilną wersją React Native: 0.83.

informacja

Wersja 0.82 jest teraz najnowszą stabilną wersją React Native, a wersja 0.79.x przestaje być wspierana. Więcej informacji można znaleźć w polityce wsparcia React Native.