Règles de connexion à la socket Android persistantes
j'ai fait quelques tests pour une solution de notification push personnalisée pour les appareils Android utilisant des sockets persistants. J'aimerais partager mes constatations et valider les résultats.
Simple Description
Les applications exécutent un service de premier plan et établit une connexion avec le serveur et maintient cette connexion par l'intermédiaire de pinging agressif (@ 10 Secondes d'intervalle). Si la connexion est détectée comme morte, l'application essaie de se reconnecter indéfiniment. Le serveur envoie des notifications via un canal duplex.
essai 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%
essai 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%
suppositions: un paquet réseau entrant réveille automatiquement le CPU, donc pas besoin de verrouillage de sillage. Utiliser AlarmManager to ping (au lieu de minuteries) signifie que nous n'avons pas besoin d'un wakelock.
enlever ce wakelock semblait vraiment aider la batterie. Étonnamment, les pings agressifs sur l'une ou l'autre solution n'ont pas affecté la durée de vie de la batterie autant que je l'aurais pensé. (Nous avons eu beaucoup d'autres tests, y compris un où l'application juste tenu un wifilock et n'a rien qui a causé environ 4% à 5% de perte de la batterie au cours de la même période)
puisque l'application a été en mesure d'envoyer avec succès toutes les demandes ping et de recevoir toutes les mes messages, je crois que mes suppositions sont correctes. Mais j'aimerais avoir la confirmation de n'importe quel expert.
une autre question: Si l'application devait plutôt écouter les connexions entrantes. J'aurais besoin de tenir un wakelock dans ce cas, correct? Une connexion entrante ne réveille pas le CPU? Nous n'allons pas suivre cette voie, mais je voulais juste confirmer.
aussi, s'il vous plaît ne pas recommander GCM, il a été exclu par la politique de l'entreprise.
Merci.
1 réponses
Puisqu'il y a eu un certain intérêt pour cette question et aucune confirmation, je vais juste répondre maintenant. Cela fait longtemps que les tests n'ont pas été effectués, et une solution au niveau de la production a été créée et rigoureusement testée. Le fait d'enlever le verrou de sillage a quand même aidé la batterie et aucun autre problème n'a été trouvé, comme des demandes de ping manquantes ou des notifications entrantes, de sorte que c'est la seule validation que j'ai reçue sur ces hypothèses.
Autres Choses à noter:
-
dans la méthode de réception de L'émetteur radio pour l'alarme de ping, si vous n'appelez pas directement sur la socket (frayant un nouveau thread ou intention), vous aurez besoin de tenir une serrure de sillage jusqu'à ce que la demande de ping est terminée. Android tient un verrou de veille seulement jusqu'à ce Qu'OnReceive revienne, après cela il est possible(mais rare) que le CPU peut dormir avant que le ping soit terminé.
-
Utilisation un High Performance Wifi Lock si les notifications sont sensibles.
-
il y avait un autre problème spécifique à l'appareil qui a affecté la solution, il est couvert ici .
mise à Jour
est tombé dans la question suivante avec Android 5.1 : Android Issue
Update 2
besoin de coder autour du mode Doze pour Android 6.0 : Mode Doze