studio - servicios web android
Reglas de conexión de socket persistentes de Android (1)
He estado haciendo algunas pruebas para una solución de notificación de inserción personalizada para dispositivos Android que usan sockets persistentes. Me gustaría compartir mis hallazgos y validar los resultados.
Descripción simple
Las aplicaciones ejecutan un servicio de primer plano y establecen una conexión con el servidor y mantienen esa conexión a través de un ping agresivo (intervalo de 10 segundos). Si alguna vez se detecta que la conexión está muerta, la aplicación intenta volver a conectarse indefinidamente. El servidor envía notificaciones a través del canal dúplex.
Prueba 1:
Pinging is done using a timer at 10 second intervals.
Server sends notification every minute.
Applications acquires wifi and wake locks.
Duration : 8 hours
Battery loss : ~14%
Prueba 2:
Pinging is done using AlarmManager at 10 second intervals.
Server sends notification every minute.
Application acquires only a wifilock
Duration : 8 hours
Battery loss : ~7%
Suposiciones: un paquete de red entrante automáticamente activa la CPU, por lo que no es necesario un bloqueo por activación. Utilizar AlarmManager para hacer ping (en lugar de temporizadores) significa que no necesitamos un wakelock.
Eliminar ese wakelock realmente parecía ayudar a la batería. Sorprendentemente, el ping agresivo en cualquiera de las soluciones no afectó la duración de la batería tanto como yo hubiera esperado. (Tuvimos muchas otras pruebas, incluida una en la que la aplicación solo contenía un wifilock y no hizo nada, lo que causó una pérdida de batería de alrededor del 4% al 5% durante el mismo período)
Como la aplicación pudo enviar con éxito todas las solicitudes de ping y recibir todos los mensajes entrantes, creo que mis suposiciones son correctas. Pero me encantaría obtener alguna confirmación de cualquier experto.
Una pregunta más: si la aplicación debía escuchar las conexiones entrantes. Necesitaría sostener un wakelock en este caso, ¿correcto? ¿Una conexión entrante no despierta a la CPU? No vamos por esta ruta, solo queríamos confirmar.
Además, no recomiende GCM, se ha descartado por política de la compañía.
Gracias.
Dado que ha habido cierto interés en esta pregunta y no hay confirmaciones, responderé ahora. Ha pasado un tiempo desde que se realizaron las pruebas, y se ha creado una solución de nivel de producción y se ha probado rigurosamente. La eliminación del bloqueo de activación aún ayudó a la batería y no se encontraron otros problemas, como solicitudes de ping faltantes o notificaciones entrantes, por lo que esa es la única validación que recibí sobre dichos supuestos.
Cosas adicionales a tener en cuenta:
En el método OnReceive de BroadcastReceiver para la alarma de ping, si no está llamando directamente al socket (generando un nuevo hilo o intento), tendrá que mantener un bloqueo de activación hasta que finalice la solicitud de ping. Android tiene un bloqueo de activación solo hasta que vuelve OnReceive, después de eso es posible (pero raro) que la CPU pueda dormir antes de que finalice el ping.
Use un bloqueo Wifi de alto rendimiento si las notificaciones son delicadas.
Hubo otro problema específico del dispositivo que afectó la solución, se trata here .
Actualizar
Se encontró con el siguiente problema con Android 5.1: Android Issue
Actualización 2
Necesita codificar el modo Doze para Android 6.0: Modo Doze