Hermes V1 у React Native 0.84: Продуктивність, Прекомпільований Байткод та Питання на Співбесіді

Hermes V1 став типовим JavaScript-рушієм у React Native 0.84, випущеному в лютому 2026 року, що є найбільш значущим покращенням продуктивності в історії React Native. Ця стаття детально аналізує прекомпіляцію байткоду, конкурентний збирач сміття Hades, стратегії оптимізації пам'яті та технічні питання на співбесіді, що оцінюють знання Hermes.

Як Прекомпіляція Байткоду Усуває Затримки Запуску

Традиційні JavaScript-рушії, такі як JavaScriptCore (JSC) чи V8, виконують багатоетапний процес: парсять вихідний код, генерують Abstract Syntax Tree (AST), компілюють у байткод, а потім оптимізують гарячі шляхи під час виконання. Hermes фундаментально змінює цей процес, переносячи компіляцію на етап збірки.

Під час процесу збірки React Native, Metro bundler генерує JavaScript-бандл. Компілятор Hermes (hermesc) потім перетворює цей бандл в оптимізований байткод, що зберігається у файлах .hbc. Під час виконання рушій завантажує прекомпільований байткод напряму — без парсингу, без генерації AST, без затримок прогріву JIT.

const { getDefaultConfig } = require('@react-native/metro-config');

const config = getDefaultConfig(__dirname);

// Компіляція байткоду Hermes автоматична в 0.84+
// Transformer обробляє генерацію .hbc під час збірки
module.exports = {
  ...config,
  transformer: {
    ...config.transformer,
    // hermesParser тепер за замовчуванням
    hermesParser: true,
    // Inline requires зменшують час початкової оцінки бандлу
    inlineRequires: true,
  },
};

Файл .hbc відображається безпосередньо в адресний простір процесу за допомогою mmap(). Це означає, що операційна система може вивантажити невикористовувані сегменти байткоду під тиском пам'яті без необхідності повторного парсингу JavaScript-коду Hermes. На пристроях з обмеженою пам'яттю це запобігає краху через брак пам'яті, що траплявся в додатках з великими бандлами на JSC.

Hades: Архітектура Конкурентного Збирача Сміття

Hermes V1 використовує Hades, переважно конкурентний генераційний збирач сміття, що замінив однопотоковий GenGC. Розуміння внутрішніх механізмів Hades є необхідним для відлагодження проблем з пам'яттю та відповідей на питання співбесіди рівня senior.

GenGC спричиняв помітні затримки UI, оскільки вся робота збирача сміття відбувалася в головному потоці. У складних додатках, таких як Facebook для Android, паузи GenGC становили в середньому 200ms з латентністю p99, що сягала 1.4 секунди — іноді до 7 секунд на слабших пристроях.

Hades вирішує цю проблему, виконуючи основну частину роботи збирання у фоновому потоці паралельно з виконанням JavaScript. Збирач використовує стратегію mark-sweep на основі snapshot-at-the-beginning для старого покоління, зберігаючи стратегію напівпросторового копіювання для молодого покоління.

// Розуміння патернів алокації, що добре працюють з Hades
// Короткоживучі об'єкти в молодому поколінні швидко збираються

function renderProductList(products) {
  // Тимчасовий масив - молоде покоління, швидке збирання
  const mapped = products.map(product => ({
    id: product.id,
    display: `${product.name} - $${product.price}`,
  }));
  
  return mapped;
}

// Уникайте патернів, що обходять генераційний GC
// Не кешуйте великі об'єкти без потреби - вони підвищуються до старого покоління
const expensiveCache = {}; // Старе покоління - рідше збирання

// Замість цього використовуйте обмежені кеші з явним видаленням
class BoundedCache {
  constructor(maxSize = 100) {
    this.maxSize = maxSize;
    this.cache = new Map();
  }
  
  set(key, value) {
    if (this.cache.size >= this.maxSize) {
      // Видаліть найстаріший запис - дозвольте GC звільнити пам'ять
      const firstKey = this.cache.keys().next().value;
      this.cache.delete(firstKey);
    }
    this.cache.set(key, value);
  }
  
  get(key) {
    return this.cache.get(key);
  }
}

React Native налаштовує Hermes з pre-tenuring: перші 32MiB алокацій йдуть безпосередньо в старе покоління. Об'єкти, алоковані під час ініціалізації додатку, зазвичай довгоживучі (стеки навігації, глобальний стан, API-клієнти) і не відповідають генераційній гіпотезі, що молоді об'єкти швидко помирають. Pre-tenuring уникає непотрібних збирань молодого покоління під час запуску, безпосередньо покращуючи TTI.

Патерни Оптимізації Пам'яті для Hermes V1

Hermes V1 впроваджує ліниву компіляцію функцій — функції повністю компілюються лише при першому виклику. Це значно зменшує початковий обсяг пам'яті для кодових баз з багатьма рідко використовуваними шляхами коду, але вимагає від розробників розуміння наслідків.

// Ці функції компілюються лише коли функціональність використовується
export function initializeAdvancedAnalytics() {
  // Складна логіка ініціалізації - компілюється при першому виклику
  const analyticsEngine = require('./AnalyticsEngine');
  return analyticsEngine.initialize({
    samplingRate: 0.1,
    batchSize: 50,
  });
}

export function generateDetailedReport(data) {
  // Важкі обчислення - пам'ять алокується лише коли потрібно
  const ReportGenerator = require('./ReportGenerator');
  return new ReportGenerator(data).generate();
}

// У компоненті - прапори функцій контролюють час компіляції
function SettingsScreen({ hasAdvancedFeatures }) {
  const [analytics, setAnalytics] = useState(null);
  
  useEffect(() => {
    if (hasAdvancedFeatures && !analytics) {
      // Функція компілюється тут, не під час завантаження модуля
      setAnalytics(initializeAdvancedAnalytics());
    }
  }, [hasAdvancedFeatures]);
  
  return (
    <View>
      {hasAdvancedFeatures && analytics && (
        <AnalyticsDashboard data={analytics} />
      )}
    </View>
  );
}

Байткод Hermes зазвичай на 10-30% менший за еквівалентний мініфікований JavaScript. Це зменшення розміру бандлу покращує конверсію від завантаження до першого запуску в магазинах додатків та зменшує час холодного старту на пристроях з повільнішим сховищем.

Перевірка Компіляції Байткоду в Продакшн Збірках

Поширеною помилкою є припущення, що байткод Hermes доставляється автоматично. Дебаг-збірки можуть використовувати чистий JavaScript для швидшої ітерації, через що розробники пропускають проблеми, пов'язані з байткодом, до продакшну. Перевірка вимагає дослідження фактичного вмісту бандлу.

# Android: Перевірте байткод Hermes в APK
unzip -l app-release.apk | grep -E "bundle$|hbc$"
# Очікується: assets/index.android.bundle (має бути у форматі HBC)

# Підтвердіть, що файл справді байткод, а не чистий JS
unzip -p app-release.apk assets/index.android.bundle | head -c 8 | xxd
# Байткод Hermes починається з magic bytes: c6 1f bc 03

# iOS: Перевірте байткод в IPA
unzip -l App.ipa | grep -E "main.jsbundle"
# Розпакуйте та перевірте magic bytes так само, як для Android

Якщо бандл містить чистий JavaScript замість байткоду, конфігурація збірки ймовірно має вимкнений Hermes або перевизначення Metro transformer обходить hermesc. Перевірте react-native.config.js та переконайтеся, що жодні кастомні трансформери не заважають генерації байткоду.

module.exports = {
  // НЕ встановлюйте hermes_enabled: false
  // Hermes за замовчуванням в 0.84+
  project: {
    ios: {},
    android: {},
  },
  // Кастомна конфігурація ресурсів за потреби
  assets: ['./src/assets/fonts'],
};

Технічні Питання на Співбесіді про Hermes V1

Позиції senior React Native дедалі частіше включають питання, специфічні для Hermes. Вони оцінюють розуміння шару JavaScript-рушія, що безпосередньо впливає на продуктивність додатку.

Питання 1: Поясніть різницю між компіляцією байткоду Hermes та JIT-компіляцією V8

Hermes використовує Ahead-of-Time (AOT) компіляцію: JavaScript перетворюється в байткод під час процесу збірки на машині розробника або CI-сервері. Скомпільований байткод постачається з бінарним файлом додатку. Під час виконання Hermes виконує байткод напряму без парсингу JavaScript-коду.

V8 використовує Just-in-Time (JIT) компіляцію: JavaScript-код постачається з додатком. Під час виконання V8 парсить код, генерує байткод, потім прогресивно оптимізує гарячі функції через багаторівневу компіляцію (інтерпретатор Ignition → оптимізуючий компілятор TurboFan).

Компроміс: Hermes жертвує піковою швидкістю виконання заради стабільної продуктивності запуску. JIT V8 може врешті виконувати гарячі шляхи швидше за байткод Hermes, але потребує часу прогріву та пам'яті для оптимізуючого компілятора. Мобільні додатки більше виграють від швидкого запуску, ніж від пікової пропускної здатності — користувачі покидають додатки, яким потрібно більше 3 секунд для досягнення інтерактивності.

Питання 2: Чим Hades GC відрізняється від GenGC і чому зміна була необхідною?

GenGC однопотоковий: вся робота збирача сміття зупиняє виконання JavaScript. Фаза mark обходить граф об'єктів, фаза compact дефрагментує heap, обидві в головному потоці. У складних додатках паузи GC сягали сотень мілісекунд.

Hades переважно конкурентний: фоновий потік виконує mark-sweep збирання під час виконання JavaScript. Короткі stop-the-world паузи залишаються для маркування коренів та фіналізації слабких посилань, але зазвичай менше 10ms. Молоде покоління досі використовує копіювальне збирання (швидке, але потребує паузи), тоді як старе покоління використовує конкурентний mark-sweep.

Зміна була необхідною, оскільки мобільні UI-фреймворки вимагають бюджетів 16ms на кадр для анімацій 60fps. Паузи GenGC, що перевищували 200ms, спричиняли видимі затримки та низькі оцінки користувацького досвіду.

Питання 3: Що таке pre-tenuring в Hermes і коли його слід налаштовувати?

Pre-tenuring алокує перші 32MiB безпосередньо в старе покоління, оминаючи збирання молодого покоління. Ініціалізація React Native створює довгоживучі об'єкти (стан навігації, Redux stores, API-клієнти), які не отримують користі від збирання молодого покоління. Pre-tenuring уникає хибних спрацювань під час збирань при запуску.

Сценарії налаштування: Додатки з незвично великими алокаціями при ініціалізації (важке налаштування нативних модулів, великі статичні набори даних) можуть отримати користь від збільшеного розміру pre-tenure. Додатки, оптимізовані для мінімального споживання пам'яті, можуть його зменшити. На практиці типові 32MiB добре працюють для більшості додатків — профілювання з реальними метриками пристрою має передувати будь-яким змінам.

Питання 4: Як відлагоджувати витоки пам'яті в React Native додатку на Hermes?

Почніть з вбудованого монітора продуктивності React Native для спостереження за трендами розміру JS heap. Зростаючий heap під час нормального використання вказує на витоки. Використовуйте дебагер Hermes у Flipper для захоплення знімків heap до та після підозрілих сценаріїв витоку.

Поширені патерни витоків у React Native:

• Event listeners, не видалені у функціях очищення
• Замикання, що захоплюють стан компонента в довгоживучих callback-ах
• Listeners навігації, що продовжують існувати після розмонтування екрану
• Анімовані значення, не зупинені при розмонтуванні

// Патерн витоку пам'яті - замикання захоплює область компонента
function LeakyComponent() {
  const [data, setData] = useState(largeDataset);
  
  useEffect(() => {
    // Це замикання захоплює 'data' - якщо інтервал триває, data теж
    const interval = setInterval(() => {
      console.log(data.length); // Витік: data ніколи не GC'd поки інтервал працює
    }, 1000);
    
    // Виправлення: очистіть інтервал при розмонтуванні
    return () => clearInterval(interval);
  }, [data]);
}

Питання 5: Які потокові аспекти існують при використанні нативних модулів з Hermes?

Hades знищує JavaScript-об'єкти у фонових потоках GC, а не в потоці, де вони були створені. Бібліотеки, що підтримують потоково-локальні ресурси (GPU-контексти, нативні дескриптори), можуть аварійно завершитися, якщо код очищення припускає однопотокове знищення.

Варто відзначити приклад: React Native Skia керує GPU-контекстами per-thread. Об'єкти, створені в UI-потоці, мають бути знищені в UI-потоці. Бібліотека реалізує спеціальний підрахунок посилань для забезпечення правильної потокової прив'язки для очищення.

При написанні кастомних нативних модулів, переконайтеся, що логіка деструктора або виконується в правильному потоці, або є потокобезпечною. Використовуйте платформо-специфічну диспетчеризацію потоків (Android: Handler.post(), iOS: dispatch_async()) для очищення, що потребує певної потокової прив'язки.

Бенчмарки Продуктивності: Hermes V1 vs Попередні Версії

Реальні виміри демонструють покращення Hermes V1 за ключовими метриками:

| Метрика | Hermes Legacy | Hermes V1 | Покращення | |---------|---------------|-----------|------------| | Холодний Старт (TTI) | 2.8s | 1.9s | На 32% швидше | | Теплий Старт | 1.2s | 0.8s | На 33% швидше | | Розмір JS Heap | 45MB | 38MB | На 16% менше | | Пауза GC (p99) | 180ms | 12ms | Зменшення на 93% | | Розмір Бандлу | 4.2MB | 3.1MB | На 26% менше |

Бенчмарки з e-commerce додатку середньої складності, протестованого на Pixel 6a (Android) та iPhone 12 (iOS). Результати варіюються залежно від розміру бандлу, кількості екранів та використання нативних модулів.

Для команд, що мігрують з JSC, покращення ще більш драматичні — особливо паузи GC, що раніше перевищували 500ms на пристроях Android з обмеженою пам'яттю.

Висновок

• Hermes V1 постачає прекомпільований байткод, усуваючи парсинг JavaScript під час виконання та забезпечуючи на 25-50% швидший Time to Interactive
• Конкурентний GC Hades зменшує паузи збирача сміття з сотень мілісекунд до менш ніж 12ms у p99, підтримуючи плавні анімації 60fps
• Pre-tenuring (типово 32MiB) оптимізує запуск, алокуючи об'єкти ініціалізації безпосередньо в старе покоління
• Перевіряйте продакшн-збірки на наявність .hbc байткоду, перевіряючи magic bytes (c6 1f bc 03), а не чистий JavaScript
• Лінива компіляція функцій зменшує початковий обсяг пам'яті — структуруйте код для відкладення компіляції рідко використовуваних функцій
• Автори нативних модулів мають враховувати знищення об'єктів у фоновому потоці при керуванні потоково-локальними ресурсами
• Технічні співбесіди дедалі частіше оцінюють знання Hermes: компроміси байткод vs JIT, архітектура GC та робочі процеси відлагодження пам'яті