Pourquoi est-il préférable pour la batterie d'un iPhone de ne PAS fermer les applications ?

Les réponses fournies sont exactes, je souhaite simplement apporter une précision du point de vue d'un développeur iOS.

iOS est conçu pour gérer autant de choses que possible afin que vous (et les développeurs) n'ayez pas à vous en soucier. Le résultat final est un quelque peu une approche cohérente pour toutes les applications, y compris celles d'Apple (même si parfois, Apple elle-même prend des raccourcis).

Ceci étant dit, la prémisse est :

• iOS en sait plus que nous sur la mémoire. Il sait combien il en a, et combien il en a besoin (jusqu'à un certain point).
• iOS a le contrôle total de la mémoire ; il a le dernier mot sur qui utilise quoi.
• Si iOS a besoin de mémoire, il la trouvera, et cela se fait généralement en tuant les autres processus qui sont restés inactifs pendant un certain temps (et il existe de nombreuses règles en coulisses, nous ne les connaissons pas toutes, et nous ne nous en préoccupons pas vraiment).
• Tout ce que fait un processeur (CPU) consomme de l'énergie. Absolument tout. N'oubliez pas que les ordinateurs ne sont que de très petits conteneurs d'électrons qui se déplacent dans de très petits espaces.
• Lorsqu'une application est tuée, il existe des protocoles convenus (contrats) qui définissent ce qui doit être fait. iOS applique et transporte ces protocoles. Mais le travail doit être fait, ce n'est pas gratuit et certainement pas toujours bon marché (cela dépend vraiment de ce qu'est l'application).

Cela dit, on peut supposer que la plupart des utilisateurs ferment des applications dans l'espoir d'augmenter l'autonomie de la batterie, en pensant qu'en fermant des applications, ils gaspillent moins d'énergie pour les maintenir en fonctionnement.

La vérité est que, sur iOS, ce n'est presque jamais le cas. Lorsque vous appuyez sur home, l'application est suspendue et n'utilise plus les ressources dont d'autres applications peuvent avoir besoin. Si une nouvelle application (ou même iOS) a besoin de cette mémoire, elle s'en chargera d'elle-même, mais seulement si elle en a besoin.

Vous fermez les applications encore et encore, et vous forcez iOS à faire ça. potentiellement coûteux La tâche de décharger réellement une application, de sauvegarder son état et ainsi de suite, avec le problème supplémentaire que lorsque vous rouvrez l'application, tous ces éléments doivent être annulés et, selon la complexité de l'application, beaucoup de choses doivent être lues depuis le stockage, jusqu'à la mémoire principale du téléphone, et ainsi de suite. Tout ce travail supplémentaire aurait pu être évité si vous aviez simplement laissé l'application dans son état "suspendu".

Cependant

Dans certains cas (et ils sont rares mais pas incroyablement rares), vous voulez tuer les applications qui se comportent mal. Les exemples sont (mais pas limités à) : Les apps qui traitent le fond sonore, ou les services asynchrones comme la localisation (où l'app demande un emplacement et iOS doit aller se renseigner sur l'endroit où il se trouve, par exemple en déclenchant le GPS si nécessaire), le streaming vidéo, etc.

J'ai eu d'innombrables exemples d'applications comme Lyft, United Airlines, et même Twitter, qui se sont retrouvées en panne (ou qui n'ont tout simplement pas fonctionné correctement), soit parce que vous êtes dans un mauvais réseau (iOS est devenu très mauvais pour récupérer de certains mauvais réseaux dans les 3-4 dernières versions), soit parce que le réseau ne répond tout simplement pas correctement.

Avec le temps, la plupart de ces problèmes tendent à disparaître et l'application recommence à fonctionner ; mais si vous avez vraiment besoin que l'application fonctionne maintenant Il faut alors payer le prix de la mort et du redémarrage à partir de zéro. Vous avez utilisé plus de batterie en faisant cela, mais, hey, vous en aviez besoin.

Et si cela vous a dérouté, je peux vous donner une analogie avec une voiture, car c'est ce que nous avons tendance à faire tout le temps.

L'analogie avec la voiture

_{<em>Je sais que la technologie automobile a évolué et que ce n'est plus un bon exemple, mais jouez avec moi ici. </em>.}

L'allumage du moteur d'une voiture consommait plus de carburant que la simple marche au ralenti. Lorsque les voitures étaient équipées de carburateurs au lieu d'injecteurs, c'était encore pire ; c'est pourquoi éteindre votre moteur lorsque vous vous arrêtez à un feu rouge peut théoriquement consommer plus de carburant que de laisser tourner le moteur au ralenti pendant une minute. Les voitures plus récentes ont un mécanisme beaucoup plus efficace et peuvent arrêter le moteur, tout en restant dans un état de semi-démarrage (ne parlons pas trop des voitures ici).

Fermer des applications, c'est l'équivalent d'une personne qui éteint sa voiture à chaque feu rouge. Au lieu de la laisser tourner au ralenti jusqu'à ce que vous en ayez à nouveau besoin, normalement quelques secondes plus tard.

L'analogie n'est pas parfaite, car la vérité est que les voitures au repos utilisent toujours du carburant, alors que les applications suspendues n'en utilisent pas. no en utilisant tout ce qui est lié à la mémoire ou à la batterie (tant qu'ils n'ont pas de traitement de fond actif, évidemment).

En fait, vous éteignez votre moteur à chaque fois que vous fermez une application, et vous ne laissez pas le mécanisme "intelligent" d'iOS qui fait tourner le moteur au ralenti s'en charger, de sorte que lorsque le feu passe au vert, il vous suffit d'appuyer sur l'accélérateur pour que le moteur démarre. plus rapide que s'il avait été arrêté à 100%. Le démarrage d'un moteur à partir d'un état arrêté consomme également plus d'énergie que le simple carburant, il faut tourner le démarreur pour que le moteur puisse être lancé, injecter du carburant et créer des étincelles, donc c'est beaucoup de travail en coulisse. Les applications sont comme les moteurs :)

1. Si vous fermez complètement une application et que vous devez la rouvrir ultérieurement, les frais généraux associés au lancement d'une nouvelle instance de l'application sont plus gourmands en ressources CPU et en énergie que le simple passage d'une application à une autre.
2. Lorsqu'une application reste en mémoire, à moins qu'elle ne soit conçue pour fonctionner en arrière-plan, elle est généralement mise en pause ou tuée et ne consomme pas de cycle CPU (en général). S'il s'agit d'une application assez simple, elle ne fera qu'occuper la mémoire. Dans ce cas, l'état de l'application est conservé ailleurs (sur le stockage de l'appareil dans le cas d'Android) afin de pouvoir être restauré ultérieurement. Pour vous donner une idée, un message non envoyé assez long que j'ai écrit dans l'application Viber de mon téléphone a survécu à un arrêt du téléphone dû à l'épuisement de la batterie. Après avoir redémarré le téléphone, puis Viber, j'ai trouvé le message qui attendait que je l'envoie. Alléluia.
3. Selon votre puce mémoire, le fait qu'elle contienne des zéros ou des uns ne fera pas de différence significative dans la consommation d'énergie. Donc, garder des choses en mémoire ou non ne vous fera pas économiser de la batterie de manière significative.
4. Lorsqu'une application est en super sommeil profond (les gars, confirmez cela s'il vous plaît), seule une référence à cette application sera visible dans le sélecteur d'applications comme un instantané du dernier écran qui était visible depuis cette application avant d'être endormie. Je dis cela parce qu'un jour, j'ai décidé de fermer toutes les applications de mon iPad, et j'ai été surpris par le nombre d'applications que j'ai dû fermer. Il y avait plus de 60 applications. Toutes ces applications ne peuvent pas être conservées dans la mémoire de l'iPad. J'y ai vu des applications qui ont été utilisées il y a plusieurs mois.

Par analogie... avec votre voiture, si vous devez faire trop d'arrêts dans la journée et que vous arrêtez et redémarrez sans cesse le moteur, il arrivera un moment où la batterie sera totalement épuisée. Cela peut se produire si le temps de charge entre les arrêts n'est pas suffisant pour restituer l'énorme quantité d'énergie qui est aspirée de la batterie chaque fois que vous démarrez le moteur. En outre, ce n'est pas bon pour le démarreur et la consommation globale d'essence. C'est pourquoi de nombreux chauffeurs de camions de livraison laissent le moteur tourner au ralenti pendant leurs courts arrêts.

Cette analogie est, selon l'OMI, similaire au mythe de l'économie de mémoire.

Je ne fais que donner une opinion différente pour le bien de la discussion. Ce concept a un certain degré de vérité, mais une fois que vous avez un certain nombre d'applications ouvertes, vous allez probablement commencer à voir des rendements décroissants sur le maintien des applications suspendues.

Plus vous avez d'applications ouvertes, plus la mémoire vive sera utilisée, évidemment. En général, la mémoire de chaque application est divisée entre la mémoire que l'application utilise actuellement, la mémoire que l'application souhaite avoir à disposition et la mémoire que le système d'exploitation a autorisé l'application à utiliser, ce qui donne la quantité finale de mémoire que l'application est autorisée à utiliser. La raison pour laquelle l'application conserve une partie distincte de cette mémoire comme mémoire qu'elle veut utiliser est que l'application peut avoir besoin d'augmenter son tas, mais elle ne veut pas nécessairement le faire tout de suite parce que c'est mauvais pour les garbage collectors d'avoir de grands tas (grands tas = garbage collectors plus longs), donc l'application mettra de côté une partie de la mémoire qui n'est pas actuellement utilisée, mais qui peut être utilisée par l'application exclusivement si nécessaire.

Disons que le système d'exploitation autorise mon application à utiliser jusqu'à 700 mb, et que l'application met de côté 300 mb de cette mémoire pour elle-même, laissant 400 mb pour que mon application puisse l'utiliser si elle le souhaite, mais qu'une autre application s'ouvre et a besoin de mémoire ; le système d'exploitation examine toutes les différentes applications et décide s'il est possible de retirer de la mémoire à une autre application et de l'utiliser pour la nouvelle application ; dans ce cas, il peut décider de retirer 150 mb de la mémoire autorisée de mon application et de la donner à la nouvelle application, ce qui nécessite un échange de mémoire pour donner de la mémoire à la nouvelle application (pensez à cela comme à une réaffectation de fonds dans une entreprise).

En ce sens, chaque application ouverte et suspendue ajoute de la complexité à ce processus, le rendant plus gourmand en ressources CPU, et nécessitant éventuellement plus d'énergie de la batterie pour ouvrir les applications futures que l'énergie de la batterie économisée en ne fermant pas les autres applications.

Mais attention, rien de tout cela ne prend en compte le fait qu'à moins que vous ne tuiez vraiment une application, il peut y avoir des services d'arrière-plan en cours d'exécution qui consomment de la puissance de traitement, par exemple des notifications programmées pour vous avertir selon une minuterie, etc. D'un autre côté, certaines applications n'utilisent pas de véritable service d'arrière-plan, et utilisent en fait les notifications push de services comme Firebase, qui ne nécessitent pas que l'application soit ouverte à tout moment.

Autre élément à prendre en compte, plus vous ouvrez d'applications, plus la mémoire sera fragmentée jusqu'à ce que le système d'exploitation la nettoie pour la rendre plus propre et plus efficace, ce qui consomme de la puissance de traitement.

Tout cela pour dire que laisser les applications ouvertes est généralement plus efficace, sauf si trop d'applications sont ouvertes, mais je ne sais pas combien d'applications doivent être ouvertes pour atteindre ce seuil, si ce nombre existe.

Sources :

Collecteur de déchets SGen pour Mono : http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

Aperçu du profileur de mémoire pour les applications Xamarin iOS et Android, qui montre la façon dont la mémoire est gérée par l'application (ensemble de travail, octets privés, mémoire allouée, etc.) https://blog.xamarin.com/say-hello-to-the-xamarin-profiler/

Version épurée : Elle est meilleure parce que le système d'exploitation a été conçu pour la rendre meilleure, au point que l'utilisateur souhaiterait garder les applications actives (ou dans un état "suspendu") afin de recueillir plus d'informations sur vos actions plus tard si nécessaire.

Version plus longue : Les applications qui sont "suspendues" auront leur état sauvegardé en mémoire, donc une fois que vous voudrez les relancer, le processus de chargement de tout sera moins long pour le processeur et n'utilisera presque pas l'unité de stockage... Avec cela, vous ne pouvez pas savoir si vos applications font d'autres choses en arrière-plan qui, dans de nombreux cas, sont là à collecter des données sur vous.

[Les applications qui sont stockées en mémoire peuvent être soit "suspendues", soit actives en arrière-plan. En tant que propriétaire de l'appareil, vous ne pouvez pas savoir (si vous ne possédez pas les connaissances et d'autres applications pour analyser activement l'utilisation du CPU) ce que fait réellement cette application. Du point de vue de la sécurité, je conseillerais de fermer toute application que vous n'allez pas utiliser pendant les 10 prochaines minutes.

P.S. Cette pratique se fait aussi bien sur les appareils Android que sur les appareils ...