Hvordan React Native konstruerer applayouts (og hvordan Fabric er ved at ændre det)

React Native-teamet har arbejdet på noget, der grundlæggende vil ændre, hvordan internt i React Native-kommunikation fungerer med værtsoperativsystemet. Det er pænt kodenavnet "projektstof" (indtil der er et officielt navn frigivet).

Lad os diskutere, hvad det faktisk er, og hvilke ændringer det medfører for dig som udvikler.

Hvordan React Native fungerer lige nu

Hvis vi kigger på, bruger React Native lige nu 3 tråde:

  1. UI-tråd - Dette er den vigtigste applikationstråd, som din Android / iOS-app kører på. Den har adgang til brugergrænsefladen, og din brugergrænseflade kan kun ændres af denne tråd.
  2. Shadow Thread - Denne tråd er baggrundstråden, der bruges af React Native til at beregne dit layout oprettet ved hjælp af React-biblioteket.
  3. JavaScript-tråd - Denne tråd er det sted, hvor din JavaScript-kode (din React-kode, i det væsentlige) bor og udføres.

Det indre arbejde ...

Lad os starte fra starten. Antag at du vil tegne et rødt felt midt på skærmen. Så hvad der sker er, at din JS-tråd indeholder kode for at oprette et layout, dvs. den røde boks på skærmen. Her er et typisk kodestykke, som muligvis opnår det for React Native (RN):

Værtsoperativsystemet har sit eget layoutimplementering og følger ikke den slags flexbox-kode, du lige har skrevet. Derfor skal RN først og fremmest konvertere dit flexbox-kodede layout til et layoutsystem, som dit værtsoperativsystem kan forstå.

Hold fast! Før vi gør det, skal vi downloade denne layoutberegningsdel til en anden tråd, så vi kan fortsætte med at udføre vores JavaScript-tråd. Derfor bruger RN Shadow Thread, som i det væsentlige konstruerer et træ i dit layout, du kodede i din JS-tråd. I denne tråd bruger RN en layoutmotor kaldet Yoga, der konverterer det flexbox-baserede layout til et layoutsystem, som din oprindelige vært kan forstå.

React Native bruger noget kaldet en React Native bridge til at kommunikere disse oplysninger fra JS-tråden til Shadow-tråden. I en nøddeskal serierer dette simpelthen dataene i JSON-format og overfører dem som en streng over broen.

På dette tidspunkt er vi i skyggetråden. JS-tråden udføres, og der er ikke noget tegnet på skærmen.

Når vi først har den gengivne markering fra yoga, overføres denne information igen til UI-tråden via React Native bridge. Igen gør dette noget serialisering på Shadow-tråden og deserialisering på hovedtråden. Her gengiver hovedtråden derefter brugergrænsefladen.

Problemer med denne tilgang

Hvis du ser, sker al kommunikation mellem tråde over en bro, der fungerer, men er fuld af begrænsninger. Disse inkluderer:

  • det er langsomt at overføre store stykker data (f.eks. en billedfil konverteret til base64-streng), og
  • der er unødvendig datakopiering, hvis den samme opgave kan implementeres bare ved at pege på dataene i hukommelsen (igen, sig et billede)

Dernæst er al kommunikation asynkron, hvilket i de fleste tilfælde er god. Der er dog i øjeblikket ingen måde at opdatere UI-tråden fra JS-tråden synkront. Dette skaber et problem, når du bruger f.eks. FlatList med en enorm liste med data. (Du kan tænke på FlatList som en svagere implementering af RecyclerView.)

Endelig på grund af denne asynkrone karakter af kommunikation mellem JS-tråden og UI-tråden kan native moduler, der strengt taget kræver synkron dataadgang, ikke bruges i fuldt omfang. For eksempel kræver RecyclerViews adapter på android synkron adgang til de data, den gengiver for ikke at have flimrer på skærmen. Dette er ikke muligt lige nu på grund af den multi-threadede arkitekturopsætning af React Native.

Introduktion til stof

Tag et skridt tilbage, og tænk på din browser. Hvis du tager et dybere kig, er inputfelterne, knapperne osv. Faktisk operativsystemspecifikke. Derfor er det din browser, der beder dit operativsystem (Windows, Mac, Linux eller stort set alt andet) om at tegne for eksempel et indtastningsfelt et eller andet sted på en webside. Holy moly! Se den smukke kortlægning fra browsere til React Native.

  • UI-tråd → UI-tråd
  • Browser rendering engine → React Native rendering engine (Yoga / Shadow thread)
  • JavaScript-tråd → JavaScript-tråd

Vi ved, at moderne browsere er meget modne og håndterer alle disse opgaver effektivt. Så hvorfor ikke reagere indfødte? Hvad er det manglende stykke af puslespillet, der brutalt begrænser React Native, men ikke browsere?

Eksponering af Native API-opkald direkte til JavaScript

Har du nogensinde lige skrevet kommandoer som document.getElementByIdog kommandoer som setTimeoutog setIntervali din konsol og set output? Åh! Deres implementering er faktisk [native code]! Hvad betyder det?

Du kan se, at når du udfører disse funktioner, kalder de ikke nogen JavaScript-kode. I stedet er disse funktioner knyttet direkte til native C ++ - kode, der kaldes. Så browseren lader ikke JS kommunikere med værtsoperativsystemet ved hjælp af bro, men i stedet udsætter JS direkte for operativsystemet ved hjælp af native-kode! I en nøddeskal er dette, hvad React Native Fabric ville gøre: eliminere broen og lade brugergrænsefladen styres direkte fra JS-tråden ved hjælp af native-kode.

Takeaways

  1. RN Fabric gør det muligt for UI-tråden (hvor UI er tegnet) at være synkroniseret med JS-tråden (hvor UI er programmeret)
  2. Fabric er stadig under udvikling, og React Native-teamet har ikke nævnt en offentlig udgivelsesdato fra nu af. Men jeg er temmelig sikker på, at vi får se noget fantastisk i år.
  3. Rammer til appudvikling som disse (RN, NativeScript, Flutter) bliver bedre dag for dag!

Billedkilder: //www.slideshare.net/axemclion/react-native-fabric-review20180725

TL; DR

Kan du lide denne artikel?

Hvis du kunne lide denne artikel, er du velkommen til at give mig nogle klapper og oprette forbindelse til mig på twitter. Kender du det bedste? Claps og twitter er begge gratis! Hvis du har spørgsmål, er du velkommen til at droppe dem i kommentarerne!

Hurtigt skamløst stik: Hvis du kommer i gang med React Native, her er mine 95% rabat på, hvordan du kommer i gang med det: React Native - De første trin