Интеграция Photon для мультиплеера мобильной игры

Представьте: ваша мобильная игра на Unity, вы интегрировали Photon, но при смене Wi-Fi на 4G соединение рвётся, и игроки вылетают из комнаты. Знакомая проблема? Мы решаем её на уровне кода: настраиваем playerTtl, реконнект и ручную синхронизацию, чтобы трафик не улетал впустую. Многие разработчики допускают одну и ту же ошибку: полагаются на стандартные компоненты PhotonTransformView, что приводит к избыточному трафику и проблемам с реконнектом. Мы же предлагаем проверенный подход, который сокращает трафик в 3–5 раз и обеспечивает стабильное соединение на мобильных устройствах. За 5 лет работы с Photon мы выполнили 15+ проектов для мобильных игр — от простых лобби до сложных квестов с матчмейкингом. Если вы хотите избежать типичных проблем и сэкономить на трафике, обращайтесь к нам для интеграции Photon в вашу игру.

Как правильно синхронизировать объекты в Photon?

PhotonView — основной компонент синхронизации. Каждый сетевой объект получает ViewID. Синхронизацию позиции и ротации через PhotonTransformView используют по умолчанию — это работает, но рассылает обновления на каждый FixedUpdate, даже если объект не двигался.

Правильный подход: реализовать IPunObservable.OnPhotonSerializeView с ручным контролем отправки данных:

public void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info)
{
    if (stream.IsWriting)
    {
        // Отправляем только если изменилось значимо
        if (Vector3.Distance(_lastSentPosition, transform.position) > 0.01f)
        {
            stream.SendNext(transform.position);
            stream.SendNext(transform.rotation);
            _lastSentPosition = transform.position;
        }
    }
    else
    {
        _networkPosition = (Vector3)stream.ReceiveNext();
        _networkRotation = (Quaternion)stream.ReceiveNext();
    }
}

На клиенте принятое _networkPosition не применяется напрямую — интерполируем через Vector3.MoveTowards или Lerp по времени пакета из PhotonMessageInfo.SentServerTime. Как утверждает документация Photon, такой подход минимизирует сетевой трафик без потери плавности.

Сравнение методов синхронизации:

Ручная синхронизация уменьшает трафик в 3–5 раз. Для мобильных игр это критично, так как Photon тарифицируется по CCU.

Как работает RPC и когда его использовать?

photonView.RPC — для событий, которые должны гарантированно дойти: урон, смерть, подбор предмета. RpcTarget.All рассылает всем в комнате включая отправителя. RpcTarget.Others — всем кроме.

Типичная ошибка: использовать RPC для позиционных обновлений. RPC надёжный (TCP-like поведение), добавляет overhead на подтверждение. Для позиций — PhotonNetwork.SendRate + OnPhotonSerializeView, для важных событий — RPC.

PhotonNetwork.SendRate по умолчанию 20, SerializationRate — 10. Для мобильного баланс трафика vs плавность: 15/10.

Подключение и комнаты

PhotonNetwork.ConnectUsingSettings(); // использует PhotonServerSettings asset

void OnConnectedToMaster() {
    PhotonNetwork.JoinRandomOrCreateRoom(
        expectedCustomRoomProperties: null,
        expectedMaxPlayers: 4,
        matchingType: MatchmakingMode.FillRoom,
        typedLobby: null,
        sqlLobbyFilter: null,
        createIfNotFound: true
    );
}

RoomOptions.CustomRoomPropertiesForLobby — массив ключей, видимых в лобби для фильтрации. Передавать всё в lobby-свойства не нужно: только то, по чему фильтруют (регион, режим игры, карта).

Почему игроки отключаются при смене сети?

Смена сети. Photon SDK поддерживает PhotonNetwork.ReconnectAndRejoin() — но только если комната с playerTtl > 0. По умолчанию playerTtl = 0, игрок считается вышедшим мгновенно. Для мобильного: playerTtl = 10000 (10 секунд на reconnect).

iOS Background. При уходе в фон iOS агрессивно глушит сетевые соединения. Photon разорвётся через 5-10 секунд. Для игр, где это критично — UIBackgroundModes: voip (с осторожностью, Apple может отклонить) или graceful disconnect.

Трафик. Photon Realtime тарифицирует по CCU (одновременные пользователи). 20 CCU бесплатно. При интеграции стоит добавить Photon Dashboard в мониторинг — видно кол-во сообщений, байты, пики. Мы включаем в работу настройку Photon Dashboard и оптимизацию кода для снижения трафика на 30–50%.

Что входит в нашу работу по интеграции Photon?

• Аудит текущей реализации (если есть)
• Настройка Photon SDK и конфигурации (регионы, комнаты, TTL)
• Реализация синхронизации через IPunObservable (ручное управление трафиком)
• Интеграция матчмейкинга с кастомными свойствами
• Настройка RPC и надёжных событий
• Оптимизация для мобильных устройств (реконнект, трафик, background)
• Тестирование на 10+ реальных устройствах в разных сетях
• Предоставление документации и поддержка после внедрения

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

Базовая интеграция Photon Realtime с комнатами, синхронизацией позиций и RPC: от 3 до 7 дней. Полноценная система с матчмейкингом, custom properties и мобильной оптимизацией: от 2 до 3 недель. Стоимость рассчитывается индивидуально — оценим ваш проект за 1 день.

Готовы обсудить детали? Свяжитесь с нами, чтобы получить консультацию и точную оценку. Обращайтесь к нам для надёжной интеграции Photon в вашу мобильную игру.

Интеграция 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 день — свяжитесь для консультации.