Los tiempos de entrega msg de GCM son WILDLY erráticos

He configurado una aplicación de Android con soporte de GCM y tengo una pequeña aplicación de prueba para enviar un msg a la aplicación. Cuando ejecuto la aplicación en el emulador, puedo ver (a través de mensajes de registro) que se registra con GCM y obtiene un Token.

Entonces, cuando pongo el token en mi aplicación de prueba y que se envíe un msg, el resultado muestra que 1 msg fue enviado, 0 falló y 0 tenía cambios de ID.

A veces el msg aparece casi inmediatamente, a veces toma 20 minutos. El viernes, mis 2 mensajes de prueba tardaron 15 y 20 minutos. Los 2 primeros que envié esta mañana fueron inmediatamente, el siguiente no ha aparecido aún – sólo ha sido de 10 minutos …

¿Hay algo que pueda hacer para que los plazos de entrega siempre sean rápidos? Un retraso aleatorio de 20 minutos será casi una condición inaceptable.

Tuvimos el mismo problema, pero varió de red a red. Creemos que fue el enrutador de concentrador doméstico (un Virgin Super Hub) que dejó caer la conexión después de cinco minutos de inactividad. Puede confirmar enviando un mensaje GCM vacío cada dos minutos para mantener la conexión viva.

A continuación se ofrece una explicación más detallada de lo que hicimos: https://groups.google.com/d/msg/android-gcm/Y33c9ib54jY/YxnCkaPRHRQJ

No puede garantizar una entrega rápida porque GCM a la conectividad del dispositivo puede ser pobre como CommonsWare ha señalado. Hay, sin embargo, dos posibles retrasos en el tren de entrega: 1) GCM conexión al teléfono (como se mencionó anteriormente) y 2) El retraso en el mensaje realmente se envía desde el servidor GCM. Si establece el parámetro 'time_to_live' en 0 segundos en su aplicación de envío, puede probar al menos dónde está ocurriendo el retardo.

Un valor de 0 segundos significa que el mensaje se enviará inmediatamente y si la entrega no tiene éxito, el mensaje se descartará en el servidor GCM. No es un valor práctico para el uso de la vida real, pero le permitirá averiguar qué parte del tren de entrega está causando el retraso.

GCM se informa que tiene un problema bastante grave con el ritmo cardíaco de mantener vivo no ser tan fiable. Por lo tanto, ya que sólo se envía una vez cada 15 minutos (a través de 3G) o 28 minutos (a través de Wifi), si por alguna razón la conexión del servidor se cayó, puede no ser restaurado durante varios minutos.

Este tipo de complicaciones incitó a desarrollar una solución que no dependa de una red de terceros para ofrecer notificaciones push masivas y escalables a aplicaciones Android sin conexión.

https://help.pubnub.com/entries/21720011-Can-my-Android-App-Receive-Messages-While-Inactive

De hecho, esto se debe a intervalos de frecuencia cardíaca poco realistas en Google Cloud Messaging.

Este es posiblemente el error más frustrante en GCM. GCM funciona mediante el mantenimiento de una conexión de socket inactiva desde un dispositivo Android a los servidores de Google. Esto es grande porque apenas consume energía de la batería (contrario a la encuesta), y permite que el dispositivo se despierte al instante cuando llega un mensaje. Para asegurarse de que la conexión permanezca activa, Android enviará un latido cada 28 minutos en la conexión móvil y cada 15 minutos en WiFi. Si se produjo un error en la pulsación, se finalizó la conexión y GCM volverá a establecerla e intentará recuperar las notificaciones push pendientes. Cuanto mayor sea el intervalo de latido, menor será la batería consumida y menos tiempo habrá que despertar el dispositivo del sueño.

Sin embargo, esto tiene un gran precio: cuanto más largo sea el intervalo de latido, más tiempo tardará en identificar una conexión de socket roto. Google no ha probado estos intervalos en situaciones de la vida real a fondo antes de implementar GCM. El problema con estos intervalos es causado por enrutadores de red y operadores móviles, que desconectan las conexiones de socket inactivas después de unos minutos de inactividad. Por lo general, esto es más común con los routers domésticos baratos, cuyos fabricantes decidieron una vida útil máxima de una conexión de socket inactiva y la terminan para ahorrar recursos. Estos enrutadores sólo pueden manejar un número finito de conexiones simultáneas, por lo que esta medida se toma para evitar la sobrecarga. Esto resulta en terminales GCM terminados, y cuando llega el momento de entregar un mensaje GCM, no llega al dispositivo. El dispositivo sólo se dará cuenta de que la conexión se ha roto cuando es hora de enviar un latido, 0 a 28 minutos más tarde, haciendo la notificación de empuje inútil en algunas situaciones (cuando el mensaje es crítico, por ejemplo). En mi experiencia, la mayoría de los enrutadores baratos terminan conexiones inactivas después de aproximadamente 5 a 10 minutos de inactividad.

Escribí un artículo entero sobre este y otros asuntos de GCM:

http://eladnava.com/google-cloud-messaging-extremely-unreliable/

Una alternativa a la mensajería de Google Cloud

Pushy ( https://pushy.me/ ) es una pasarela independiente de notificación push, completamente independiente de GCM. Mantiene su propia conexión de socket de fondo, al igual que GCM, para recibir notificaciones push. El protocolo subyacente es MQTT, un pub / sub-protocolo extremadamente ligero, que utiliza muy poco ancho de banda de red y batería.

Una gran ventaja de Pushy es que el código para enviar una notificación push (desde el servidor), y el registro del dispositivo para notificaciones push, es realmente intercambiable entre GCM y Pushy. Esto hace que sea super fácil de cambiar a Pushy después de la aplicación de GCM y tener que zanja por su inestabilidad.

(Descubrimiento completo: fundé a Pushy para mis propios proyectos y me di cuenta de que muchas aplicaciones se beneficiarían de tal servicio)

Este asunto es importante para mí.

He configurado este código dentro de un controlador de temporizador de un segundo para enviar un mensaje de GCM cada 2 minutos. La esperanza es que mantendrá las cosas vivas

if ((mOneSecondTick %120) == 0){ // q 1 minute check when we got last call.... long lDiff = System.currentTimeMillis() - GCMlastCall; if (PushAndroidActivity.GCMAvailable){ Log.d("pushAndroidActivity",String.format("(mOneSecondTick %d",lDiff)); if (lDiff > 122 * 1000){ // more than a minute Intent intent = new Intent(StayInTouch.this,PushAndroidActivity.class); 2startActivity(intent); }else{ // every 2 minutes send out a gcm message... asyncWebCall(String.format(AgeingLib.GCMTICKLE,androidid),0); return; // only if it sends a tickle and all is well... } }else{ Log.d("pushAndroidActivity",String.format("(mOneSecondTick mod60 no GCM on this device")); } } 

GCMlastCall es la última vez que se recibió un mensaje, por lo que podemos decir si gcm se detuvo.

Ha estado trabajando por un par de días ahora parece bien

¿Hay algo que pueda hacer para que los plazos de entrega siempre sean rápidos?

En la producción, los tiempos de entrega serán muy variables debido a que los dispositivos móviles son móviles y, por lo tanto, tienen conectividad variable, por encima y más allá de cualquier problema de entrega dentro de GCM.

  • Android Handler Message y ListView
  • Aplicación de chat en android para que el remitente y el mensaje del receptor debe estar en el lado diferente
  • Obtener todos los sms de un teléfono Android
  • Enviar mensajes MIDI por USB en Android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.