Ar tikrai „Flutter“ yra pasirodymų karalius? Naujoji „React Native“ architektūra turi ką pasakyti

Kalbant apie kelių platformų mobiliųjų įrenginių kūrimą, pasirodymas visada buvo vienos karščiausių diskusijų tarp Reaguoti gimtoji ir Plazdėjimas. Flutter jau seniai buvo giriamas kaip spektaklio karalius, bet su naujausi „React Native“ architektūros atnaujinimaiistorija nėra tokia vienpusė kaip anksčiau. Suskaidykime.

Kodėl „React Native“ našumas tradiciškai buvo mažesnis nei „Flutter“.

„React Native“ ir „Flutter“ perteikimas ir bendravimas su vietiniu sluoksniu labai skiriasi.

Išsamiai reaguokite į gimtąją (senąją architektūrą).

Tilto problema

Senajame „React Native“ modelyje jūsų programos verslo logika buvo parašyta „JavaScript“, o vartotojo sąsajos ir platformos API (mygtukai, navigacija, fotoaparatas ir kt.) veikė savajame kode („Objective-C“ / „Swift“, skirta „iOS“, „Java“ / „Kotlin“, skirta „Android“).
Norėdami sujungti šiuos du pasaulius, „React Native“ naudojo a tiltas — komunikacijos sluoksnis, perduodantis pranešimus pirmyn ir atgal tarp „JavaScript“ ir vietinių modulių.
Šios žinutės turėjo būti serializuotas (konvertuoti į JSON ar panašų) prieš išsiųsdami ir tada deserializuotas kitoje pusėje.

Kaip veikė srautas

„JavaScript“ gija → Tiltas → Vietiniai moduliai (UI, API) → Ekranas

• „JavaScript“ tvarkė programos logiką ir įvykius.
• Tiltas asinchroniškai nešė pranešimus.
• Vietiniai moduliai pateikė vartotojo sąsają ir vykdė platformos funkcijas.

Kodėl tai sulėtino reikalus

• Serializacijos kaina → Kiekviena žinutė (pvz „nustatyti mygtuko spalvą į raudoną“) turėjo būti konvertuotas prieš siunčiant.
• Asinchroniška gamta → Pranešimai buvo eilėje, todėl dėl sunkios animacijos ar slinkimo atsirado vėlavimų.
• Pakavimas ir eilės sudarymas → Pranešimai buvo sugrupuoti siekiant efektyvumo, tačiau didelės vartotojo sąsajos programose dėl to sumažėjo kadrų.
• Skirtingos gijos → „JavaScript“ veikė vienoje gijoje, vartotojo sąsaja – kitoje, todėl sinchronizavimas buvo sudėtingas.

Poveikis našumui

• UI-Heavy Apps → Animacijos ir gestai mikčiojo.
• Platformos kintamumas → iOS ir Android kartais elgėsi skirtingai.
• Sudėtingos integracijos → Daugiau vietinių API reiškė daugiau sujungimų, padidinančių našumo sąnaudas.

👉 Trumpai tariant: senoji tiltu paremta architektūra buvo galinga, bet sukurta naudojant serializavimą, paketų sudarymą ir bendravimą tarp gijų.

Architektūros srautas (senas prieš virpėjimą):

„Flutter“ architektūra išsamiai

Kiekvieno pikselio piešimas

„Flutter“ programos parašytos „Dart“, sukompiliuotos į savąjį mašininį kodą ir maitinamos naudojant „Dart“. Flutter variklis (C++).
Skirtingai nei „React Native“, „Flutter“ nepasikliauja platformos savaisiais vartotojo sąsajos komponentais. Vietoj to, tai atvaizduoja kiekvieną pikselįnaudojant GPU optimizuotą atvaizdavimo variklį (Darbaratis ).

Kaip veikia srautas

Smiginio kodas → Flutter Engine → Impeller (GPU rendereris) → Skia Graphics → Ekranas

• Dart kodas apibrėžia vartotojo sąsają ir logiką.
• „Flutter Engine“ valdiklių medžius paverčia atvaizdavimo instrukcijomis.
• Impeller + Skia rankena GPU piešimas (mygtukai, tekstas, vaizdai, animacijos).
• Ekrane rodoma ta pati vartotojo sąsaja „iOS“ ir „Android“.

Kodėl tai greičiau

• Nėra tilto → Nėra pirmyn ir atgal tarp JS ir vietinio.
• Vienas atvaizdavimo vamzdynas → UI yra visiškai tvarkoma „Flutter“ variklyje.
• Tiesioginė GPU prieiga → Darbaratis užtikrina sklandų 60 kadrų per sekundę+ atvaizdavimą.
• Visur tie patys valdikliai → Vienoda vartotojo sąsaja visose platformose.

Realaus pasaulio poveikis

• Nuoseklus FPS → Nuspėjamas našumas visuose įrenginiuose.
• Sklandžiai animacijos → Jokio mikčiojimo dėl siūlų šokinėjimo.
• Vienodumas tarp platformų → iOS ir Android atrodo identiškai.
• Lengvai valdo sunkią vartotojo sąsają → Sudėtingi perėjimai ir animacijos vyksta sklandžiai.

Scenarijaus pavyzdys, skirtas palyginti „Flutter“ ir „React Native“ (senas)

Įsivaizduokite programą, kurioje rodomas 100 vaizdų sąrašas:

• Plazdėjimas: Viską piešia tiesiogiai su GPU optimizuotu atvaizdavimo įrenginiu → sklandžiai 60 kadrų per sekundę.
• „React Native“ (senas):
• JavaScript apskaičiuoja, ką rodyti.
• Siunčia instrukcijas (pvz., „pateikti vaizdą X padėtyje“) per tiltą.
• Native jį atvaizduoja.
• Daugeliui daiktų nuolatinis judėjimas pirmyn ir atgal lėtina reikalus→ kadras nukrenta arba vėluoja.

👉 Trumpai tariant: „Flutter“ užtikrina didesnį ir nuoseklesnį našumą, nes valdo visą atvaizdavimo vamzdyną. Yra jokio tilto nereikia pasikliauti OS savaisiais valdikliais, o tiesioginis GPU optimizavimas užtikrina sklandžius, nuspėjamus rezultatus visose platformose.

„Štai kodėl tai buvo mantra daugelį metų: „Flutter” visada laimi dėl našumo. Tačiau dabar naujoji „React Native” architektūra apverčia scenarijų.”

Naujausias „React Native“ atnaujinimas: „The Bridgeless New Architecture“.

„Facebook“ („Meta“) pertvarkė „React Native“ su a nauja architektūraspręsti šias problemas. Atnaujinimas pristato:

JavaScript → JSI → TurboModules/Fabric → Native Components → Ekranas

1. JSI (JavaScript sąsaja)

• Senasis būdas: Senajame tilto modelyje „JavaScript“ ir savoji kalba buvo perduodama nuosekliaisiais pranešimais (dažnai JSON). Dėl to atsirado vėlavimų ir papildomų išlaidų.
• Naujasis būdas (JSI) :
• JSI suteikia tiesioginė prieigatarp JavaScript ir vietinių objektų.
• Nereikia serializuoti / deserializuoti – funkcijas ir duomenis galima iškviesti tiesiogiai.
• Tai daro vykdymą greitesnis ir artimesnis vietiniam greičiui.
• Pavyzdys : Užuot siuntusi JSON instrukcijas, pvz., { „action”: „openCamera” } per tiltą, „JavaScript” dabar gali iškviesti „openCamera()” tiesiogiai vietiniame kode.

✅ Rezultatas:Dramatiškai sumažintas delsos laikas, sklandesnis veikimas, mažiau išmestų kadrų.

2. TurboModuliai

• Senasis būdas : Vietiniai moduliai (pvz., Fotoaparatas, Geolokacija ir kt.) buvo įkeliami noriai – tai reiškia, kad visi moduliai buvo inicijuoti paleidžiant, nesvarbu, ar jie buvo naudojami, ar ne.
• Naujas būdas (TurboModules):
• Moduliai įkeliami tingiai(tik tada, kai reikia).
• Jie naudoja JSI, todėl JS gali tiesiogiai juos pasiekti be tilto serializavimo.
• Pailgina paleidimo laiką ir sumažina atminties naudojimą.
• Pavyzdys : jei jūsų programa nenaudos „Push Notifications“ iki vėliau, modulis nebus įkeltas paleidžiant → greitesnis programos paleidimas.

✅ Rezultatas:Greitesnis paleidimas, mažesnis atminties suvartojimas, geresnis veikimo laikas.

3. Audinių atvaizduotojas

Senasis kelias (tiltas + joga) :

Reaguoti komponentas → JS gija → šešėlių medis (joga) → tiltas → savoji vartotojo sąsajos gija → platformos vartotojo sąsaja

• Jūs rašote React komponentus (, ).
• „React“ sukuria virtualų medį (NS JS atvaizdas).
• Šis medis paverčiamas šešėliniu medžiu – lengva vartotojo sąsajos struktūros kopija.
• Čia veikia joga, kad būtų galima apskaičiuoti išdėstymą (dydžius, lenkimo pozicijas ir kt.).
• „Yoga“ apskaičiavus išdėstymą, instrukcijos (pvz., plotis = 200, aukštis = 50, x = 10, y = 20) turėjo būti suskirstytos į JSON panašius pranešimus.
• Jie buvo siunčiami per Tiltą (asinchroniniai, paketiniai).
• Gimtojoje pusėje prieš pateikiant jie buvo deserializuoti atgal į vietinius objektus.
• Jis susieja juos su vietiniais vartotojo sąsajos komponentais (UIButton sistemoje „iOS“, „TextView“ sistemoje „Android“).
• Galiausiai ekrane nubrėžiama vartotojo sąsaja.

Šis serializacijos + deserializacijos veiksmas buvo pagrindinis pridėtinių išlaidų ir vartotojo sąsajos vėlavimo šaltinis.

Joga → Tiesioginė (JSI/Audinys) → Gimtoji.

• Šešėlių medis vis dar egzistuoja, o Joga vis dar skaičiuoja išdėstymą.
• Bet dabar yra Nėra JSON serializavimodaugiau.
• Vietoj to, pats šešėlių medis yra tiesiogiai bendrinamas tarp „JavaScript“ ir „Native“, naudojant JSI („JavaScript“ sąsają).
• Tiek JS, tiek Native gali pasiekti tuos pačius atminties objektus (be konvertavimo).
• Pavyzdys : Sudėtinga animacija (pvz., perbraukimas, kad ištrintumėte) dabar atnaujinama sklandžiai, nes JS ir savoji vartotojo sąsaja yra glaudžiai sinchronizuojama su mažiau šuolių.

✅ Rezultatas:Sklandesnė vartotojo sąsaja, mažiau kadrų kritimo, patobulintas animacijos valdymas.

4. Codegen

• Senasis būdas : Kūrėjai rankiniu būdu parašė įrišimus, kad sujungtų JS su vietiniais moduliais. Tai buvo klaidų ir dažnai trūko tipo saugumo.
• Naujasis būdas (Codegen):
• Konstravimo metu automatiškai generuojamas pradinis kodas, skirtas vietiniams susiejimams.
• Užtikrina tipo saugus bendravimastarp JS ir vietinio.
• Sumažina žmogiškųjų klaidų ir platformų neatitikimų skaičių.
• Pavyzdys : Jei savoji funkcija tikisi sveikojo skaičiaus, bet JS siunčia eilutę, Codegen sugauna ją kompiliavimo metu.

✅ Rezultatas: Saugesnė, patikimesnė ir greitesnė kūrimo darbo eiga.

Architektūros srautas (nauja architektūra):

Šis be tiltų metodas drastiškai sumažina išlaidas ir daro „React Native“ našumą daug artimesnį „Flutter“.

„Flutter vs React Native“: pasirodymas šiandien

• Plazdėjimas: Vis dar turi neapdoroto GPU atvaizdavimo pranašumą, nes jis valdo kiekvieną pikselį ir visiškai apeina vietinius valdiklius.
• „React Native“ (nauja): Dabar teikia beveik vietinį našumą su mažesnis delsos laikas, geresnis atminties efektyvumas ir sklandesni vartotojo sąsajos atnaujinimaidėka Fabric ir Turbo modulių.

Praktikoje:

• Programoms su sunki pasirinktinė grafika / animacija„Flutter“ vis tiek gali veikti geriau.
• Programoms, kurios labai priklauso nuo vietinės integracijos ir konkrečios platformos funkcijos „React Native“ dabar stipriai konkuruoja be senosios našumo bausmės.

Ar „plazdėjimas visada geresnis“ vis dar tiesa?

Jau ne.

„Flutter“ vis dar šviečia savo pasirinktiniu atvaizdavimo varikliu ir nuosekliu vartotojo sąsajos veikimu. Bet „React Native“. Nauja Architektūra pakeitė žaidimą – nebėra lėto tilto, greitesni vartotojo sąsajos atnaujinimai naudojant „Fabric“, išmanesnis vietinis įkėlimas naudojant „TurboModules“ ir sklandus saugaus tipo integravimas naudojant „Codegen“.

Dabar „React Native“.užtikrina našumą, kuris ne tik „priartėja“ – ji iš naujo apibrėžia, ką kelių platformų programos gali pasiekti naudodami „JavaScript“.

👉 Taigi senas posakis „plazdėjimas visada yra geriausias pasirodymui“ nebegalioja. Su savo modernizavimu, „React Native“ ne tik vejasi, bet ir konkuruoja.

Išvada

Jei jūsų prioritetas yra tobula pikselių vartotojo sąsaja ir visiška atvaizdavimo kontrolė, „Flutter“ vis tiek dėvi karūną. Tačiau istorija tuo nesibaigia. Su React Native’s Nauja Architektūradiskusijos dėl pasirodymų nebėra vienpusė gatvė. „React Native“ dabar petys į petį stovi kartu su „Flutter“ ir įrodo, kad ji ne tik neatsilieka, bet ir konkuruoja aukščiausiu lygiu.

👉 Tikra tiesa 2025 m.: Abi sistemos yra galingas, išbandytas kovoje ir galintis kurti pasaulinio lygio programas. Senas įsitikinimas, kad „Flutter visada laimi spektaklyje“, tapo labiau mitu nei realybe.

Galų gale, jūsų pasirinkimas priklauso ne nuo to, kas laimės pasirodymo lenktynes, o apie tai, kas tinkaJūsų komandos stipriąsias puses, projekto viziją ir ilgalaikį augimą.

Nes „Ateitis nėra „Flutter vs React Native“ – tai tai, ką su jais sukuriate.