React Native

React Native Hermes Baştan Sona: Bytecode, Static Hermes ve Hermes v1

React NativeHermesStatic HermesPerformance

Hermes motorunun mimarisi, bytecode pipeline, Hermes v1 mirası, Static Hermes ve production checklist — baştan sona rehber.

EG

Emre Gürbüz

20 Temmuz 2026 · 4 dk okuma

React Native’de “hızlı açılış” ve “düşük bellek” konuşulunca yol çoğu zaman Hermes’e çıkar (Meta’nın RN için optimize ettiği JavaScript motoru). Bu yazı yüzeysel tanıtım değil: bytecode’dan Static Hermes’e, Hermes v1’den bugünkü varsayılan motora kadar production’da işe yarayan detayları toplar.

Hermes nedir, JSC’den farkı ne?

Klasik yol (JavaScriptCore / V8) kaynak kodu cihaz üzerinde parse + compile eder. Hermes mümkün olduğunca işi build time’a çeker:

  1. Metro (RN bundler’ı) JS bundle üretir
  2. hermesc bu bundle’ı Hermes Bytecode (.hbc — önceden derlenmiş JS) haline getirir
  3. Cihazda runtime bytecode’u yükler — cold start’ta parse maliyeti düşer

Pratik sonuçlar (projeye göre değişir):

  • TTI / cold start iyileşmesi
  • Daha düşük peak memory
  • Daha öngörülebilir release davranışı (bytecode sabittir)

Metro → hermesc → .hbc pipeline

Release build’de Hermes açıksa Metro çıktısı düz JS olarak gitmez; bytecode’a çevrilir.

Android release ve .hbc arama örneği:

# Android release
cd android && ./gradlew assembleRelease

# Bundle içinde .hbc / hermes varlıklarını ara
find android/app/build -name "*.hbc" -o -name "*hermes*" 2>/dev/null | head

Kontrol listesi:

  • android/gradle.properties → hermesEnabled=true
  • iOS’ta Hermes aktif
  • Source map’ler Crashlytics / Sentry ile eşleşmeli (bytecode + map olmadan stack okunmaz)

Metro config’i bilinçli tutun:

// metro.config.js — minify / serializer ayarlarını bilinçli tut
const { getDefaultConfig, mergeConfig } = require("@react-native/metro-config");
module.exports = mergeConfig(getDefaultConfig(__dirname), {
  // monorepo ise watchFolders / resolver ekstra kritik
});

Garbage collection ve bellek

Hermes generational GC (çöp toplayıcı) kullanır. Büyük liste, image-heavy feed ve sık re-render’da:

  • JS heap’i Hermes sampling profiler ile izleyin
  • Native leak ile JS leak’i ayırın (Instruments / Android Profiler)
  • Bridge/JSI üzerinden tutulan native referansları unutmayın — motor temizlese bile native taraf tutabilir

Hermes v1: ilk nesil ve mirası

Hermes v1, motorun erken dönemidir: bytecode odaklı, Intl (tarih/para formatı) açısından kısıtlı, “Hermes mi JSC mi?” tartışmalarının başladığı dönem.

O dönemde sık görülen konular:

  • Eksik veya kısmi Intl desteği
  • Bazı ES özelliklerinin sürpriz çıkarması
  • “Hermes’te bozuluyor, Chrome’da çalışıyor” tipi polyfill ihtiyacı

Bugünkü Hermes (RN varsayılanı) v1’e göre daha zengin dil desteği, daha iyi tooling ve New Architecture (JSI / Fabric) ile daha doğal entegrasyon sunar.

Eski bloglar ve crash yorumları v1 varsayımlarıyla yazılmış olabilir. Production’da hermes-engine sürümünü net bilin.

Hangi hermes-engine geldiğini kontrol edin:

yarn why hermes-engine
# veya
npm ls hermes-engine

Static Hermes: bytecode’dan native’e

Static Hermes (toplulukta shermes / AOT tartışmalarıyla anılır), JS’i yalnızca bytecode’a değil, mümkün olduğunca native koda derleme vizyonudur.

Klasik Hermes (bugün RN’de):

  • Build: JS → bytecode (.hbc)
  • Device: Hermes VM bytecode çalıştırır

Static Hermes yönü:

  • Build: JS/TS → (tip çıkarımı) → native binary
  • Device: VM yorumlama katmanı azalır; startup ve CPU maliyeti farklı ligde hedeflenir

Neden önemsemeli?

  • CPU-bound işler için uzun vadeli fırsat
  • “JS thread şişiyor” problemlerine mimari alternatif
  • Tip disiplinini güçlendiren bir dünya

Sınırlar

  • Tüm dinamik JS kalıpları AOT’ye dost değil
  • Ekosistem bir günde geçmez
  • Bugün production varsayılanı hâlâ bytecode Hermes; Static Hermes’i roadmap olarak izleyin

Pratik tutum: Bugün Hermes bytecode + New Arch + ölçüm. Kodunu “daha az sihirli, daha tip-net” yaz — AOT gelsin veya gelmesin kazanırsın.

Debugging ve crash

  • Hermes debugger / RN DevTools ile breakpoint
  • Release crash: source map şart
  • Error.stack bytecode’da anlamsız görünebilir; sembolikasyon pipeline’ını CI’ye bağlayın

Release bundle + map üretildi mi kontrol:

ls -la android/app/build/generated/assets/createBundleReleaseJsAndAssets/ 2>/dev/null

Production checklist

  1. hermesEnabled=true (Android + iOS)
  2. Release artifact’ta yanlış motor / JSC kalıntısı yok
  3. Source map → Crashlytics/Sentry upload
  4. Intl / tarih formatı cihaz dilinde test
  5. Cold start metrikleri Hermes öncesi-sonrası
  6. hermes-engine sürümünü lockfile’da sabitle
  7. Static Hermes’i “şimdi migrate” değil “mimari hazırlık” olarak izle

Sonuç

Hermes sadece “açınca hızlanan bir flag” değil: bytecode derleme, GC, tooling ve ufukta Static Hermes ile birlikte düşünülecek bir runtime stratejisidir. Hermes v1 mirasını bilmek eski dokümanları okurken kurtarır; Static Hermes’i bilmek gelecek performans yatırımını doğru yere koydurur.

Diğer yazılar