Processus et cycle de vie d'une application

Dans la plupart des cas, chaque application Android s'exécute dans son propre processus Linux. Ce processus est créé pour l'application lorsqu'une partie de son code doit s'exécuter et reste en cours d'exécution jusqu'à ce que le système ait besoin de récupérer sa mémoire pour l'utiliser par d'autres applications et qu'il ne soit plus nécessaire.

Une caractéristique inhabituelle et fondamentale d'Android est que la durée de vie d'un processus d'application n'est pas contrôlée directement par l'application elle-même. Au lieu de cela, il est déterminé par le système en fonction d'une combinaison des parties de l'application que le système sait en cours d'exécution, de l'importance de ces éléments pour l'utilisateur et de la quantité de mémoire globale disponible dans le système.

Il est important que les développeurs d'applications comprennent l'impact des différents composants d'application (en particulier Activity, Service et BroadcastReceiver) sur la durée de vie du processus de l'application. Si vous n'utilisez pas correctement ces composants, le système peut interrompre le processus de l'application alors qu'il effectue une tâche importante.

Un exemple courant de bug de cycle de vie de processus est un BroadcastReceiver qui démarre un thread lorsqu'il reçoit un Intent dans sa méthode BroadcastReceiver.onReceive(), puis qui revient de la fonction. Une fois qu'il est renvoyé, le système considère que le BroadcastReceiver n'est plus actif et que son processus d'hébergement n'est plus nécessaire, sauf si d'autres composants d'application y sont actifs.

Par conséquent, le système peut arrêter le processus à tout moment pour récupérer de la mémoire. Il arrête ainsi le thread généré en cours d'exécution dans le processus. La solution à ce problème consiste généralement à planifier un JobService à partir du BroadcastReceiver afin que le système sache qu'une tâche active est en cours dans le processus.

Pour déterminer les processus à arrêter en cas de manque de mémoire, Android place chaque processus dans une hiérarchie d'importance en fonction des composants qui s'exécutent dans ces processus et de leur état. Par ordre d'importance, ces types de processus sont les suivants:

1. Un processus de premier plan est celui qui est requis pour ce que l'utilisateur fait actuellement. Différents composants d'application peuvent entraîner la considération du processus contenant comme premier plan de différentes manières. Un processus est considéré comme étant au premier plan si l'une des conditions suivantes est remplie :
   • Il exécute une Activity en haut de l'écran avec laquelle l'utilisateur interagit (sa méthode onResume() a été appelée).
   • Il dispose d'un BroadcastReceiver en cours d'exécution (sa méthode BroadcastReceiver.onReceive() est en cours d'exécution).
   • Il dispose d'un Service qui exécute actuellement du code dans l'un de ses rappels (Service.onCreate(), Service.onStart() ou Service.onDestroy()).

Il n'y a jamais que quelques processus de ce type dans le système, et ils ne sont arrêtés qu'en dernier recours si la mémoire est si faible que même ces processus ne peuvent plus continuer à s'exécuter. En règle générale, si cela se produit, l'appareil a atteint un état de pagination de mémoire. Cette action est donc nécessaire pour que l'interface utilisateur reste réactive.

2. Un processus visible effectue une tâche dont l'utilisateur est actuellement conscient. L'arrêt de ce processus a donc un impact négatif notable sur l'expérience utilisateur. Un processus est considéré comme visible dans les conditions suivantes :
   • Il exécute un Activity visible à l'écran par l'utilisateur, mais pas au premier plan (sa méthode onPause() a été appelée). Cela peut se produire, par exemple, si l'Activity au premier plan est affiché sous forme de boîte de dialogue qui permet de voir l'Activity précédent derrière elle.
   • Il dispose d'un Service exécuté en tant que service de premier plan, via Service.startForeground() (qui demande au système de traiter le service comme quelque chose que l'utilisateur connaît, ou essentiellement comme s'il était visible).
   • Il héberge un service que le système utilise pour une fonctionnalité particulière que l'utilisateur connaît, comme un fond d'écran animé ou un service de saisie.

   Le nombre de ces processus exécutés dans le système est moins limité que celui des processus de premier plan, mais reste relativement contrôlé. Ces processus sont considérés comme extrêmement importants et ne sont pas arrêtés, sauf si cela est nécessaire pour maintenir tous les processus de premier plan en cours d'exécution.

3. Un processus de service est un processus qui détient un Service démarré avec la méthode startService(). Bien que ces processus ne soient pas directement visibles par l'utilisateur, ils effectuent généralement des tâches qui l'intéressent (telles que l'importation ou le téléchargement de données réseau en arrière-plan). Par conséquent, le système maintient toujours ces processus en cours d'exécution, sauf s'il n'a pas suffisamment de mémoire pour conserver tous les processus de premier plan et visibles.

   Les services qui s'exécutent depuis longtemps (par exemple, 30 minutes ou plus) peuvent être déclassés pour que leur processus soit ajouté à la liste mise en cache.

   Les processus qui doivent être exécutés sur une longue période peuvent être créés avec setForeground. S'il s'agit d'un processus périodique qui nécessite un temps d'exécution strict, il peut être planifié via AlarmManager. Pour en savoir plus, consultez la page Compatibilité avec les nœuds de calcul de longue durée. Cela permet d'éviter les situations où des services de longue durée qui utilisent des ressources excessives, par exemple en cas de fuite de mémoire, empêchent le système de fournir une bonne expérience utilisateur.

4. Un processus mis en cache est un processus qui n'est pas actuellement nécessaire. Le système est donc libre de le fermer si nécessaire lorsque des ressources telles que la mémoire sont nécessaires ailleurs. Dans un système qui se comporte normalement, ce sont les seuls processus impliqués dans la gestion des ressources.

   Un système bien géré dispose de plusieurs processus mis en cache toujours disponibles pour un basculement efficace entre les applications et ferme régulièrement les applications mises en cache si nécessaire. Seuls les cas très critiques peuvent amener le système à supprimer tous les processus mis en cache et à commencer à supprimer les processus de service.

   Étant donné que le système peut arrêter les processus mis en cache à tout moment, les applications doivent cesser toute activité lorsqu'elles sont dans cet état. Si l'application doit effectuer une tâche critique pour l'utilisateur, elle doit utiliser l'une des API ci-dessus pour exécuter la tâche à partir d'un état de processus actif.

   Les processus mis en cache contiennent souvent une ou plusieurs instances Activity qui ne sont pas actuellement visibles par l'utilisateur (leur méthode onStop() a été appelée et a renvoyé). S'ils implémentent correctement leur cycle de vie Activity lorsque le système arrête ces processus, cela n'a aucune incidence sur l'expérience utilisateur lorsqu'il revient à cette application. Il peut restaurer l'état précédemment enregistré lorsque l'activité associée est recréée dans un nouveau processus. Sachez que l'appel de onDestroy() n'est pas garanti si un processus est arrêté par le système. Pour en savoir plus, consultez Activity.

   À partir d'Android 13, un processus d'application peut recevoir un temps d'exécution limité ou aucun jusqu'à ce qu'il passe à l'un des états de cycle de vie actifs ci-dessus.

   Les processus mis en cache sont conservés dans une liste. La règle d'ordre exacte pour cette liste est un détail d'implémentation de la plate-forme. En général, il essaie de conserver les processus les plus utiles, tels que ceux qui hébergent l'application d'accueil de l'utilisateur ou la dernière activité qu'il a vue, avant les autres types de processus. D'autres règles d'arrêt des processus peuvent également être appliquées, comme la définition de limites strictes sur le nombre de processus autorisés ou la limitation de la durée pendant laquelle un processus peut rester en cache en continu.

Pour décider de la classification d'un processus, le système se base sur le niveau le plus important parmi tous les composants actuellement actifs dans le processus. Pour en savoir plus sur la façon dont chacun de ces composants contribue au cycle de vie global d'un processus et d'une application, consultez la documentation sur Activity, Service et BroadcastReceiver.

La priorité d'un processus peut également être augmentée en fonction des autres dépendances qu'il a. Par exemple, si le processus A est lié à un Service avec l'indicateur Context.BIND_AUTO_CREATE ou utilise un ContentProvider dans le processus B, la classification du processus B est toujours au moins aussi importante que celle du processus A.