Je pense que la raison pour laquelle vous avez du mal à trouver une réponse définitive est que le concept d'application "en cours d'exécution" n'est pas le même que celui auquel on s'attend. Un utilisateur non technicien peut avoir une idée de ce que signifie "fonctionner", un programmeur PC "à l'ancienne" peut avoir une idée différente - et puis il y a ce qui se passe réellement sur iOS, dont seuls Apple et les développeurs d'applications ont à s'occuper.
Sur un PC traditionnel, vous trouverez un programme exécutable sur le disque que vous démarrez - et maintenant le programme est "en cours d'exécution". Ce terme signifie que le programme s'attend à ce que son fil d'exécution principal soit périodiquement programmé pour s'exécuter sur l'unité centrale - ce qui signifie que son propre code de programme s'exécutera sur l'unité centrale réelle et qu'il aura un certain pouvoir sur ce qui se passe réellement.
Sur un PC traditionnel, vous pourriez avoir une telle application en cours d'exécution avec une interface utilisateur graphique dans une fenêtre. Que cette fenêtre soit au premier plan, à l'arrière-plan ou même minimisée (c'est-à-dire non visible du tout), le code de programmation est toujours programmé périodiquement 1 pour fonctionner sur l'unité centrale. L'application est pour ainsi dire libre de faire ce qu'elle veut. L'application peut avoir une priorité moindre en arrière-plan et ne pas être programmée aussi fréquemment ou aussi longtemps que lorsqu'elle est au premier plan, mais c'est fondamentalement la même chose.
Toujours sur un PC traditionnel, vous pouvez mettre l'ensemble du PC en mode veille. Il existe de nombreux types d'états de veille ayant des impacts différents sur le système :
Pour les états de veille S1, S2 et S3, l'application conserve son état dans la mémoire vive, mais son code de programme n'est pas programmé pour s'exécuter périodiquement sur l'unité centrale pendant la veille. C'est en fait tout ce qui se passe réellement dans le contexte de l'application 2 bien que, dans le contexte du système d'exploitation, beaucoup de choses doivent se produire lors du réveil (les pilotes doivent réinitialiser les périphériques, etc.).
Pour l'état de veille S4, l'état de l'application est sauvegardé sur le disque - bien que cela se fasse de manière transparente pour l'application. Il n'est plus prévu qu'elle s'exécute sur le processeur (évidemment). Lorsque le PC est réveillé, l'état est restauré dans la mémoire et l'application peut à nouveau s'exécuter en programmant son code de programme pour qu'il s'exécute à nouveau sur l'unité centrale.
En ce qui concerne l'état d'alimentation du S5, le système est essentiellement arrêté et mis hors tension. Dans ce cas, aucun état de l'application n'est sauvegardé automatiquement sur le disque par le système d'exploitation. L'application doit elle-même disposer d'un état sauvegardé afin de reprendre là où elle s'est arrêtée lorsque le système est remis sous tension. Sur de nombreux systèmes d'exploitation, vous constaterez qu'il est courant que les applications ne fassent pas cela - ou du moins qu'elles ne le fassent pas de manière transparente. Par exemple, si vous éteignez votre système alors que votre jeu préféré est en cours d'exécution, vous ne pouvez pas vous attendre à ce que le jeu soit toujours en cours d'exécution et au même endroit lorsque vous rallumerez le système.
J'en viens maintenant aux applications sur iOS. À l'instar des états de puissance Sx dont nous avons parlé précédemment (qui concernent l'ensemble du système), une application sur iOS passera également par différents états au cours de sa vie. Plus précisément, les applications sont en fait constituées de scènes 2 qui peut se trouver dans l'un des états suivants :
- Non inscrit
- Avant-plan et inactif
- Premier plan et actif
- Contexte
- Suspendu
La question de savoir si vous considérez que l'application "fonctionne" dans l'un ou l'autre de ces états dépend vraiment de votre point de vue. Par exemple, un utilisateur non technique peut avoir une vision différente de celle d'un développeur d'applications.
Si nous prenons l'exemple d'une application que vous lancez pour la première fois, voici ce qui se passe :
Lorsque vous appuyez sur une icône de l'écran d'accueil pour "lancer" votre application, une scène spécifique de l'application passe d'abord à l'état "détaché". Cela signifie que des parties du code exécutable de l'application sont chargées dans la mémoire vive, qu'une boucle d'événements est mise en place et qu'une fonctionnalité spécifique et limitée du code du programme est déclenchée. Lors de la première exécution, ce code particulier ne fera pratiquement rien lui-même (c'est-à-dire qu'il déclenchera du code UIKit dans les cadres du système, par exemple, mais pas beaucoup de code spécifique à l'application). Rien n'est visible à l'écran pour l'utilisateur.
Peu après, la scène passe à l'état "Avant-plan et inactif". L'application exécute alors son propre code pour configurer les éléments de l'interface utilisateur, démarrer les minuteries, acquérir les ressources partagées, etc. - mais rien n'est encore affiché à l'écran et aucune entrée utilisateur n'est donnée au programme.
Peu après, la scène passe à l'état "Avant-plan et actif". Les éléments de l'interface utilisateur sont désormais visibles sur l'écran et les entrées de l'utilisateur (telles que les touches) sont envoyées à la boucle d'événements de l'application. L'exécution du code de l'application est programmée périodiquement.
Quelque temps plus tard, iOS peut faire repasser la scène à l'état "Avant-plan et inactif". Par exemple, si l'utilisateur décide de changer d'application. Là encore, les événements d'entrée de l'utilisateur ne sont pas envoyés à l'application, mais le code de l'application est périodiquement programmé afin de mettre en pause les opérations de travail - comme par exemple l'enregistrement des données de l'utilisateur dans le stockage permanent, l'arrêt des minuteries, la mise en pause des threads qui vident les files d'attente des tâches, l'arrêt de la mise à jour des animations, etc.
Si la scène n'est devenue "Avant-plan et inactive" que temporairement en raison, par exemple, d'une fenêtre contextuelle du système (comme un message indiquant qu'il reste 10 % de batterie), elle peut rapidement redevenir "Avant-plan et active". Toutefois, si l'utilisateur a basculé vers une autre application, la scène passera à l'état "arrière-plan".
Lors du passage à l'état "Arrière-plan", l'exécution du code de l'application n'est programmée que pour une durée très limitée (généralement 5 secondes, mais une application peut demander une extension). À ce stade, l'application est censée libérer tous les objets de données volumineux en mémoire (tels que les images et les fichiers audio chargés précédemment à partir du stockage), ainsi que toutes les ressources partagées (telles que l'appareil photo, le carnet d'adresses ou de nombreux autres types de ressources partagées). Il est également censé nettoyer son interface utilisateur pour la "désencombrer" et supprimer toute information sensible 3 . Au bout d'un certain temps, iOS cesse de planifier l'exécution du code de l'application et effectue une "capture d'écran" (rappelez-vous que l'interface utilisateur n'est pas affichée à l'écran et qu'il s'agit donc d'une copie bitmap de ce qui aurait été affiché à l'écran, s'il avait été affiché à l'écran). Cette capture d'écran est maintenant ce qui sera présenté à l'utilisateur comme l'"application en cours" dans le sélecteur d'applications, par exemple. Les éléments de l'interface utilisateur peuvent avoir été supprimés de la mémoire, mais la capture d'écran restera la même.
Il est important de noter que les applications peuvent indiquer à iOS qu'elles prennent en charge des cas d'utilisation spécifiques qui leur permettront de bénéficier de la planification de l'exécution de leur code, même lorsqu'elles se trouvent en "arrière-plan". L'application ne décide pas elle-même du moment où son code est exécuté - c'est iOS qui en décide en fonction des cas d'utilisation pour lesquels l'application s'est enregistrée. Par exemple, il peut s'agir d'une application de courrier électronique qui a demandé à être autorisée à vérifier l'arrivée de nouveaux courriers en utilisant une approche temporelle. Il peut s'agir d'une application qui a demandé un délai d'exécution lorsque l'emplacement géographique de l'utilisateur change dans une certaine mesure. Il existe plusieurs autres cas d'utilisation, comme par exemple un destinataire de notifications push, des applications qui diffusent de l'audio que l'utilisateur souhaite continuer à jouer lorsque l'application est en arrière-plan, etc.
En arrière-plan, une partie du code du programme se trouve généralement encore dans la mémoire vive, mais la plupart de ses ressources les plus importantes n'y sont pas. L'application peut exécuter certaines fonctions limitées, mais elles sont contrôlées par iOS, et non par elle-même. L'interface utilisateur est essentiellement une capture d'écran.
Plus tard, la scène peut être suspendue à la discrétion d'iOS. Cela signifie que l'application a le temps d'exécuter le code qui permettra de préserver son état dans un stockage permanent afin de pouvoir restaurer l'application dans le même état plus tard. Cela permet de donner l'illusion que l'application est toujours en cours d'exécution. Pour les applications utilisant les outils d'Apple, cela peut être fait plus ou moins automatiquement par le système sans que le développeur de l'application n'ait à faire grand-chose. Pour certaines applications, cependant, le développeur doit faire beaucoup de travail pour être en mesure de maintenir correctement l'état de l'application.
Désormais, lorsque l'application est "suspendue", iOS est libre de la supprimer complètement de la mémoire vive. Pour l'utilisateur, il ne se passe visiblement que très peu de choses, voire rien du tout, lorsque l'application est suspendue. Le plus important est qu'iOS conserve l'état sauvegardé - il est préservé même en cas de redémarrage du téléphone. Il est supprimé lorsque l'utilisateur utilise le sélecteur d'applications pour forcer la sortie de l'application, et si l'application se bloque au lancement (ce qui indique un bogue dans l'application - ceci est fait pour éviter que l'application ne se bloque à chaque lancement).
Lorsque l'utilisateur revient à une application en état de "suspension", la scène entre à nouveau en état de non-attachement. La différence avec le "nouveau départ" est que cette fois, l'application reçoit également son état préservé. L'application peut maintenant utiliser ces données pour configurer les éléments de l'interface utilisateur, l'état interne, etc. afin que l'application apparaisse à l'utilisateur exactement comme elle l'était avant d'être suspendue.
Certains développeurs n'utilisent que les outils d'Apple dans un domaine où cela se fait sans effort ou ils sont habiles à mettre en œuvre cette restauration pour eux-mêmes. Ainsi, l'utilisateur ne peut pas faire la différence entre une application qui passe de l'état d'arrière-plan à l'état de premier plan et une application qui passe de l'état de suspension à l'état de premier plan.
Cependant, certains développeurs n'offrent pas cette restauration sans faille. Dans le cas le plus simple (c'est-à-dire s'ils ne font rien), l'application va essentiellement "redémarrer" et donner l'impression d'avoir été quittée de force et redémarrée.
Cela explique en partie pourquoi certaines applications semblent "fonctionner en permanence" et d'autres "s'arrêter" et "redémarrer". Cela ne signifie pas nécessairement qu'iOS a "décidé de quitter" cette application plus que d'autres, mais plutôt que l'application elle-même n'a pas été conçue avec le même soin ou que, pour d'autres raisons, elle n'a pas été en mesure de préserver et de restaurer son état.
Notez qu'iOS peut suspendre des applications pour diverses raisons autres que le redémarrage de votre téléphone. Par exemple, une application peut être mise en arrière-plan et suspendue afin de libérer de la mémoire ou d'autres ressources qui seront utilisées par d'autres programmes. Elles peuvent également être remises en service lorsque les ressources sont moins rares.
En fait, les applications peuvent être mises en arrière-plan et suspendues sans que l'utilisateur non technique ne s'en aperçoive. L'application conserve le même aspect dans le sélecteur d'applications et l'utilisateur peut reprendre l'utilisation de l'application sans qu'il y ait nécessairement de différence entre une application suspendue et une application non suspendue. Notez qu'il faut souvent un peu plus de temps pour faire apparaître une application suspendue qu'une application non suspendue.
En résumé, la définition du moment où un programme est "en cours d'exécution" est contextuelle et peut être assez complexe. L'utilisateur moyen considérerait-il qu'un programme PC dont la fenêtre est réduite est "en cours d'exécution" ? - Si ce PC passe temporairement en état de veille S1, le programme est-il toujours "en cours d'exécution" ? Vous pourriez dire que non, mais pourriez-vous dire que le programme a "quitté" ?
De même, une application iOS pourrait probablement être considérée comme étant en cours d'exécution par un utilisateur non technicien dans l'un ou l'autre des états mentionnés, tant que son état est préservé. L'utilisateur peut passer à l'application et celle-ci réagira et se présentera comme prévu - elle ne "redémarre" pas (comme si elle repartait de zéro). Il est évident que certains pourraient considérer que l'application ne fonctionne pas lorsque le téléphone est éteint... mais du point de vue de l'application elle-même, elle ne "sait" pas si le téléphone a été éteint ou non.
UPDATE :
Les commentaires m'ont appris que le problème pratique derrière cette question est l'application MediSafe et son incapacité à alerter correctement l'utilisateur dans certains cas - et je voudrais savoir si c'est une lacune d'iOS ou de l'application elle-même.
L'application MediSafe est censée émettre une alerte à des heures précises (ou le plus tôt possible après) pour rappeler à l'utilisateur de prendre ses médicaments. Pour que cela fonctionne dans tous les cas, même si le téléphone vient de redémarrer, si l'application n'est pas en cours d'exécution, si l'application est en arrière-plan - ou quoi que ce soit d'autre - le développeur doit utiliser l'API Notifications de l'utilisateur et plus particulièrement l'API UNNotificationRequest() fonction.
Cette API n'a rien à voir avec les "modes d'arrière-plan" mentionnés.
1 : Notez que le programme peut avoir demandé au système d'exploitation de ne pas le programmer à nouveau à moins qu'un événement ne se produise.
2 : Je parle ici d'iOS 13 et des versions plus récentes - c'est légèrement différent sur iOS 12 et les versions plus anciennes, où cela n'est pas géré par scène, mais plutôt par UIApplication.
3 : Cela explique pourquoi certaines applications apparaissent dans le sélecteur d'applications comme étant "vides" ou d'une "couleur unie" uniquement. Certaines applications modifient volontairement leur interface utilisateur juste avant la capture d'écran afin de protéger les informations sensibles des regards indiscrets. Cela ne signifie pas que l'application est "effacée de la mémoire" ou qu'elle est "moins active" (si cela a un sens) que d'autres applications.
]
