Quelle est la consommation de batterie causée par les notifications push sous Android 4.1 ?

Les notifications push sont conçues pour être la solution aux applications consommatrices de batterie qui surveillent constamment les données qui ont changé localement ou sur un serveur. De ce fait, elles sont très économes en batterie. Mon téléphone reçoit généralement 20 notifications en quelques heures, avec une consommation totale de la batterie inférieure à 1 %.

Si vous avez de gros problèmes de batterie, votre téléphone ne dort probablement pas correctement, ce qui est généralement dû à une application qui empêche le téléphone de dormir. Je pourrais peut-être vous aider à résoudre ce problème avec quelques informations supplémentaires, comme le téléphone, la version d'Android (ou la ROM si vous êtes enraciné) et une capture d'écran de votre batterie après que votre téléphone ait fonctionné pendant quelques heures. Je mettrai à jour ma réponse en conséquence.

Je veux savoir si la version 4.1 est configurée pour utiliser efficacement les notifications push en ce qui concerne la consommation de la batterie.

En bref, la réponse est oui, mais cette question semble mal posée. Les notifications push existent depuis bien plus longtemps que la version 4.1 et, à ma connaissance, aucune "efficacité" majeure n'a été ajoutée au système d'exploitation Android après la version 4.1 pour améliorer la gestion des notifications push.

Pour que les notifications push fonctionnent, vous avez besoin de 4 composants :

(1) Un serveur d'application qui traite des données pour vous dans le nuage et qui souhaite vous informer d'un événement (par exemple, les serveurs Twitter/Facebook).

(2) Un serveur de notification Push qui peut recevoir des demandes de la part de (1) pour déterminer à qui il est destiné et envoyer un message à la bonne combinaison utilisateur/appareil (ex : serveur Google Cloud Messaging).

(3) Une application/service Android équivalente qui fonctionne en permanence en arrière-plan et dispose d'une connexion persistante (toujours active) à l'application Android. (2) Ainsi, il peut recevoir le push, déterminer à quelle application il est destiné, réveiller cette application et lui envoyer les petites données du push (ex : application native du Google Play Store).

(4) Une application Android qui peut recevoir ces données locales à partir de (3) et déterminer la meilleure façon d'informer l'utilisateur de cette notification push (généralement en affichant un indicateur de notification dans la barre d'état) (ex : application Twitter Android). C'est ce que l'utilisateur final considère comme une notification push. Cependant, toutes les notifications push n'ont pas besoin de s'afficher dans la barre d'état/de notification, elles sont envoyées silencieusement par les services suivants (3) et c'est à (4) pour déterminer si une notification doit être montrée à l'utilisateur

Idéalement, même avec le paramètre de notifications push activé, (4) n'est pas réveillé. Il sera réveillé par (3) quand (3) reçoit le coup de pouce de (2) . Google fournit le cadre GCM qui permet (2) y (3) . Ainsi, si vos applications utilisent la GCM (ou d'autres services équivalents comme UrbanAirship, Xtify, etc.), toute décharge excessive de la batterie que vous pourriez constater est la faute de (1) ou (4), qui sont tous deux la faute du développeur de l'application.

(1) et (2) peuvent être combinés, tout comme (3) et (4). Ainsi, si les applications que vous installez disposent de leur propre service de poussée, il s'agit toujours d'un problème lié à leur code, et non à votre appareil ou au système d'exploitation.

Lecture supplémentaire : Architecture de messagerie de Google Cloud