Hermes — mi ez, JS-motor a React Native-hoz és működési elve

Mi az a Hermes

Hermes — egy kompakt, nyílt forráskódú (MIT licenc) JavaScript-motor, amelyet a Meta hozott létre a React Native számára, és optimalizált korlátozott erőforrású mobil eszközökön való működésre. A Hermes fő innovációja a JIT-fordítás elhagyása az AOT (Ahead-of-Time) javára. A React Native alkalmazás build fázisában a Metro Bundler továbbítja a lefordított JavaScriptet a Hermes CLI-nek, amely azt HBC (Hermes ByteCode) bájtkóddá alakítja. Ezt a bájtkódot a motor közvetlenül hajtja végre, további fordítás nélkül az eszközön. Ez a megközelítés kiszámítható teljesítményt biztosít: nincs JIT “bemelegedés”, nincsenek fordítási szünetek, nincs extra akkumulátorfogyasztás. A Hermes a mobil eszközök korlátainak figyelembevételével készült: kevés RAM (1-4 GB), korlátozott energiafogyasztás és gyors hidegindítás szükségessége. A Hermes első nyilvános kiadása 2019-ben volt, és a React Native 0.70-től (2022) a motor szabvánnyá vált Androidon.

Hermes vs JavaScriptCore: motorok összehasonlítása

JavaScriptCore (JSC) — a szabványos WebKit-motor, amelyet a Safari és a React Native használt a 0.70-es verzió előtt. A JSC támogatja a JIT-fordítást, ami magas teljesítményt biztosít összetett JavaScript-műveletekhez. A JIT-nek azonban bemelegedésre van szüksége: az első másodpercekben a kód lassabban fut (értelmezett mód), majd a JIT lefordítja a forró részeket. iOS-en a JIT gyakorlatilag nem elérhető az App Store irányelvei miatt (dinamikus kódgenerálás tilalma), ezért a JSC iOS-en csak értelmezett módban működik — a teljesítmény csökken. A JSC nagyobb bináris mérettel rendelkezik (kb. 10 MB), és több RAM-ot fogyaszt a JIT-infrastruktúra miatt. A Hermes nem függ a JIT-től, ami kiszámítható teljesítményt biztosít közvetlenül az indítás után (hidegindítás). A JSC teljesebben támogatja az ECMAScript szabványt (beleértve a Proxy, BigInt, Reflect elemeket), de nagyobb erőforrás-felhasználás árán. Azon React Native projektekhez, ahol a hidegindítás és a kis méret kritikus — a Hermes előnyösebb. A nehéz JS-számításokkal rendelkező projektekhez (játékok, WebGL) — a JSC magasabb csúcsteljesítményt nyújthat.

AOT-fordítás: hogyan működik az előzetes build

AOT-fordítás (Ahead-of-Time) a Hermes-ben két szakaszban történik. Az első szakaszban a Metro Bundler összegyűjti a JavaScript-fájlokat egyetlen csomagba, és továbbítja a Hermes CLI-nek (a hermesc segédprogramnak). A második szakaszban a hermesc elemzi a JavaScript AST-t, létrehozza a HIR (Hermes Intermediate Representation) köztes reprezentációt, majd kiadja a HBC bináris bájtkódot. Az eredmény egy .hbc kiterjesztésű fájl, amely csak bájtkódot tartalmaz az eredeti JavaScript nélkül. A Hermes runtime közvetlenül tölti be a HBC-t, elemzés és fordítás nélkül. Ez radikálisan felgyorsítja az indulást: ezer JS sor elemzése (async) helyett a motor egy előre lefordított bináris formátumot olvas. Az AOT csökkenti a méretet is: a bájtkód átlagosan 30%-kal tömörebb, mint a JavaScript AST. Az AOT hátránya — az eval, new Function vagy dinamikus require végrehajtásának lehetetlensége futásidőben — minden modulnak ismertnek kell lennie a build szakaszában.

# Telepítse a Hermes CLI-t önállóan
npm install hermes-engine

# Fordítsa a JS-t HBC bájtkódra
npx hermesc -emit-binary -out bundle.hbc bundle.js

# Bájtkód statisztikák
npx hermesc -dump-bytecode bundle.hbc  # shows HBC instructions

# Eredeti JS vs HBC méret
wc -c bundle.js      # 2,300,000 bytes
wc -c bundle.hbc     # 1,450,000 bytes (37% reduction)

Hermes teljesítménymutatók

A Hermes teljesítményét három kulcsfontosságú mutató alapján mérik: Time-To-Interactive (TTI), APK/IPA méret és RAM-fogyasztás. A Meta szerint Androidon a Hermes 34%-kal csökkenti a TTI-t a JSC-hez képest: 4,2 másodpercről 2,8 másodpercre egy középkategóriás eszközön (Moto G7). Az APK mérete 28%-kal csökken a kompakt bájtkódnak és a JIT-könyvtárak hiányának köszönhetően. A RAM-fogyasztás átlagosan 22%-kal alacsonyabb azonos terhelés mellett — ez különösen fontos a 2-3 GB RAM-mal rendelkező eszközök esetében. iOS-en az előny még nagyobb: mivel a JSC nem használhatja a JIT-et, a Hermes akár 45%-os TTI-javulást is biztosít. A mutatók a Meta Facebook Lite alkalmazással végzett tesztjein alapulnak. Valós projektekben az előny változó: egyszerű képernyőknél (listák, szöveg) a Hermes nagyobb javulást ad, nehéz animációknál — kisebbet. Profilozó eszköz: React Native Profiler + hermes profile --heap.

Memória profilozása Hermes-szel

Hermes beépített memória-profilozót tartalmaz, amely a Chrome DevTools-on keresztül érhető el. Csatlakozzon az alkalmazáshoz Metro-n keresztül, nyissa meg a Memory fület, és válassza a Hermes (JavaScript) lehetőséget a pillanatkép-típusoknál. A Hermes három pillanatkép-típust támogat: Heap Snapshot (összes objektum), Allocation Timeline (objektumok élettartama) és Allocation Sampling (szelektív profil). A Hades GC minimálisra csökkenti a GC-szünetek számát — átlagosan egy 2-5 ms-os szünet 10 másodpercenként, szemben a JSC 10-20 ms-os szüneteivel ugyanabban az időszakban.

Hades GC szemétgyűjtő

Hades GC — a Hermes szemétgyűjtője, amely minimális szünetekkel rendelkező mobil forgatókönyvekhez készült. A JSC mark-sweep GC-jétől eltérően a Hades egyidejű (concurrent) gyűjtést használ: a gyűjtő párhuzamosan dolgozik a fő végrehajtási szállal, és csak rövid időszakokra állítja meg azt. A Hades GC generációkra osztja a kupacot: a fiatal generációt (nursery) gyakran és gyorsan gyűjti (Scavenge), az öreg generációt ritkábban és kisebb szünetekkel gyűjti. A kupac mérete konfigurálható: alapértelmezés szerint — az alkalmazás rendelkezésre álló RAM-jának 2/3-a, minimális küszöb — 32 MB. A Hades nem használ stop-the-world megközelítést: még az öreg generáció teljes gyűjtése sem tart tovább 5-8 ms-nál. A gyűjtő a tipikus mobil forgatókönyvhöz van optimalizálva: sok rövid életű objektum (ideiglenes karakterláncok, React fibre objektumok), kevés hosszú életű. Az intenzív objektumlétrehozással rendelkező alkalmazásoknál (listák, animációk) a Hades simább FPS-t biztosít a JSC-hez képest.

Hermes bekapcsolása React Native projektben

A Hermes bekapcsolása a React Native verziójától és a platformtól függ. A React Native 0.70-től kezdve a Hermes alapértelmezés szerint be van kapcsolva Androidon az új projektekben. iOS esetén a Hermes opcionális. Bekapcsoláshoz Androidon: a android/app/build.gradle fájlban állítsa be a enableHermes: true értéket a project.ext.react.enableHermes blokkban. iOS esetén: állítsa a hermes_enabled értékét true-ra a Podfile-ban a use_react_native!(:path => config[:reactNativePath], :hermes_enabled => true) segítségével. Bekapcsolás után futtassa a pod install parancsot. Meglévő projekteknél ellenőrizze a könyvtárak kompatibilitását: a Hermes nem támogatja a Proxy, eval és néhány ES2021 funkciót. Használja a npx react-native info parancsot a konfiguráció ellenőrzéséhez. A Hermes és JSC közötti váltáshoz módosítsa a jelzőt, és hajtson végre clean rebuild-et.

// android/app/build.gradle — Hermes bekapcsolása
project.ext.react = [
    enableHermes: true,
    cliPath: "node_modules/react-native/cli.js"
]

// iOS/Podfile — Hermes bekapcsolása iOS-en
require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

target 'MyApp' do
  config = use_native_modules!
  use_react_native!(
    :path => config[:reactNativePath],
    :hermes_enabled => true
  )
end

Hermes korlátozásai: mi nem támogatott

A Hermes fő korlátozásai a JIT elhagyásával kapcsolatosak. A Hermes nem támogatja a következőket: Proxy és Reflect API (a MobX, Vue, néhány állapotkezelő használja), BigInt (nagy számok), Symbol.toStringTag, WeakRef és FinalizationRegistry. Az eval és new Function függvények kivételt generálnak végrehajtás közben. A Array.prototype.flat és flatMap metódusok this argumentummal rendelkező callback-jei korlátozásokkal működnek. Az ISO 8601 dátumformátumok időzónákkal nem teljesen feldolgozottak. E korlátozások többsége nem érinti a tipikus React Native alkalmazásokat: a React és a React Native korlátozott ES-funkciókészletet használ. Ha egy könyvtár Proxy-t igényel (pl. MobX 6+ Proxy-val), használja a configure({ useProxies: false }) parancsot, vagy válasszon alternatívát. A meglévő kód kompatibilitásának ellenőrzéséhez futtassa a npx hermesc -check parancsot a csomagján — megjeleníti a nem támogatott funkciók listáját.

• Proxy / Reflect — nincs implementálva; a Proxy-t használó könyvtárak fallback módot igényelnek
• BigInt — nem elérhető; használja a bignumber.js könyvtárakat nagy számokhoz
• eval / new Function — hívás throw; minden modulnak statikusnak kell lennie
• WeakRef / FinalizationRegistry — nem támogatott; nincs alternatíva
• Symbol.toStringTag — figyelmen kívül hagyva; instanceof helyesen működik