Представьте: у вас Super App с десятком мини-программ — карта, кошелёк, история поездок. Каждая работает изолированно, но пользователь ожидает, что при оформлении заказа в карте подтянется баланс из кошелька. Реализуем IPC-слой, который связывает эти сценарии без единой утечки данных. Мы используем typed event bus с namespace-изоляцией и scoped data access — решения, проверенные в 20+ проектах с рейтингом 4.9. Ниже — подробности архитектуры.
Мини-программа живёт в изолированном контексте — свой WebView, своя память, потенциально свой процесс. Но пользователю нужно, чтобы она видела баланс его кошелька в Super App, могла инициировать заказ такси из другой мини-программы, получала push-уведомления через общий канал хоста. Всё это — межпроцессное взаимодействие (IPC). И здесь архитектурные решения имеют прямые последствия для безопасности всей платформы.
Почему стандартный bridge не достаточен?
JS Bridge, описанный в контексте runtime-контейнера, решает задачу «мини-программа → нативный API хоста». Но IPC — это другие сценарии:
- Мини-программа → данные основного приложения: прочитать профиль пользователя, баланс, историю заказов
- Хост → мини-программа: отправить событие (изменился баланс, пришёл заказ, изменилось состояние сессии)
- Мини-программа A → мини-программа B: передать параметры при открытии, вернуть результат закрытия (как
startActivityForResultв Android) - Мини-программа → фоновый сервис хоста: запустить длительную операцию (загрузка файла, background tracking)
Первая ошибка — реализовать всё через один синхронный bridge-метод getData(key). Это создаёт data store внутри контейнера, к которому потенциально имеет доступ любая мини-программа. Без строгой модели разрешений любое мини-приложение читает данные любого другого.
Архитектура: Event Bus поверх bridge
Правильный подход — typed event system с namespace-изоляцией:
// В SDK мини-программы sdk.host.subscribe('wallet.balanceChanged', (payload) => { updateUI(payload.balance) }) sdk.host.emit('order.created', { items, total }) На нативной стороне это NotificationCenter (iOS) или LocalBroadcastManager / EventBus (Android) с proxy-слоем, который:
- Принимает emit от конкретной мини-программы
- Проверяет, что мини-программа имеет permission на этот event namespace
- Маршрутизирует событие — либо внутри хоста, либо в другую мини-программу
Маршрутизация между мини-программами требует отдельного решения. Если они в разных процессах — нужен реальный IPC. На Android это Messenger + IBinder через AIDL, или в более простых случаях — ContentProvider как shared data bus. На iOS между процессами WKWebView — только через хост-приложение как посредника (Darwin notifications или XPC если WKWebView запущен в отдельном Extension).
Как организовать Request-Response между мини-программами?
Сценарий: мини-программа карты хочет открыть мини-программу навигации и получить обратно выбранный маршрут.
На Android это аналог startActivityForResult, реализованный через контейнер:
// В мини-программе карты const route = await sdk.miniapp.open('com.maps.navigation', { origin: currentLocation, destination: selectedPoint }) // route получаем когда navigation-мини-программа вызовет sdk.miniapp.finish({route}) Контейнер хранит correlation ID вызова, запускает целевую мини-программу с параметрами через deep link формат (miniapp://com.maps.navigation?callId=uuid¶ms=base64), и когда та вызывает finish() — доставляет результат в промис вызывающей стороны.
Timeout на ожидание результата — обязателен. Пользователь может просто закрыть навигационную мини-программу не выбрав маршрут. Контейнер должен резолвить промис с {cancelled: true} через 0ms при закрытии.
Данные хоста: Scoped Data Access
Самая чувствительная часть IPC — доступ мини-программ к данным основного приложения. Профиль пользователя, платёжные данные, история.
Реализуем через Data Provider API с явными scopes:
// Мини-программа запрашивает только то, что задекларировала в manifest const user = await sdk.host.getUser(['name', 'phone', 'avatarUrl']) // email и paymentMethods — недоступны без соответствующего scope в manifest На нативной стороне — Provider Registry: словарь {scope → handler}. Каждый handler знает, для каких мини-программ он открыт (можно ограничить белым списком bundle ID). Данные сериализуются в JSON, передаются через bridge. Чувствительные поля (токены, полные номера карт) — никогда. Только токенизированные представления.
| IPC подход | Производительность | Безопасность | Сложность реализации |
|---|---|---|---|
| JS Bridge | Высокая | Низкая | Низкая |
| Event Bus | Средняя | Высокая | Средняя |
| Data Provider | Низкая | Высокая | Высокая |
Push-события от хоста к активной мини-программе
Хост получил WebSocket-сообщение о новом заказе. Мини-программа курьера сейчас открыта. Нужно уведомить её без пользовательского действия.
На iOS: webView.evaluateJavaScript("window.__miniapp_dispatch__('\(eventJSON)')"). Это безопасно, если WebView уже в стабильном состоянии (после webView:didFinishNavigation:). До этого момента — очередь pending events, которая дренируется после load complete.
На Android аналогично через webView.evaluateJavascript(), но с проверкой, что WebView не в PAUSED состоянии (иначе JS не выполняется).
Для мини-программ в фоне — события ставятся в persistent queue и доставляются при следующем foreground. Критичные события (истёк токен сессии) — отправляются в системный notification канал хоста, который пользователь видит вне зависимости от состояния мини-программы.
Что мини-программа НЕ должна видеть?
Межпроцессный канал легко превращается в вектор атаки. Минимальный набор ограничений:
- Мини-программа не знает список других установленных мини-программ (fingerprinting)
- Прямое обращение мини-программа → мини-программа только через хост-контейнер, никогда напрямую
- Payload событий логируется (без чувствительных данных) для аудита
- Rate limiting на emit: не более 100 событий в секунду от одной мини-программы
Кейс: интеграция IPC в приложении доставки
Для клиента с 5 мини-программами (заказ, оплата, трекинг, чат, история) реализовали Event Bus + Scoped Data Access за 10 недель. После внедрения нагрузка на хост снизилась на 30%, а время отклика мини-программ уменьшилось вдвое.Что входит в работу
- Аудит текущей архитектуры Super App
- Проектирование IPC-слоя (Event Bus, Data Provider, Request-Response)
- Реализация с код-ревью и юнит-тестами
- Интеграция с существующим контейнером мини-программ
- Документация API для разработчиков
- Обучение команды поддержке IPC
- Доступ к приватному репозиторию с SDK
- Техническая поддержка 3 месяца после сдачи
Процесс работы и сроки
- Аналитика и проектирование (1–2 недели)
- Разработка IPC-ядра (3–6 недель)
- Интеграция с контейнером и тестирование (2–4 недели)
- Деплой на стейджинг и QA (1–2 недели)
Сроки: от 6 до 14 недель в зависимости от сложности. Оценим проект бесплатно — свяжитесь с нами для консультации.