Проблема: користувачі бачать старі баги тижнями
Припустимо, ваш e-commerce Super App містить міні-програму «Корзина». Ви виправили баг з розрахунком знижки, але поки оновлення пройде рев'ю App Store, мине 2–5 днів. Якщо баг не критичний, чекати наступного релізу додатка — ще 2–4 тижні. В результаті користувачі бачать помилку, конверсія падає на 15–20%, бізнес втрачає прибуток. Система hot-loading міні-програм вирішує цю проблему: ви публікуєте новий bundle на CDN, і через хвилини він у всіх. Але реалізація проста тільки на словах. Ми реалізували десятки таких систем — ділимося архітектурою, яка не падає. Замовте архітектуру hot-loading під ваш проект — ми допоможемо уникнути типових помилок.
Архітектура системи гарячого завантаження
Hot-loading для міні-програм — це не те саме, що Hot Module Replacement у Webpack. Це CDN-based delivery system з версійним контролем та rollback-можливістю.
Базовий flow:
- Розробник публікує нову версію міні-програми (новий bundle.zip на CDN)
- Платформа оновлює manifest — JSON з метаданими та URL нового bundle
- Super App періодично (або при запуску) перевіряє manifest-сервер
- Якщо версія змінилася — завантажує новий bundle у фоні
- При наступному відкритті міні-програми — завантажується новий bundle
Диявол у деталях кроків 3–5.
Стратегії перевірки оновлень: порівняння
| Стратегія | Затримка доставки | Battery impact | Надійність на мобільних мережах |
|---|---|---|---|
| Polling при старті | Години | Низький | Висока |
| Long polling / SSE | Секунди | Високий | Низька |
| Silent push (APNs/FCM) | Хвилини | Середній | Середня (залежить від iOS Doze) |
На практиці комбінуємо: silent push як основний канал + polling при запуску як fallback для пристроїв, де push не дійшов. Silent push через APNs доставляє оновлення в середньому за 5 хвилин — це в 10 разів швидше щоденного polling'у за розкладом. Polling при старті забезпечує 99.5% доставку протягом години для всіх пристроїв.
Чому атомарне оновлення критично важливе?
Не можна застосовувати bundle під час активної сесії міні-програми. Якщо замінити файли поки WebView працює — краш гарантовано.
Рішення — staged swap:
/miniapps/com.vendor.app/ current/ <- поточний active bundle (v2.3.1) pending/ <- завантажений, але ще не застосований (v2.3.2) rollback/ <- попередній bundle для відкочування (v2.3.0) pending стає current тільки при наступному холодному старті міні-програми. Перейменування директорії — атомарна операція на рівні FS. Якщо під час swap стався краш хоста — pending залишиться як є, і спроба повториться при наступному запуску.
Приклад структури директорій на iOS та Android
// iOS let baseURL = FileManager.default.applicationSupportDirectory let appDir = baseURL.appendingPathComponent("miniapps/com.vendor.app/") let currentDir = appDir.appendingPathComponent("current") let pendingDir = appDir.appendingPathComponent("pending") let rollbackDir = appDir.appendingPathComponent("rollback") Для Android аналогічно через Context.getFilesDir().
Верифікація перед застосуванням
Перед застосуванням нового bundle — верифікація:
// iOS let expectedHash = manifest.bundleHash // "sha256:a3f8c2..." let actualHash = SHA256.hash(data: bundleData).hexString guard "sha256:\(actualHash)" == expectedHash else { throw BundleError.hashMismatch } Додатково: перевірка цифрового підпису маніфесту (платформа підписує manifest приватним ключем, клієнт верифікує публічним). Це захищає від атак, коли CDN підмінює bundle на шкідливий.
Якщо верифікація провалилася — bundle видаляється, продовжуємо використовувати поточну версію. В аналітику — подія з hash mismatch для моніторингу.
Як захиститися від краш-петлі?
Нова версія bundle може містити JS-помилку, яка призводить до краш-петлі. Потрібен автоматичний rollback.
Механізм: контейнер рахує consecutive crashes при завантаженні міні-програми. Якщо 3 краші підряд при старті — відкочуємося на rollback/ директорію (попередню відомо-робочу версію). Подія в аналітику, сповіщення розробнику через портал.
Крашем вважається: WKWebView навігація завершилася з помилкою, або JS викинув uncaught exception протягом 2 секунд після завантаження, або bridge не відповів на init-handshake за 5 секунд.
На стороні платформи — можливість emergency rollback: змінити currentVersion у manifest на попередню. Всі клієнти, що перевірили manifest, завантажать «старий» bundle. Це виконується за хвилини, а не години.
Диференціальні оновлення: економія трафіку в 10–30 разів
При великих bundle (> 1 MB) — диференціальні патчі замість повної заміни. Алгоритм bsdiff (Colin Percival, 2003): для оновлення v2.3.1 → v2.3.2 генерується патч-файл, який в 10–30 разів менший за повний bundle. Клієнт завантажує патч, застосовує до поточного bundle, отримує новий. Користувачі з повільним інтернетом економлять до 95% трафіку. Для проекту з аудиторією 500 тис. користувачів економія на трафіку за рахунок диференціальних патчів становить до 90%.
Вимагає зберігання бінарного bundle на клієнті (не тільки розпакованих файлів) для застосування патча. Ускладнює реалізацію, але критично важливо для користувачів з повільним інтернетом.
Типові проблеми та їх вирішення
| Проблема | Наслідки | Наше рішення |
|---|---|---|
| Старий bundle під час сесії | Краш WebView | Staged swap при холодному старті |
| Шкідливий bundle через CDN | Витік даних | Цифровий підпис маніфесту |
| Краш-петля нової версії | Користувач йде | Автоматичний rollback після 3 крашів |
| Повільний трафік | Поганий UX | Диференціальні патчі (bsdiff) |
Що входить у реалізацію hot-loading під ключ
- Проектування архітектури: вибір стратегії доставки, схема manifest API
- Реалізація клієнтського завантажувача (iOS/Android) з верифікацією та rollback
- Розробка CDN-агрегатора та API публікації
- Інтеграція з CI/CD: автоматична публікація bundle при мержі в main
- Документація API та схема конфігурації
- Проведення навантажувального тестування (імітація 1000+ паралельних запитів)
- Підтримка після релізу: моніторинг, алерти, hotfix через emergency rollback
Строки реалізації системи hot-loading з нуля (manifest API + CDN + client-side завантажувач з верифікацією + rollback): від 6 до 12 тижнів. З диференціальними патчами — додайте ще 3–4 тижні. Отримайте консультацію — оцінимо ваш проект і запропонуємо оптимальну архітектуру.
Наш досвід: 10+ років у мобільній розробці
Ми впровадили hot-loading у Super App чотирьох великих замовників з аудиторією від 1 млн користувачів. Жодного інциденту з втратою даних або недоступністю міні-програм після більш ніж 500 релізів. Використовуємо ті самі підходи, що описані вище. Замовте розробку — ми гарантуємо надійність і швидкість.