Unity мультиплеер: Mirror, синхронизация, reconnect и headless-сервер

Мобильная игра на Unity часто тормозит при добавлении мультиплеера. Сетевая синхронизация на телефоне — отдельный вызов: случайный уход в фон обрывает соединение, а задержки в 200 мс убивают геймплей. Мы решаем эту задачу с помощью открытого сетевого кода Mirror Networking — фреймворка, который даёт полный контроль над Unity сетью и инфраструктурой. В отличие от Photon, Mirror не привязан к облаку: подключайте kcp2k, Telepathy или WebSockets, поднимайте сервер на собственных мощностях. Для мобильных проектов это означает latency 10–50 мс вместо 100+, экономию на хостинге до 70% и оптимизацию трафика, сокращающую расходы на передачу данных до 50%. Mirror обходится в 2-3 раза дешевле Photon при 1000+ одновременных игроков. Наш опыт — 5+ лет разработки мобильных мультиплеерных игр на Unity, более 30 успешных релизов. Гарантируем стабильную синхронизацию даже при 50+ одновременных игроках.

Как Mirror решает проблему потери соединения на мобильных устройствах?

Мобильные сети нестабильны. При уходе в фон iOS закрывает сокет через 10 секунд, Android — по-разному. Mirror сам не восстанавливает соединение, поэтому мы реализуем кастомный reconnect:

public class MobileNetworkManager : NetworkManager
{
    private bool wasPaused;

    void OnApplicationPause(bool pauseStatus)
    {
        if (pauseStatus)
        {
            wasPaused = true;
        }
        else if (wasPaused)
        {
            wasPaused = false;
            if (!NetworkClient.isConnected)
            {
                StartCoroutine(TryReconnect());
            }
        }
    }

    IEnumerator TryReconnect()
    {
        int attempts = 0;
        while (attempts < 5 && !NetworkClient.isConnected)
        {
            NetworkClient.Reconnect();
            yield return new WaitForSeconds(2f * attempts);
            attempts++;
        }
    }
}

Согласно Mirror Networking документации, метод NetworkClient.Reconnect() используется для восстановления соединения.

Код выше — база. Дополнительно настраиваем push-уведомления (APNs/FCM) для возврата игрока в активную сессию и используем NetworkManager.singleton для глобального доступа. Важно: не создавайте несколько NetworkManager в сцене — Mirror выдаст предупреждение, но поведение станет непредсказуемым.

Синхронизация состояния: SyncVar, SyncList и вызовы

[SyncVar] автоматически передаёт изменения с сервера на всех клиентов. Используйте hook для обновления UI:

public class PlayerHealth : NetworkBehaviour
{
    [SyncVar(hook = nameof(OnHealthChanged))]
    public int health = 100;

    void OnHealthChanged(int oldVal, int newVal)
    {
        healthBar.fillAmount = newVal / 100f;
    }

    [Command]
    public void CmdTakeDamage(int amount)
    {
        // Выполняется только на сервере
        health = Mathf.Max(0, health - amount);
    }
}

Для коллекций (инвентарь, очередь баффов) используйте SyncList<T> с callback OnChange. Тройка [Command] (клиент→сервер), [ClientRpc] (сервер→все клиенты), [TargetRpc] (сервер→один клиент) — основа любого мультиплеера. Освойте их до начала интеграции.

Почему выбор транспорта критичен для мобильного мультиплеера?

Для мобильного нативного приложения выбирайте kcp2k или Ignorance. kcp2k встроен в Mirror с версии 50+, настройка: NoDelay = true, Interval = 10ms, FastResend = 2. TCP (Telepathy) используйте для пошаговых игр, где надёжность важнее задержки. На мобильных устройствах kcp2k обеспечивает в 5-10 раз меньшую задержку по сравнению с TCP.

Сравнение моделей авторитетности:

Headless-сервер и инфраструктура

Mirror-сервер — это тот же Unity билд с флагом -batchmode -nographics. Для action-игр — один headless-сервер на комнату, для стратегий с малым количеством игроков — несколько комнат на инстанс. Оркестрацию доверьте Unity Game Server Hosting (Multiplay) или Kubernetes с автоскейлингом. Небольшие проекты стартуют на VPS (DigitalOcean/Hetzner) с systemd-скриптами. Для UDP-транспорта (kcp2k) убедитесь, что load balancer поддерживает UDP passthrough.

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

1. Аналитика — аудит геймдизайна, выбор модели (authoritative / P2P), прототип latency.
2. Проектирование — архитектура сети, схема синхронизации, сценарии reconnect и anti-cheat.
3. Реализация — настройка NetworkManager, транспорт, SyncVar, команды, спавн объектов.
4. Тестирование — нагрузочные тесты (50+ клиентов), эмуляция потери пакетов, уход в фон.
5. Деплой — настройка headless-сервера, CI/CD для обновлений, мониторинг.

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

• Архитектура сети (выбор модели, транспорта, балансировка).
• Настройка Mirror: NetworkManager, префабы, спавн, команды.
• Реализация reconnect и обработки фона.
• Сборка и деплой headless-сервера с systemd/Docker.
• Load-тестирование под 50+ одновременных соединений.
• Документация API и инструкция по развёртыванию.
• Поддержка после релиза (1 месяц).

Типичные ошибки при интеграции Mirror в мобильную игру

NetworkIdentity не найден. Префаб не зарегистрирован в NetworkManager.spawnPrefabs. Спавн через NetworkServer.Spawn упадёт в runtime.

Authority confusion. isServer, isClient, isLocalPlayer, hasAuthority — четыре разных булевых. Код в Update() без проверки isLocalPlayer выполняется на всех клиентах.

Disconnect на мобильном. При уходе в фон iOS закрывает сокет через ~10 секунд. Mirror не восстанавливает соединение автоматически — нужна кастомная логика.

Сроки

Базовая Mirror-интеграция с синхронизацией позиций, health и командами: 1–2 недели. Полноценная система с headless-сервером, матчмейкингом, reconnect и мобильной оптимизацией: 1–2 месяца. Стоимость рассчитывается индивидуально. Свяжитесь с нами для анализа вашего проекта — оценим бесплатно. Получите консультацию по архитектуре сети и срокам. Закажите интеграцию Mirror для вашей игры — мы проведём аудит и предложим решение за 1 день.

Интеграция API в мобильное приложение: с чего начать

Запрос уходит, ответ не приходит, timeout — 30 секунд. Пользователь смотрит на спиннер. Сети нет — мобильная карта в метро. Или сеть есть, но сервер вернул 200 с HTML-страницей ошибки вместо JSON — и приложение крашит при JSONDecoder.decode(). Мы видим такие кейсы на каждом втором проекте. Поэтому интеграция API в мобильное приложение — это не просто вызов endpoint'а, а проектирование надёжного сетевого слоя: обработка ошибок, кэширование, offline-режим, certificate pinning. Закажите аудит текущего сетевого слоя — оценим проект за 1 день.

Почему стандартные библиотеки недостаточны? URLSession и OkHttp предоставляют базовый HTTP-клиент, но для production нужны retry с exponential backoff, валидация статус-кодов, типизированная десериализация и мониторинг состояния сети. Без этого приложение теряет данные и пользователей. Мы уже 5 лет занимаемся мобильной разработкой и реализовали более 30 проектов с интеграцией API на iOS, Android и Flutter — от стартапов до enterprise-решений.

Как выбрать протокол для интеграции API?

REST остаётся стандартом для большинства проектов. Но когда на экране профиля нужно 5 полей из 40, GraphQL исключает over-fetching и сокращает трафик на 30–60%. gRPC оправдан при тысячах запросов в минуту (trading, IoT) — бинарная сериализация в 3–5 раз быстрее JSON. WebSocket — единственный выбор для real-time без polling (сообщения, уведомления).

Пример из практики: для финтех-приложения мы заменили REST (40 полей) на GraphQL — размер ответа сократился с 12 КБ до 2,5 КБ, время рендера экрана упало на 70%. Экономия трафика составила около 15 000 ₽ в месяц при 100 000 активных пользователей.

Как обеспечить надёжность соединения и offline-first

Пользователи теряют сеть в метро, лифте, тоннеле. Мобильное приложение обязано работать без интернета — хотя бы в read-only режиме. Мы внедряем паттерн offline-first:

1. При открытии экрана сначала показываем данные из локального кеша (Core Data / Room).
2. Параллельно выполняем сетевой запрос, обновляем UI после ответа.
3. Если сеть недоступна — показываем кешированные данные и метку «нет соединения».
4. При восстановлении сети автоматически синхронизируем изменения.

Для кэширования HTTP-ответов используем URLCache (iOS) и OkHttp Cache (Android) с поддержкой Cache-Control. Для структурированных данных — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback отслеживают состояние сети и триггерят обновление.

REST и выбор клиентской библиотеки

Alamofire (iOS) — де-факто стандарт для Swift-проектов. Поверх URLSession добавляет request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() с .validate() возвращает ошибку для любого статус-кода вне 200–299. Без .validate() Alamofire считает 404 и 500 успешными ответами. С Swift Concurrency — async-версия через serializingDecodable.

Retrofit (Android) — аннотационный HTTP-клиент поверх OkHttp. Интерфейс с аннотациями компилируется в реализацию. @GET, @POST, @Path, @Query, @Body — декларативное описание API. OkHttp под капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логирование в debug-сборке. Authenticator — автоматический refresh токена при 401.

Ktor (KMM/Flutter) — мультиплатформенный HTTP-клиент. На iOS работает через Darwin engine (URLSession), на Android — через OkHttp. Единый код для обеих платформ при KMM-архитектуре.

GraphQL: когда REST не справляется

REST возвращает фиксированную структуру. Экран профиля требует name, avatar, email — сервер отдаёт 40 полей. Over-fetching. GraphQL решает это: клиент запрашивает ровно нужные поля. Это критично для мобайла, где трафик и время парсинга — реальные ограничения. Apollo iOS и Apollo Kotlin генерируют типизированные классы по схеме: schema.graphql + query-файлы → строгие типы на этапе компиляции. Subscriptions через WebSocket — real-time без polling. Ограничение: GraphQL сложнее кешировать на уровне HTTP. Apollo использует нормализованный in-memory кеш InMemoryNormalizedCache — запросы с пересекающимися данными обновляют кеш без дублирования. Apollo GraphQL Documentation

WebSocket: real-time без лишнего трафика

Polling (setInterval каждые 5 секунд) — трата батареи и трафика. WebSocket — постоянное двунаправленное соединение. iOS: URLSessionWebSocketTask (нативный, iOS 13+). Android: OkHttp WebSocket. Обязательная обработка reconnect: при onFailure — экспоненциальный backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надстройка с автоматическим reconnect, но для новых проектов предпочтительнее нативный WebSocket (меньше зависимостей).

gRPC: для высоконагруженных сервисов

gRPC с protobuf — бинарная сериализация: меньше размер, быстрее парсинг. grpc-swift для iOS, grpc-kotlin для Android. Protobuf-схема компилируется в типизированные классы. Streaming (server-side, client-side, bidirectional) — нативная возможность. Порог применения: высокая частота запросов (trading, IoT) или критичная latency. Для обычного CRUD REST проще в дебаге и мониторинге.

Certificate Pinning и безопасность

Корпоративный proxy может перехватить HTTPS через подмену сертификата. Certificate pinning предотвращает это: приложение принимает только конкретный сертификат или публичный ключ. Alamofire: ServerTrustManager с PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner с SHA-256 хешем. Операционная сложность: при ротации сертификата старые версии приложения перестают работать. Решение — pinning на публичный ключ CA или поддержка нескольких пинов с grace period. Подробнее о certificate pinning на Wikipedia

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

Мы передаём: исходный код сетевого слоя, документацию по используемым библиотекам, инструкцию по ротации сертификатов, поддержку в течение 2 недель после сдачи.

Сроки и стоимость

Реализация сетевого слоя с REST, retry, кэшированием и offline-режимом — 1–2 недели. Добавление GraphQL или WebSocket — ещё 1–2 недели. gRPC — 2–3 недели, включая кодогенерацию. Стоимость рассчитывается индивидуально после анализа API и требований к offline-поведению. Оценим проект за 1 день — свяжитесь для консультации.