Planification des processus Android

Question

J'essaie de mieux comprendre afin de pouvoir évaluer l'impact sur la fiabilité des problèmes d'interopérabilité potentiels lors de la création d'une application/service Android. J'aimerais comprendre comment la priorité des processus est déterminée. Les différences de priorité entre les services et les activités et si le planificateur traite leur priorité différemment. En gros, j'essaie d'avoir une bonne compréhension de la probabilité qu'une activité ou un service soit affamé par un processus rebelle d'une autre application (ou même du noyau linux).

Quelqu'un a-t-il de bons liens à recommander... Mes recherches n'ont pas donné grand-chose pour l'instant.

Gracias.

Edit : Ma préoccupation concerne le découpage/planification du temps du processeur, et non les ressources mémoire (les ressources mémoire sont bien décrites dans la documentation Android). Merci encore !

Answer 1

La liste suivante présente les différents types de processus par ordre d'importance (le premier processus est le plus important et est tué en dernier) :

1. Processus de premier plan
2. Processus visible
3. Processus de service
4. Processus de base
5. Processus vide

Note : Android classe un processus au niveau le plus élevé possible, en fonction de l'importance des composants actuellement actifs dans le processus. Par exemple, si un processus héberge un service et une activité visible, le processus est classé comme un processus visible, et non comme un processus de service.

Ceci est référencé à partir d'ici Processus et fils

EDITAR:

Comprendre la priorité des applications et les états du processus

L'ordre dans lequel les processus sont tués pour récupérer les ressources est déterminé par la priorité des applications hébergées. La priorité d'une application est égale à son composant le plus prioritaire.

Lorsque deux applications ont la même priorité, le processus qui a été le plus longtemps à une priorité inférieure sera tué en premier. La priorité des processus est également affectée par les dépendances interprocessus ; si une application dépend d'un service ou d'un fournisseur de contenu fourni par une deuxième application, l'application secondaire aura une priorité au moins aussi élevée que l'application qu'elle supporte.

Toutes les applications Android resteront en cours d'exécution et en mémoire jusqu'à ce que le système ait besoin de ses ressources pour d'autres applications.

Il est important de structurer correctement votre application pour que sa priorité soit adaptée au travail qu'elle effectue. Si vous ne le faites pas, votre application pourrait être tuée alors qu'elle est en train de réaliser quelque chose d'important. La liste suivante détaille chacun des états de l'application présentés dans la figure , en expliquant comment l'état est déterminé par les composants de l'application qui le composent :

Processus actifs Les processus actifs (au premier plan) sont ceux qui hébergent des applications dont les composants interagissent actuellement avec l'utilisateur. Ce sont les processus qu'Android essaie de garder réactifs en récupérant des ressources. Ces processus sont généralement très peu nombreux et ne sont tués qu'en dernier recours.

Les processus actifs comprennent :

1. les activités dans un état "actif", c'est-à-dire qu'elles sont au premier plan et répondent aux événements de l'utilisateur. Vous explorerez plus en détail les états des activités plus loin dans ce chapitre.

2. les activités, les services ou les récepteurs de diffusion qui exécutent actuellement un gestionnaire d'événement onReceive.

3. les services qui exécutent un gestionnaire d'événement onStart, onCreate ou onDestroy.

Processus visibles Les processus visibles, mais inactifs, sont ceux qui hébergent des activités "visibles". Comme son nom l'indique, les activités visibles sont visibles, mais elles ne sont pas au premier plan et ne répondent pas aux événements de l'utilisateur. Cela se produit lorsqu'une activité n'est que partiellement masquée (par une activité non visible ou transparente). Il y a généralement très peu de processus visibles, et ils ne seront tués que dans des circonstances extrêmes pour permettre aux processus actifs de continuer.

Démarrage des processus de service Traite les services d'hébergement qui ont été lancés. Les services prennent en charge les traitements en cours qui doivent se poursuivre sans interface visible. Comme les services n'interagissent pas directement avec l'utilisateur, ils reçoivent une priorité légèrement inférieure à celle des activités visibles. Ils sont toujours considérés comme des processus d'avant-plan et ne seront pas tués, sauf si des ressources sont nécessaires aux processus actifs ou visibles.

Processus de base Les processus hébergeant des activités qui ne sont pas visibles et dont aucun service n'a été lancé sont considérés comme des processus d'arrière-plan. Il y aura généralement un grand nombre de processus d'arrière-plan qu'Android tuera en utilisant la méthode du dernier vu, premier tué, afin d'obtenir des ressources pour les processus d'avant-plan.

Processus vides Pour améliorer les performances globales du système, Android conserve souvent les applications en mémoire après qu'elles aient atteint la fin de leur durée de vie. Android maintient ce cache pour améliorer le temps de démarrage des applications lorsqu'elles sont relancées. Ces processus sont tués régulièrement si nécessaire.

Pour plus d'informations, regardez ici (j'ai trouvé sur ce blog). Gestion de la mémoire dans Android

EDITAR:

I think Android is basic Linux so, whatever scheduler works for Linux is same in Android. 

La différence entre le programmateur Android et le programmateur Linux

Planificateur - 5 fichiers - Le noyau Android contient également de légères modifications du planificateur de processus du CPU et des algorithmes de maintien du temps. Nous ne connaissons pas l'historique de ces changements, et l'impact n'était pas évident sur la base d'un examen superficiel.

Processus de préemption :

Comme mentionné, le système d'exploitation Linux est préemptif. Lorsqu'un processus entre dans l'état TASK_RUNNING, le noyau vérifie si sa priorité est supérieure à celle du processus en cours d'exécution. Si c'est le cas, l'ordonnanceur est invoqué pour choisir un nouveau processus à exécuter (vraisemblablement le processus qui vient de devenir exécutable). De plus, lorsque le timelice d'un processus atteint zéro, il est préempté et l'ordonnanceur est appelé à sélectionner un nouveau processus.

La politique d'ordonnancement en action

Considérons un système comportant deux tâches exécutables : un éditeur de texte et un encodeur vidéo. L'éditeur de texte est lié aux E/S parce qu'il passe presque tout son temps à attendre que l'utilisateur appuie sur les touches (peu importe la vitesse à laquelle l'utilisateur tape, il n'est pas si rapide). Malgré cela, lorsqu'il reçoit une pression sur une touche, l'utilisateur s'attend à ce que l'éditeur réponde immédiatement. À l'inverse, l'encodeur vidéo est lié au processeur. Outre la lecture du flux de données brutes sur le disque et l'écriture ultérieure de la vidéo résultante, l'encodeur passe tout son temps à appliquer le codec vidéo aux données brutes. Il n'a pas de contraintes temporelles fortes sur le moment où il s'exécute - s'il commençait à s'exécuter maintenant ou dans une demi-seconde, l'utilisateur ne pourrait pas le savoir. Bien sûr, plus vite il s'exécute, mieux c'est.

Dans ce système, l'ordonnanceur donne à l'éditeur de texte une priorité plus élevée et un plus grand timelice que l'encodeur vidéo, parce que l'éditeur de texte est interactif. L'éditeur de texte dispose d'un grand nombre de tranches de temps. De plus, comme l'éditeur de texte a une priorité plus élevée, il est capable de préempter l'encodeur vidéo si nécessaire. Cela garantit que l'éditeur de texte est capable de répondre immédiatement aux pressions des touches de l'utilisateur. Cela se fait au détriment de l'encodeur vidéo, mais comme l'éditeur de texte ne fonctionne que par intermittence, l'encodeur vidéo peut monopoliser le temps restant. Les performances des deux applications sont ainsi optimisées.

Answer 2

À cet égard, Android est un peu différent d'un système Linux normal. Il y a deux choses qu'Android utilise pour avoir un impact sur l'ordonnancement : le niveau "nice" des processus/threads et les cgroups.

Le niveau de "gentillesse" du processus a un impact sur la politique d'ordonnancement normal "équitable" de Linux ; les threads qui ont une gentillesse plus élevée seront exécutés moins souvent que les threads avec une gentillesse plus faible. Dans la situation où vous avez un thread à une priorité "par défaut" (telle que définie dans le fichier Process.THREAD_PRIORITY_DEFAULT ) seront exécutés beaucoup plus souvent que ceux qui ont une priorité d'arrière-plan (ou Process.THREAD_PRIORITY_BACKGROUND ).

En théorie, cela permet de s'assurer que les threads de premier plan/UI ne sont pas impactés de manière significative par le travail en arrière-plan... cependant, en pratique, ce n'est pas suffisant. Considérez le cas où vous avez 10 threads d'arrière-plan qui veulent tous s'exécuter, mais un thread d'avant-plan qui pilote l'interface utilisateur. Cela peut encore avoir un impact notable sur le comportement du thread d'avant-plan.

Pour y remédier, Android utilise également les cgroups Linux d'une manière simple pour créer un ordonnancement plus strict entre l'avant-plan et l'arrière-plan. Le cgroup de premier plan/par défaut permet la programmation des threads comme d'habitude. Le cgroup d'arrière-plan applique cependant une limite de seulement un petit pourcentage du temps total du CPU disponible pour les threads. todo threads dans ce cgroup. Ainsi, si ce pourcentage est de 5 % et que vous avez 10 threads d'arrière-plan qui veulent tous s'exécuter et un thread d'avant-plan, les 10 threads d'arrière-plan ensemble ne peuvent prendre au maximum que 5 % des cycles CPU disponibles de l'avant-plan. (Bien sûr, si aucun thread d'avant-plan ne veut s'exécuter, les threads d'arrière-plan peuvent utiliser tous les cycles CPU disponibles).

Android déplace implicitement les threads entre les cgroups par défaut et d'arrière-plan lorsque vous utilisez ses API publiques pour définir la priorité des threads. Ainsi, si vous définissez la priorité d'un thread à Process.THREAD_PRIORITY_BACKGROUND ou plus, vous placerez également le fil dans le cgroup d'arrière-plan. Réglez-le sur Process.THREAD_PRIORITY_DEFAULT et il sera dans le cgroup par défaut.

Pour cette raison, en suivant la convention normale qui consiste à placer vos threads de travail en arrière-plan dans la priorité d'arrière-plan, vous pouvez vous assurer qu'ils ne perturbent pas votre thread d'interface utilisateur d'avant-plan.

En outre, Android déplacera également tous les threads d'un processus vers le cgroup d'arrière-plan pour les processus qu'il sait ne pas être critiques pour l'utilisateur. Tout processus d'arrière-plan ou processus de service voit ses threads placés dans le cgroup d'arrière-plan, que les threads individuels aient ou non demandé une priorité d'ordonnancement au premier plan.

Answer 3

Oui, c'est possible pour que votre processus soit affamé.

Android utilise Linux 2.6 pour sa gestion de bas niveau des ressources. Il se trouve que Linux 2.6 utilise files d'attente de rétroaction à plusieurs niveaux comme algorithme d'ordonnancement. Cela favorise les processus liés aux E/S et les processus à courte durée d'utilisation du CPU (idéal pour les téléphones pour la réactivité/interaction). Cela signifie cependant que les processus intensifs en CPU et les processus à faible priorité risquent d'être affamés. Je ne suis pas sûr que Linux 2.6 augmente périodiquement la priorité des processus en attente afin qu'ils soient finalement servis, évitant ainsi la famine.

D'un point de vue réaliste, vous ne devriez pas avoir à vous en soucier puisque vous serez soit l'activité active, soit un service, qui ont tous deux des priorités relativement élevées comme le montre la réponse précédente.