Я работаю с GCM в своем приложении, и у меня есть проблема.
В большинстве случаев я получаю сообщения сразу, но иногда сообщения появляются через 5 минут, один за другим, как будто они застряли в пути. Это нормально?
Сообщения GCM для Android слишком долго
Ответ 1
Часть каркаса GCM на клиентском телефоне использует TCP-соединение на порту 5228. Это соединение используется для push-уведомлений, но поскольку каждое соединение tcp может идти в тайм-аут с некоторыми маршрутизаторами/несущими которые применяют строгие политики для уничтожения неактивных подключений tcp (tcp idle timeout).
Большинство маршрутизаторов wifi убивают неактивные соединения через 5 минут, например, мои.
В рамках GCM используется механизм keep-alive для отправки сетевого пакета через каждые 15 минут на Wi-Fi и каждые 28 минут на 3G. Этот keep-alive не всегда надежный для всех пользователей.
Я открыл проблему для google здесь: https://productforums.google.com/forum/#!category-topic/nexus/connecting-to-networks-and-devices/fslYqYrULto Они соглашаются, что в настоящее время проблема.
Ответ 2
Я еще не заметил, что в моем крайне ограниченном тестировании до сих пор, но из моего понимания документации это не звучит ужасно неожиданно:
GCM обычно доставляет сообщения сразу после их отправки. Однако это не всегда возможно. Например, устройство может быть отключено, отключено или недоступно. В других случаях сам отправитель может запросить доставку сообщений до тех пор, пока устройство не станет активным, используя флаг delay_while_idle. Наконец, GCM может преднамеренно задерживать сообщения, чтобы приложение не потребляло чрезмерные ресурсы и отрицательно влияло на срок службы батареи.
Между этим и языком во всей остальной документации, то, что вы описали, похоже на то, что я ожидаю. Там нет гарантии немедленной доставки; вы обычно будете получать сообщения сразу, но иногда вы этого не сделаете.
Ответ 3
Я нахожу то же самое, что и оригинальный плакат. Кажется, что до 5 минут "проснуться", а затем очень быстро обрабатывает сообщения.
Мое приложение обрабатывает текстовые объекты в разговоре с глухим человеком. Вызывающий инициирует разговор, а глухой человек отвечает по телефону. Задержка происходит только на первом шаге, новое сообщение "не в синем". Как только это делается для первого (приложение, устройство, системный идентификатор?), Другие проходят очень быстро, почти мгновенно.