Реализация межпроцессного взаимодействия мини-программ с основным приложением

Реализация межпроцессного взаимодействия мини-программ с основным приложением

Мини-программа живёт в изолированном контексте — свой 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-слоем, который:

1. Принимает emit от конкретной мини-программы
2. Проверяет, что мини-программа имеет permission на этот event namespace
3. Маршрутизирует событие — либо внутри хоста, либо в другую мини-программу

Маршрутизация между мини-программами требует отдельного решения. Если они в разных процессах — нужен реальный 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&params=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. Чувствительные поля (токены, полные номера карт) — никогда. Только токенизированные представления.

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-подсистемы в рамках существующего Super App с готовым контейнером: от 6 до 14 недель в зависимости от набора сценариев и требований к безопасности. Полноценная Event Bus + Scoped Data Access + Request-Response — ближе к старшей границе.