android - sale - Conexiones de enchufe y sondeo. ¿Cuál es una mejor solución en términos de duración de la batería?
se me rompio la entrada del cargador del celular (3)
La batería está muy relacionada con las transiciones de estado de radio en 3G desde DCH / FACH / IDLE. Si desea tener una aplicación que sea eficiente desde el punto de vista energético, debe enviar tantos datos como sea posible en un intervalo de tiempo limitado, irrelevante para una conexión persistente o no ...
Entonces ... estoy haciendo una aplicación para Android. La aplicación necesita enviar y recibir datos de chat en tiempo real (debe ser un socket) pero también necesita enviar comandos (que no lo hacen porque el cliente sabe cuándo está enviando algo).
Necesito saber cuál es la mejor solución en términos de ahorrar batería del usuario.
a) Abrir y cerrar la conexión cada vez que se envía un comando, si la pestaña de chat se abre, mantenga la conexión constante.
b) Mantenga la conexión constante todo el tiempo.
He echado un vistazo por Internet pero he obtenido respuestas mixtas, algunos dicen que mantener una conexión persistente es malo para la duración de la batería y otros dicen que no (ejemplo: "¿Estás preguntando si mantener abierta una conexión TCP va a agotar la batería? ¿Vive? Tal vez estoy MUY FUERA aquí, pero tener una conexión abierta no debería desperdiciar la vida de la batería ... Si crees que sí, me encantaría saber de dónde sacaste esa información. Suena muy extraño para mí " ).
O si hay otra solución que sería mejor. No creo que el C2DM de Google sea muy útil en esta situación tampoco.
Básicamente, ¿qué es lo que agota más la batería: tener una conexión persistente, o abrir y cerrar la conexión a menos que la pestaña de chat esté abierta?
¡Gracias!
Para mantener realmente abierta una conexión, es probable que tengas que enviar señales de latido de un lado a otro, ya que cualquier enrutador con estado entre el dispositivo Android y tus servidores se olvidaría de la conexión después de un tiempo de espera relativamente corto.
Lo que es mejor, todo depende de cuánto tiempo piense que irá sin necesidad de conectarse al servidor. Si se conecta una vez cada 30 segundos más o menos la mayor parte del tiempo, definitivamente mantenga la conexión abierta, pero de lo contrario, será mejor que la cierre.
Mantener abierta una conexión de socket TCP inactiva (sin enviar ni recibir datos) no consumirá (o al menos no debería) más batería que tenerla cerrada. Esto se debe a que una conexión TCP inactiva no utiliza ancho de banda ni ciclos de CPU (*).
Dicho esto, mantener una conexión TCP abierta durante períodos prolongados puede no ser una buena opción para un dispositivo móvil, porque las conexiones TCP no interactúan bien con las computadoras que se quedan dormidas. El escenario del problema sería el siguiente: su usuario de Android pone su dispositivo Android en reposo mientras su aplicación se está ejecutando, y luego el programa del usuario remoto (o lo que sea que esté al otro extremo de la conexión TCP) envía algunos datos a través de la transmisión TCP. El programa del usuario remoto nunca recupera ningún ACK del dispositivo Android porque, por supuesto, el dispositivo Android está inactivo, por lo que la pila TCP del dispositivo remoto asume que los paquetes TCP que envió se deben haber perdido y responde al aumentar el tiempo de espera. disminuyendo su tamaño de ventana TCP (también conocido como número de paquetes TCP permitidos en vuelo a la vez) y reenviando los paquetes TCP. Pero el dispositivo Android todavía está dormido y, por lo tanto, vuelve a ocurrir lo mismo. El resultado es que unos minutos más tarde, el extremo remoto de la conexión TCP se ha ralentizado hasta el punto en que, incluso si el dispositivo Android se despertara, la conexión TCP probablemente sea demasiado lenta para ser utilizable, y en ese momento su programa tendrá que cerrar la conexión TCP empantanada y poner en marcha una nueva de todos modos, ¿por qué molestarse en tratar de mantenerla abierta?
Por lo tanto, mi recomendación sería ir con la opción (a), con la condición de que cierre la conexión TCP como parte de su rutina device-is-going-to-sleep-now.
Una posible advertencia sería si Android tiene una función en la que mantener abierta una conexión TCP hace que el WiFi o el hardware de la red celular permanezcan encendidos en una situación en la que de lo contrario podría dormir, si ese es el caso, entonces el Android el dispositivo pagaría un costo de batería por alimentar la antena, que de otra manera no habría tenido que pagar. No conozco ninguna lógica de Android como esa, pero solo he usado Android un poco, así que podría ser ignorancia de mi parte. Por lo menos vale la pena probarlo.
(*) Bueno, técnicamente TCP envía un paquete "keepalive" cada cierto tiempo mientras se abre una conexión TCP, y eso usa algunos ciclos de CPU y alimentación de antena ... pero el intervalo predeterminado para enviar paquetes keepalive en Android es de dos horas , así que dudo que la potencia utilizada para eso sea notable.