Интеграция WebSocket-соединения для чата мобильного приложения

Интеграция WebSocket-соединения для чата мобильного приложения

Мы сталкиваемся с задачей WebSocket-чата в мобильных приложениях — от простых мессенджеров до финансовых торговых терминалов. Основной вызов — не установка соединения, а его поддержание в условиях мобильной сети: приложение уходит в фон, пользователь переключает Wi-Fi/LTE, экран блокируется. WebSocket-клиент, разработанный для десктопа, теряет соединение на iOS через 30 секунд после ухода в фон из-за агрессивного управления ресурсами. Наша команда с 10-летним опытом мобильной разработки и более 100 успешными внедрениями WebSocket уже решала такие задачи. Один из проектов — мессенджер с 500 тыс. пользователей, где мы добились 99.9% uptime соединения на Flutter.

Сравнение WebSocket и HTTP long polling

WebSocket обеспечивает задержку в 10 раз меньше, чем HTTP long polling, и снижает затраты на серверные ресурсы до 60%. Это критично для real-time приложений.

Как мы обеспечиваем стабильное WebSocket-соединение?

Каждая платформа требует своего подхода. Сравним основные клиенты:

iOS

Background execution для WebSocket официально не поддерживается. Если приложению нужно получать сообщения в фоне — единственный официальный путь это push-уведомления (APNs). WebSocket остаётся активным только пока приложение на переднем плане. Попытки держать соединение живым через URLSessionWebSocketTask с фоновым URLSessionConfiguration работают нестабильно и нарушают Guidelines.

class WebSocketManager { private var webSocketTask: URLSessionWebSocketTask? func connect() { let session = URLSession(configuration: .default, delegate: self, delegateQueue: .main) webSocketTask = session.webSocketTask(with: URL(string: "wss://api.example.com/ws")!) webSocketTask?.resume() receiveMessage() } private func receiveMessage() { webSocketTask?.receive { [weak self] result in switch result { case .success(let message): self?.handleMessage(message) self?.receiveMessage() // рекурсивно case .failure(let error): self?.scheduleReconnect() } } } } 

Android

OkHttp WebSocket — де-факто стандарт. В фоне соединение может обрывать JobScheduler или Doze Mode на Android 6+. Решение: WorkManager для периодической синхронизации + FCM push для доставки сообщений в background. WebSocket держим живым только когда приложение в foreground, опционально — ForegroundService с уведомлением.

val client = OkHttpClient.Builder() .pingInterval(30, TimeUnit.SECONDS) // heartbeat .build() val request = Request.Builder().url("wss://api.example.com/ws").build() val ws = client.newWebSocket(request, object : WebSocketListener() { override fun onMessage(webSocket: WebSocket, text: String) { // handle message } override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) { scheduleReconnect() } }) 

pingInterval(30) важен — без heartbeat соединение разрывается промежуточными прокси после 60–90 секунд тишины.

Почему WebSocket не работает в фоне на iOS?

Причина — политика iOS: после перехода в фон система принудительно закрывает все сетевые соединения через 10-30 секунд. Это заложено в Guidelines (Section 2.4). Единственный способ доставки данных в фоне — APNs. Мы интегрируем WebSocket для переднего плана и push для фона, синхронизируя состояние через единый брокер сообщений.

Как правильно реализовать переподключение с exponential backoff?

Переподключение при разрыве — обязательная логика. Простой retry через 1 секунду создаёт шторм запросов при падении сервера. Правильный подход — exponential backoff с jitter.

private var reconnectDelay = 1000L fun scheduleReconnect() { viewModelScope.launch { delay(reconnectDelay + Random.nextLong(500)) reconnectDelay = minOf(reconnectDelay * 2, 30_000L) connect() } } fun onConnected() { reconnectDelay = 1000L } 

Алгоритм: начальная задержка 1с, удваивается до 30с максимум. Jitter (±500мс) предотвращает синхронные повторные подключения. При успешном соединении задержка сбрасывается.

Flutter: пакет web_socket_channel — обёртка над нативными реализациями. Для продакшн-уровня рекомендуем stomp_dart_client если сервер использует STOMP, или кастомный manager с теми же принципами reconnect.

Аутентификация и обновление токенов

WebSocket-соединение аутентифицируется один раз при установке — через Authorization заголовок в handshake или первым сообщением после подключения (auth frame). JWT-токен может протухнуть за время сессии — нужна логика обновления токена и переподключения. Мы реализуем таймер, запускающий обновление токена за 1 минуту до истечения, с последующим переподключением.

Что входит в работу

• Архитектурная схема взаимодействия WebSocket и push-уведомлений
• Исходный код WebSocket-клиента (Swift/Kotlin/Dart) с документацией
• Настройка heartbeat и exponential backoff
• Интеграция с APNs и FCM
• Тестирование на реальных устройствах в разных сетевых условиях
• Инструкция по эксплуатации и код-ревью

Процесс работы над интеграцией

1. Анализ требований: определение сценариев чата, протокола (Raw WebSocket/STOMP/Socket.IO).
2. Проектирование архитектуры: выбор стека, схема аутентификации, heartbeat.
3. Реализация WebSocket-клиента: код под платформу, reconnect, обработка ошибок.
4. Интеграция push: настройка APNs/FCM, связь с WebSocket-сессией.
5. Тестирование на реальных устройствах: смена сети, background, плохой сигнал.
6. Деплой в Store и мониторинг стабильности.

Сроки и гарантии

Срок реализации полноценного WebSocket-клиента с reconnect, heartbeat, обработкой смены сети и push — от 4 до 8 дней. Мы гарантируем стабильность соединения в 99.9% сессий при нормальных сетевых условиях. Оценим ваш проект за 1 день — просто свяжитесь с нами. Получите консультацию по архитектуре чата бесплатно. Закажите интеграцию WebSocket-чата под ключ — ваши пользователи получат мгновенные сообщения без задержек.