28 votes

Règles de connexion de socket persistant Android

J'ai fait quelques tests pour une mesure de notification push solution pour les appareils Android à l'aide persistante sockets. Je voudrais partager mes découvertes et de valider les résultats.

Description Simple
Les applications s'exécute avec un premier plan de service et établit une connexion avec le serveur et soutient que la connexion via agressif ping (@ 10 secondes d'intervalle). Si la connexion est toujours détecté comme morts, l'application continue d'essayer de se reconnecter indéfiniment. Le serveur envoie des notifications par canal duplex.

Test 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%

Test 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%

Hypothèses: l'arrivée d'Un paquet réseau réveille automatiquement le CPU, donc pas besoin d'un réveil de verrouillage. À l'aide de AlarmManager de ping(au lieu d'un "timer") signifie que l'on n'a pas besoin d'un wakelock.

Retrait de wakelock air de vraiment l'aide de la batterie. Étonnamment, l'agressivité de la commande ping sur l'une ou l'autre solution n'a pas d'incidence sur la vie de la batterie autant que je l'aurais attendu. (Nous avons eu de nombreux autres tests, y compris celui où la demande a tenu une wifilock et n'a rien fait qui a causé autour de 4% à 5% de la batterie de perte au cours de la même période)

Depuis, l'application a réussi à envoyer toutes les requêtes ping et de recevoir tous les messages entrants, je pense que mes hypothèses sont correctes. Mais j'aimerais obtenir une confirmation de tous les experts.

Encore une question: Si l'application a été à la place d'écouter les connexions entrantes. J'aurais besoin de tenir un wakelock dans ce cas, correct? Une connexion entrante ne se réveille pas le CPU? Nous n'allons pas vers le bas de cette route, mais je voulais juste confirmer.

Aussi, s'il vous plaît ne pas recommander GCM, il a été écarté par la politique de l'entreprise.

Merci.

11voto

Alex Points 779

Depuis il y a eu un certain intérêt dans cette question, et aucun des confirmations, je vais juste répondre maintenant. Il a été un moment depuis que les tests ont été fait, et un niveau de production de la solution a été créé et rigoureusement testés. Retirer le sillage de verrouillage a aidé à la batterie et pas d'autres questions ont été trouvés tels que l'absence de ping des demandes ou des notifications entrantes, c'est la seule justification que j'ai reçu sur ces hypothèses.

Les autres Choses à Noter:

  • Dans la méthode OnReceive de la BroadcastReceiver pour la requête ping à l'alarme, si vous n'êtes pas en appelant directement sur le support (fraie un nouveau thread ou l'intention), vous aurez besoin de tenir un signal de verrouillage jusqu'à ce que la requête ping est fini. Android est titulaire d'un signal de verrouillage seulement jusqu'à ce que OnReceive retourne, après qu'il est possible(mais rare) que le CPU peut dormir avant que le ping est fini.

  • Utiliser une Haute Performance Wifi de Verrouillage si les notifications sont sensibles.

  • Il y en avait un autre appareil à la question précise qui a touché la solution, il est couvert ici.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: