Google is committed to advancing racial equity for Black communities. See how.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

О сообщениях FCM

Firebase Cloud Messaging (FCM) предлагает широкий спектр вариантов и возможностей обмена сообщениями. Информация на этой странице призвана помочь вам понять различные типы сообщений FCM и то, что вы можете с ними делать.

Типы сообщений

С помощью FCM вы можете отправлять клиентам два типа сообщений:

  • Уведомляющие сообщения, иногда называемые «отображаемыми сообщениями». Они обрабатываются FCM SDK автоматически.
  • Сообщения с данными, которые обрабатываются клиентским приложением.

Уведомляющие сообщения содержат предопределенный набор видимых пользователю ключей. Сообщения с данными, напротив, содержат только ваши пользовательские пары ключ-значение. Уведомляющие сообщения могут содержать дополнительные полезные данные. Максимальная полезная нагрузка для обоих типов сообщений составляет 4 КБ, за исключением отправки сообщений из консоли Firebase, которая обеспечивает ограничение в 1024 символа.

Сценарий использования Как отправить
Уведомительное сообщение FCM автоматически отображает сообщение на устройства конечного пользователя от имени клиентского приложения. Уведомляющие сообщения имеют предопределенный набор видимых пользователю ключей и дополнительную полезную нагрузку данных в виде настраиваемых пар ключ-значение.
  1. В надежной среде, такой как облачные функции или сервер приложений, используйте Admin SDK или протоколы сервера FCM : установите ключ notification . Может иметь дополнительную полезную нагрузку данных. Всегда разборный.

    См. Несколько примеров отображения уведомлений и полезных данных отправки запроса.

  2. Используйте композитор уведомлений : введите текст сообщения, заголовок и т. Д. И отправьте. Добавьте дополнительные полезные данные, предоставив пользовательские данные.
Сообщение данных Клиентское приложение отвечает за обработку сообщений с данными. Сообщения с данными содержат только настраиваемые пары ключ-значение без зарезервированных имен ключей (см. Ниже). В надежной среде, такой как облачные функции или сервер приложений, используйте Admin SDK или протоколы сервера FCM : установите только ключ data .

Используйте сообщения с уведомлениями, если вы хотите, чтобы FCM обрабатывал отображение уведомления от имени вашего клиентского приложения. Используйте сообщения с данными, когда хотите обрабатывать сообщения в клиентском приложении.

FCM может отправлять уведомление, включая дополнительные полезные данные. В таких случаях FCM обрабатывает отображение полезных данных уведомления, а клиентское приложение обрабатывает полезные данные.

Уведомительные сообщения

Для тестирования или для маркетинга и повторного вовлечения пользователей вы можете отправлять уведомления с помощью консоли Firebase . Консоль Firebase обеспечивает A / B-тестирование на основе аналитики, чтобы помочь вам уточнить и улучшить маркетинговые сообщения.

Чтобы программно отправлять сообщения уведомления с помощью Admin SDK или протоколов FCM, задайте ключ notification с необходимым предопределенным набором параметров ключа и значения для видимой пользователю части сообщения уведомления. Например, вот уведомление в формате JSON в приложении для обмена мгновенными сообщениями. Пользователь может ожидать увидеть сообщение с заголовком «Португалия против Дании» и текстом «отличный матч!» на устройстве:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

Уведомляющие сообщения доставляются в панель уведомлений, когда приложение находится в фоновом режиме. Для приложений на переднем плане сообщения обрабатываются функцией обратного вызова.

См. Справочную документацию для получения полного списка предопределенных ключей, доступных для создания уведомлений:

Сообщения с данными

Задайте соответствующий ключ с вашими настраиваемыми парами ключ-значение для отправки полезных данных в клиентское приложение.

Например, вот сообщение в формате JSON в том же приложении для обмена мгновенными сообщениями, что и выше, где информация инкапсулирована в общий ключ data и ожидается, что клиентское приложение будет интерпретировать содержимое:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

В приведенном выше примере показано использование поля верхнего уровня или общего поля data , которое интерпретируется клиентами на всех платформах, получающих сообщение. На каждой платформе клиентское приложение получает полезные данные в функции обратного вызова. :

Уведомляющие сообщения с дополнительными данными

Как программно, так и через консоль Firebase вы можете отправлять уведомления, которые содержат дополнительные полезные данные в виде настраиваемых пар ключ-значение. В компоновщике уведомлений используйте поля настраиваемых данных в дополнительных параметрах .

Поведение приложения при получении сообщений, включающих в себя как уведомления, так и полезные данные, зависит от того, находится ли приложение в фоновом или переднем плане - по сути, от того, активно ли оно во время получения.

  • В фоновом режиме приложения получают полезные данные уведомления в панели уведомлений и обрабатывают полезные данные только тогда, когда пользователь нажимает на уведомление.
  • Находясь на переднем плане , ваше приложение получает объект сообщения с обеими доступными полезными нагрузками.

Вот сообщение в формате JSON, содержащее как ключ notification ключ data :

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Настройка сообщения для разных платформ

Как Firebase Admin SDK, так и протокол HTTP FCM v1 позволяют вашим запросам сообщений устанавливать все поля, доступные в объекте message . Это включает в себя:

  • общий набор полей для интерпретации всеми экземплярами приложения, получающими сообщение.
  • зависящие от платформы наборы полей, такие как AndroidConfig и WebpushConfig , интерпретируются только экземплярами приложения, запущенными на указанной платформе.

Блоки, зависящие от платформы, позволяют гибко настраивать сообщения для разных платформ, чтобы гарантировать, что они будут правильно обрабатываться при получении. Бэкэнд FCM будет учитывать все указанные параметры и настраивать сообщение для каждой платформы.

Когда использовать общие поля

Используйте общие поля, когда вы:

  • Таргетинг на экземпляры приложений на всех платформах - iOS, Android и в Интернете
  • Отправка сообщений в темы

Все экземпляры приложения, независимо от платформы, могут интерпретировать следующие общие поля:

Когда использовать поля, зависящие от платформы

Используйте специфичные для платформы поля, если хотите:

  • Отправлять поля только на определенные платформы
  • Отправлять специфичные для платформы поля в дополнение к общим полям

Если вы хотите отправлять значения только на определенные платформы, не используйте общие поля; используйте поля, зависящие от платформы. Например, чтобы отправить уведомление только в iOS и Интернет, но не в Android, вы должны использовать два отдельных набора полей: один для iOS и один для Интернета.

Когда вы отправляете сообщения с определенными параметрами доставки , используйте для их настройки поля, зависящие от платформы. При желании вы можете указать разные значения для каждой платформы. Однако даже если вы хотите установить по существу одно и то же значение для разных платформ, вы должны использовать поля, зависящие от платформы. Это связано с тем, что каждая платформа может интерпретировать значение немного по-разному - например, время жизни устанавливается на Android как время истечения срока в секундах, а на iOS оно устанавливается как срок годности .

Пример: уведомление с параметрами доставки для конкретной платформы

Следующий запрос на отправку v1 отправляет общий заголовок и содержимое уведомления на все платформы, но также отправляет некоторые переопределения для конкретной платформы. В частности, просьба:

  • устанавливает долгий срок жизни для Android и веб-платформ, при этом для приоритета сообщений APN (iOS) устанавливается низкий уровень
  • устанавливает соответствующие клавиши для определения результата нажатия пользователем на уведомление на Android и iOS - click_action и category соответственно.
{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

См. Справочную документацию HTTP v1 для получения полной информации о ключах, доступных в блоках для конкретной платформы в теле сообщения. Дополнительные сведения о создании запросов на отправку, содержащих тело сообщения, см. В разделе Сборка запросов на отправку.

Варианты доставки

FCM предоставляет определенный набор параметров доставки сообщений, отправляемых на устройства Android, и позволяет использовать аналогичные параметры для iOS и в Интернете. Например, "сворачиваемое" поведение сообщения поддерживается на Android через collapse_key FCM, на iOS через apns-collapse-id и на JavaScript / Web через Topic . Подробнее см. Описания в этом разделе и соответствующую справочную документацию.

Не сворачиваемые и сворачиваемые сообщения

Несвертываемое сообщение означает, что на устройство доставляется каждое отдельное сообщение. Не сворачиваемое сообщение доставляет некоторый полезный контент, в отличие от сворачиваемого сообщения, такого как "пинг" без содержания, мобильному приложению, чтобы связаться с сервером для получения данных.

Некоторые типичные варианты использования несвертываемых сообщений - это сообщения чата или критические сообщения. Например, в приложении для обмена мгновенными сообщениями вы хотите доставлять каждое сообщение, потому что каждое сообщение имеет разное содержание.

Для Android существует ограничение в 100 сообщений, которые можно сохранить без свертывания. Если предел достигнут, все сохраненные сообщения удаляются. Когда устройство снова в сети, оно получает специальное сообщение о том, что предел был достигнут. Затем приложение может правильно обработать ситуацию, обычно запрашивая полную синхронизацию с сервера приложения.

Сворачиваемое сообщение - это сообщение, которое может быть заменено новым сообщением, если оно еще не было доставлено на устройство.

Распространенные варианты использования сворачиваемых сообщений - это сообщения, которые используются мобильным приложением для синхронизации данных с сервера. Примером может служить спортивное приложение, которое обновляет пользователям последние результаты. Актуально только самое последнее сообщение.

Чтобы пометить сообщение как сворачиваемое на Android, collapse_key параметр collapse_key в полезные данные сообщения. FCM позволяет серверу приложений одновременно использовать не более четырех различных ключей сворачивания для каждого устройства Android. Другими словами, сервер FCM может одновременно хранить четыре разных сворачиваемых сообщения на каждое устройство, каждое с разными ключами сворачивания. Если вы превысите это число, FCM сохранит только четыре ключа сворачивания без каких-либо гарантий относительно того, какие из них будут сохранены.

Тематические сообщения без полезной нагрузки по умолчанию сворачиваются.

Что мне использовать?

Сворачиваемые сообщения - лучший выбор с точки зрения производительности, если вашему приложению не нужно использовать несвертываемые сообщения. Однако, если вы используете сворачиваемые сообщения, помните, что FCM позволяет серверу соединений FCM использовать максимум четыре различных ключа сворачивания для каждого регистрационного токена в любой момент времени. Вы не должны превышать это количество, иначе это может привести к непредсказуемым последствиям.

Сценарий использования Как отправить
Неразборный Каждое сообщение важно для клиентского приложения и должно быть доставлено. По умолчанию все сообщения, кроме уведомлений, не сворачиваются.
Складной Когда есть более новое сообщение, которое отображает более старое связанное сообщение, не имеющее отношения к клиентскому приложению, FCM заменяет старое сообщение. Например: сообщения, используемые для запуска синхронизации данных с сервера, или устаревшие уведомления. Установите соответствующий параметр в запросе сообщения:
  • collapseKey на Android
  • apns-collapse-id на iOS
  • Topic в сети
  • collapse_key в устаревших протоколах (все платформы)

Установка приоритета сообщения

У вас есть два варианта назначения приоритета доставки сообщениям нисходящего потока на Android: нормальный и высокий приоритет. Доставка обычных и высокоприоритетных сообщений работает следующим образом:

  • Нормальный приоритет. Это приоритет по умолчанию для сообщений с данными . Сообщения с обычным приоритетом доставляются немедленно, когда приложение находится на переднем плане. Когда устройство находится в дремоте, доставка может быть отложена для экономии заряда батареи. Для менее чувствительных ко времени сообщений, таких как уведомления о новой электронной почте, синхронизация пользовательского интерфейса или синхронизация данных приложения в фоновом режиме, выберите обычный приоритет доставки.

    При получении сообщения с обычным приоритетом на Android, которое запрашивает фоновую синхронизацию данных для вашего приложения, вы можете запланировать задачу с помощью WorkManager для ее обработки, когда сеть доступна.

  • Высокий приоритет. FCM пытается немедленно доставить сообщения с высоким приоритетом, позволяя службе FCM пробуждать спящее устройство, когда это необходимо, и выполнять некоторую ограниченную обработку (включая очень ограниченный доступ к сети). Сообщения с высоким приоритетом обычно должны приводить к взаимодействию пользователя с вашим приложением или его уведомлениями. Если FCM обнаружит шаблон, в котором они этого не делают, приоритет ваших сообщений может быть снижен. Android P представил резервные сегменты приложений, которые ограничивают количество сообщений с высоким приоритетом FCM, которые вы можете отправить в свое приложение, которые не приводят к тому, что пользователь использует ваше приложение или просматривает уведомление. Если в ответ на сообщение с высоким приоритетом отображается уведомление таким образом, чтобы он был виден пользователю, то квота резервной корзины вашего приложения не будет использована этим сообщением.

    Поскольку небольшая часть мобильного населения Android работает в сетях с высокой задержкой, не открывайте соединение с вашими серверами до отображения уведомления. Обратный вызов на сервер до окончания разрешенного времени обработки может быть рискованным для пользователей в сетях с высокой задержкой. Вместо этого включите содержимое уведомления в сообщение FCM и немедленно отобразите его. Если вам нужно синхронизировать дополнительный контент в приложении на Android, вы можете запланировать задачу с помощью WorkManager для обработки ее в фоновом режиме.

Вот пример сообщения с обычным приоритетом, отправляемого по протоколу FCM HTTP v1 для уведомления подписчика журнала о том, что новый контент доступен для загрузки:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

Дополнительные сведения о настройке приоритета сообщений для конкретной платформы:

Установка срока жизни сообщения

FCM обычно доставляет сообщения сразу после их отправки. Однако это не всегда возможно. Например, если платформа Android, устройство может быть выключено, отключено от сети или недоступно по иным причинам. Или FCM может намеренно задерживать сообщения, чтобы приложение не потребляло чрезмерные ресурсы и отрицательно влияло на срок службы батареи.

Когда это происходит, FCM сохраняет сообщение и доставляет его, как только это возможно. Хотя в большинстве случаев это нормально, есть некоторые приложения, для которых запоздалое сообщение также может никогда не быть доставлено. Например, если сообщение представляет собой уведомление о входящем вызове или видеочате, оно имеет смысл только в течение короткого периода времени, прежде чем вызов будет завершен. Или, если сообщение является приглашением на мероприятие, оно бесполезно, если оно получено после того, как мероприятие закончилось.

На Android и в Интернете / JavaScript вы можете указать максимальный срок жизни сообщения. Значение должно иметь продолжительность от 0 до 2 419 200 секунд (28 дней), и это соответствует максимальному периоду времени, в течение которого FCM сохраняет и пытается доставить сообщение. Запросы, не содержащие этого поля, по умолчанию имеют максимальный период в четыре недели.

Вот несколько возможных вариантов использования этой функции:

  • Входящие звонки в видеочат
  • События приглашения с истекающим сроком действия
  • Календарь событий

Еще одно преимущество указания срока жизни сообщения состоит в том, что FCM никогда не регулирует сообщения со значением времени жизни 0 секунд. Другими словами, FCM гарантирует максимальные усилия для сообщений, которые должны быть доставлены «сейчас или никогда». Имейте в виду, что значение time_to_live равное 0, означает, что сообщения, которые не могут быть доставлены немедленно, отбрасываются. Однако, поскольку такие сообщения никогда не сохраняются, это обеспечивает лучшую задержку для отправки уведомлений.

Вот пример запроса, который включает TTL:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

Получение сообщений от нескольких отправителей

FCM позволяет нескольким сторонам отправлять сообщения в одно и то же клиентское приложение. Например, предположим, что клиентское приложение представляет собой агрегатор статей с несколькими участниками, и каждый из них должен иметь возможность отправлять сообщение при публикации новой статьи. Это сообщение может содержать URL-адрес, по которому клиентское приложение может загрузить статью. Вместо того, чтобы централизовать все действия по отправке в одном месте, FCM дает вам возможность разрешить каждому из этих участников отправлять свои собственные сообщения.

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

Убедитесь, что вы не добавляете несколько идентификаторов отправителя в один запрос токена, так как это может привести к непредсказуемым результатам. Совершайте каждый звонок отдельно, один раз для каждого идентификатора отправителя.

Наконец, поделитесь токеном регистрации с соответствующими отправителями, и они смогут отправлять сообщения в клиентское приложение, используя свои собственные ключи аутентификации.

Обратите внимание, что существует ограничение в 100 отправителей.

Время жизни сообщения

Когда сервер приложений отправляет сообщение в FCM и получает обратно идентификатор сообщения, это не означает, что сообщение уже было доставлено на устройство. Скорее, это означает, что он был принят к доставке. Что происходит с сообщением после его принятия, зависит от многих факторов.

В лучшем случае, если устройство подключено к FCM, экран включен и нет ограничений на регулирование, сообщение доставляется сразу.

Если устройство подключено, но находится в состоянии дремоты, FCM сохраняет сообщение с низким приоритетом, пока устройство не перестанет дремать. И здесь играет роль флаг collapse_key : если уже есть сообщение с тем же ключом свертывания (и токеном регистрации), сохраненное и ожидающее доставки, старое сообщение отбрасывается, а новое сообщение занимает его место (т. Е. Старое сообщение). сообщение сворачивается новым). Однако, если ключ свертывания не установлен, как новые, так и старые сообщения сохраняются для будущей доставки.

Если устройство не подключено к FCM, сообщение сохраняется до тех пор, пока соединение не будет установлено (опять же с соблюдением правил ключа свертывания). Когда соединение установлено, FCM доставляет на устройство все ожидающие сообщения. Если устройство больше не подключается (например, если оно было сброшено к заводским настройкам), время ожидания сообщения истекает и оно удаляется из хранилища FCM. time_to_live аут по умолчанию составляет четыре недели, если не time_to_live флаг time_to_live .

Чтобы получить больше информации о доставке сообщения:

    Чтобы получить больше информации о доставке сообщений на Android или iOS, просмотрите панель отчетности FCM , на которой записывается количество сообщений, отправленных и открытых на устройствах iOS и Android, а также данные о «показах» (уведомлениях, которые видят пользователи) для Android. Программы.

Для устройств Android с включенным обменом сообщениями по прямому каналу, если устройство не подключалось к FCM более одного месяца, FCM все равно принимает сообщение, но немедленно его отбрасывает. Если устройство подключается в течение четырех недель после последнего сообщения с данными, которое вы ему отправили, ваш клиент получит обратный вызов onDeletedMessages () . Затем приложение может правильно обработать ситуацию, обычно запрашивая полную синхронизацию с сервера приложения.

Наконец, когда FCM пытается доставить сообщение на устройство и приложение было удалено, FCM сразу же отбрасывает это сообщение и аннулирует регистрационный токен. Последующие попытки отправить сообщение на это устройство приводят к ошибке NotRegistered .

Регулирование и масштабирование

Наша цель - всегда доставлять каждое сообщение, отправленное через FCM. Однако доставка каждого сообщения иногда приводит к ухудшению общего пользовательского опыта. В других случаях нам необходимо установить границы, чтобы гарантировать, что FCM предоставляет масштабируемую услугу для всех отправителей.

Сворачиваемое регулирование сообщений

Как описано выше, сворачиваемые сообщения - это уведомления без содержания, предназначенные для сворачивания друг над другом. В случае, если разработчик слишком часто повторяет одно и то же сообщение в приложении, мы задерживаем (дросселируем) сообщения, чтобы уменьшить влияние на батарею пользователя.

Например, если вы отправляете большое количество новых запросов на синхронизацию электронной почты на одно устройство, мы можем отложить следующий запрос синхронизации электронной почты на несколько минут, чтобы устройство могло синхронизировать с более низкой средней скоростью. Это регулирование осуществляется строго для ограничения воздействия батареи на пользователя.

Если ваш вариант использования требует шаблонов отправки с большим количеством пакетов, то правильным выбором могут быть не сворачиваемые сообщения. Для таких сообщений обязательно включайте содержимое в такие сообщения, чтобы снизить стоимость батареи.

Мы ограничиваем количество сворачиваемых сообщений пакетом из 20 сообщений для каждого приложения на каждое устройство с повторным заполнением 1 сообщения каждые 3 минуты.

Дросселирование сервера XMPP

Мы ограничиваем скорость, с которой вы можете подключаться к серверам FCM XMPP, до 400 подключений в минуту для каждого проекта. Это не должно быть проблемой для доставки сообщений, но важно для обеспечения стабильности нашей системы.

Для каждого проекта FCM допускает 2500 параллельных подключений.

Максимальная скорость передачи сообщений на одно устройство

Вы можете отправлять до 240 сообщений в минуту и ​​5000 сообщений в час на одно устройство. Этот высокий порог предназначен для кратковременных всплесков трафика, например, когда пользователи быстро взаимодействуют в чате. Этот предел предотвращает непреднамеренный разряд батареи устройства при ошибках отправки логики.

Лимит сообщений в восходящем направлении

Мы ограничиваем количество исходящих сообщений 1 500 000 в минуту на каждый проект, чтобы избежать перегрузки конечных серверов исходящего потока.

Мы ограничиваем количество исходящих сообщений на устройство до 1000 в минуту, чтобы защитить от разрядки батареи из-за плохого поведения приложения.

Лимит сообщений в теме

Скорость добавления / удаления подписки на тему ограничена 3000 QPS на проект.

Для скорости отправки сообщений см. Регулирование разветвления .

Дросселирование разветвления

Разветвление сообщений - это процесс отправки сообщения на несколько устройств, например, когда вы настраиваете таргетинг на темы и группы или когда вы используете композитор уведомлений для таргетинга на аудитории или сегменты пользователей.

Разветвление сообщений не происходит мгновенно, поэтому иногда одновременно выполняется несколько разветвлений. Мы ограничиваем количество одновременных разветвлений сообщений на проект до 1000. После этого мы можем отклонить дополнительные запросы разветвления или отложить разветвление запросов до тех пор, пока не будут завершены некоторые из уже выполняемых разветвлений.

Фактически достижимая скорость разветвления зависит от количества проектов, одновременно запрашивающих разветвление. Частота разветвления 10 000 запросов в секунду для отдельного проекта не редкость, но это число не является гарантией и является результатом общей нагрузки на систему. Важно отметить, что доступная емкость разветвления делится между проектами, а не между запросами разветвления. Итак, если в вашем проекте есть два выполняющихся разветвления, то каждое разветвление будет видеть только половину доступной скорости разветвления. Рекомендуемый способ максимизировать скорость разветвления - одновременное выполнение только одного активного разветвления.

Порты FCM и ваш брандмауэр

Если в вашей организации есть брандмауэр для ограничения трафика в Интернет или из Интернета, вам необходимо настроить его так, чтобы мобильные устройства могли подключаться к FCM, чтобы устройства в вашей сети могли получать сообщения. FCM обычно использует порт 5228, но иногда использует 5229 и 5230.

Для исходящих соединений FCM не предоставляет конкретные IP-адреса, потому что наш диапазон IP-адресов слишком часто меняется, а правила брандмауэра могут устареть, что повлияет на работу пользователей. В идеале, порты 5228-5230 занести в белый список без ограничений по IP. Однако, если у вас должно быть ограничение IP, вы должны занести в белый список все IP-адреса, перечисленные в goog.json . Этот большой список регулярно обновляется, и вам рекомендуется обновлять свои правила ежемесячно. Проблемы, вызванные ограничениями IP-адресов брандмауэра, часто носят временный характер и их трудно диагностировать.

Открытые порты для входящих сообщений:

  • 5228
  • 5229
  • 5230
  • 443

Порты для исходящих соединений:

Один из них (предпочтителен вариант №1):

  1. Нет ограничений по IP
  2. Все IP-адреса для доменов по умолчанию.

    Чтобы получить актуальный список этих адресов, следуйте инструкциям, описанным в разделе IP-адреса для доменов по умолчанию .

Межсетевые экраны трансляции сетевых адресов и / или проверки пакетов с отслеживанием состояния:

Если в вашей сети реализована трансляция сетевых адресов (NAT) или Stateful Packet Inspection (SPI), установите 30-минутный или больший тайм-аут для наших соединений через порты 5228-5230. Это позволяет нам обеспечивать надежную связь, снижая при этом расход заряда батареи мобильных устройств ваших пользователей.

Полномочия

В зависимости от того, какие функции FCM вы реализуете, вам могут потребоваться следующие учетные данные из вашего проекта Firebase:

ID проекта Уникальный идентификатор вашего проекта Firebase, используемый в запросах к конечной точке HTTP FCM v1. Это значение доступно в панели настроек консоли Firebase .
Регистрационный токен

Уникальная строка токена, которая идентифицирует каждый экземпляр клиентского приложения. Маркер регистрации требуется для обмена сообщениями с одним устройством и группой устройств. Обратите внимание, что регистрационные токены должны храниться в секрете.

Удостоверение личности отправителя Уникальное числовое значение, созданное при создании проекта Firebase, доступное на вкладке Cloud Messaging панели настроек консоли Firebase. Идентификатор отправителя используется для идентификации каждого отправителя, который может отправлять сообщения в клиентское приложение.
Токен доступа Кратковременный токен OAuth 2.0, который авторизует запросы к API HTTP v1. Этот токен связан с учетной записью службы, которая принадлежит вашему проекту Firebase. Чтобы создать и повернуть токены доступа, выполните действия, описанные в разделе « Авторизация запросов на отправку» .
Ключ сервера (для устаревших протоколов)

Ключ сервера, который разрешает вашему серверу приложений доступ к сервисам Google, включая отправку сообщений через устаревшие протоколы Firebase Cloud Messaging. Вы получаете ключ сервера при создании проекта Firebase. Вы можете просмотреть его на вкладке Cloud Messaging на панели настроек консоли Firebase.

Важно: не включайте ключ сервера в код клиента. Кроме того, убедитесь, что вы используете только ключи сервера для авторизации сервера приложений. Ключи Android, iOS и браузера отклоняются FCM.