Ordonnancement Des Processus Android

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 d'arrière-plan
5. processus Vide

Remarque: Android classe un processus au plus haut niveau possible, basé sur 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 un processus de service.

C'est référencé à partir d'ici les Processus et les Threads

EDIT:

comprendre la priorité de la demande et les États du processus

L'ordre dans lequel les processus sont tués pour récupérer des ressources est déterminée par la priorité des applications hébergées. Une application la priorité est égale à sa composante la 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é du processus est également affectée par les dépendances entre processus; si une application dépend d'un service ou D'un fournisseur de contenu fourni par une seconde application, l'application secondaire aura au moins une priorité aussi élevée que l'application qu'elle supporte.

toutes les applications Android restera 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 votre application correctement pour s'assurer que sa priorité est appropriée pour le travail qu'elle fait. Si vous ne le faites pas, votre demande pourrait être tuée alors qu'elle est au milieu de quelque chose d'important. La liste suivante détaille chacun des états de la demande représentés dans la Figure, en expliquant comment l'état est déterminé par les composantes de la demande comprenant c':

Processus Actifs les processus actifs (de premier plan) sont ceux qui hébergent des applications dont les composantes interagissent actuellement avec l'utilisateur. Ce sont les processus Android essaie de garder responsive en réclamant des ressources. Il y a généralement très peu de ces processus, et ils seront tués seulement comme un dernier recours.

les processus actifs comprennent:

1.Activités dans un "actif" l'état; c'est-à-dire qu'ils sont au premier plan et répondent aux événements des utilisateurs. Vous examinerez plus en détail les états des activités plus loin dans ce chapitre.

2.Activités, Services ou récepteurs de radiodiffusion qui exécutent actuellement un gestionnaire d'événements onReceive.

3.Les Services qui exécutent un gestionnaire d'événements onStart, onCreate ou onDestroy.

Processus Visibles processus visibles, mais inactifs sont ceux qui hébergent des activités "visibles". Comme le nom suggère, les activités visibles sont visibles, mais ils ne sont pas au premier plan ou répondre aux événements de l'utilisateur. Cela se produit lorsqu'une activité n'est que partiellement masquée (par une activité non en plein écran 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.

Commencé Le Processus De Service traite les services d'hébergement qui ont commencé. Soutien des Services en cours traitement qui devrait se poursuivre sans interface visible. Parce que les Services n'interagissent pas directement avec l'utilisateur, ils reçoivent une priorité légèrement inférieure que les activités visibles. Ils sont toujours considérés comme des processus de premier plan et ne seront pas éliminés à moins que des ressources soient nécessaires pour les processus actifs ou visibles.

Processus D'Arrière-Plan les processus qui hébergent des activités qui ne sont pas visibles et qui n'ont pas de Services qui ont été lancés sont considérés processus d'arrière-plan. Il y aura généralement un grand nombre de processus de fond que Android tuera à l'aide d'un pat-tern-last-seen - first-killed pour obtenir des ressources pour les processus de premier plan.

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

pour plus d'info regardez ici (j'ai trouvé sur ce blog) gestion de la mémoire sous Android

EDIT:

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

la différence entre Android scheduler et Linux scheduler

Scheduler-5 fichiers - le noyau Android contient également de légères modifications aux algorithmes de scheduler et de time-keeping du processus CPU. Nous ne connaissons pas l'histoire de ces changements, et la l'impact n'était pas évident à la suite d'un examen superficiel.

Préemption Du Procédé:

comme mentionné, le système D'exploitation Linux est préventif. 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 (probablement le processus qui vient de devenir exécutable). De plus, lorsque le délai d'un processus atteint zéro, il est préempté, et l'ordonnanceur est invoqué pour sélectionner un nouveau processus.

La Politique de Planification dans l'Action

Envisager un système avec deux tâches exécutables: un éditeur de texte et un encodeur vidéo. L'éditeur de texte est I / O-bound parce qu'il passe presque tout son temps à attendre les presses de touches d'utilisateur (peu importe la vitesse des types d'utilisateur, il n'est pas si rapide). Malgré cela, lorsqu'il reçoit une touche pressée, l'utilisateur s'attend à ce que l'éditeur réponde immédiatement. À l'inverse, l'encodeur vidéo est lié au processeur. En plus de lire le flux de données brutes à partir du disque et d'écrire plus tard 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 fortes contraintes de temps quand il fonctionne-s'il a commencé à courir, maintenant ou à une demi-seconde, l'utilisateur ne pouvait pas dire. Bien sûr, le plus tôt il termine le mieux.

Dans ce système, le planificateur donne l'éditeur de texte une priorité plus élevée et plus timeslice que l'encodeur vidéo, parce que l'éditeur de texte est interactif. L'éditeur de texte a beaucoup de timeslice disponibles. En outre, parce que l'éditeur de texte a une priorité plus élevée, il est capable de préempter l'encodeur vidéo lorsque nécessaire. Cela garantit l'éditeur de texte est capable de répondre à l'utilisateur appuie sur touche immédiatement. C'est au détriment de l'encodeur vidéo, mais parce que l'éditeur de texte ne fonctionne que par intermittence, l'encodeur vidéo peut monopoliser le temps restant. Cela permet d'optimiser la performance des deux applications.

Android à cet égard est un peu différent d'un système Linux normal. Il y a deux choses que Android utilise pour affecter la planification: processus/thread "nice" niveau et cgroups.

le niveau "nice" du processus a un impact sur la Politique de planification "juste" normale de Linux; les threads qui ont une plus grande niceness seront moins souvent lancés que les threads avec une plus faible niceness. Dans la situation où vous avez un thread à une priorité "par défaut" (comme défini dans Process.THREAD_PRIORITY_DEFAULT) pour fonctionner beaucoup plus souvent que ceux qui ont une priorité de fond (ou Process.THREAD_PRIORITY_BACKGROUND).

en théorie, cela permet de s'assurer que les threads de premier plan/UI ne sont pas affectés de manière significative par le travail de fond... cependant, dans la pratique, il n'est pas suffisant. Considérez si vous avez 10 threads d'arrière-plan qui veulent tous courir, mais un thread d'avant-plan qui dirige L'interface utilisateur. Cela peut encore avoir un impact notable sur le comportement du thread de premier plan.

Pour résoudre ce problème, Android utilise également Linux gcroups d'une manière simple pour créer un avant-plan plus strict vs. La programmation d'arrière-plan. Le premier plan/groupe cgroup par défaut permet l'ordonnancement du thread comme d'habitude. Le groupe de base applique cependant une limite de seulement quelques petits pour cent du temps CPU total étant disponible pour les threads qui cgroup. Ainsi, si ce pourcentage est de 5% et que vous avez 10 threads d'arrière-plan que tous veulent exécuter et un thread d'avant-plan, les 10 threads d'arrière-plan ensemble ne peuvent prendre qu'au maximum 5% des cycles CPU disponibles à partir du premier plan. (Bien sûr, si aucun thread avant-plan ne veut s'exécuter, les threads arrière-plan peuvent utiliser tous les cycles CPU disponibles.)

Android déplace implicitement les threads entre les cgroups par défaut et en arrière-plan lorsque vous utilisez ses API publiques pour définir la priorité du thread. Ainsi, si vous définissez la priorité d'un thread à Process.THREAD_PRIORITY_BACKGROUND ou plus, vous mettrez aussi le thread dans le gcroup arrière-plan. Set Process.THREAD_PRIORITY_DEFAULT et il sera par défaut dans le cgroup.

pour cette raison, en suivant la convention normale de mettre vos threads de travailleur d'arrière-plan dans la priorité d'arrière-plan, vous pouvez vous assurer qu'ils ne perturbent pas votre thread D'UI d'avant-plan.

en outre, Android déplacera également tous les threads dans un processus à l'arrière-plan ggroup pour les processus qu'il sait ne sont pas critiques pour l'utilisateur. Tout processus d'arrière-plan ou de service a ses fils mis dans le groupe d'arrière-plan, peu importe si des threads individuels ont demandé une priorité de programmation de premier plan.

Oui, c'est possible pour votre processus de faim.

Android utilise Linux 2.6 pour sa faible gestion des ressources. Linux 2.6 arrive à utiliser multi-niveau de la rétroaction des files d'attente comme son algorithme d'ordonnancement. Cela favorise les processus liés à l'E/S et les processus courts de rupture de CPU (idéal pour les téléphones pour la réactivité/interaction). Cela signifie toutefois que les processus intensifs en CPU et les processus de faible priorité risquent de mourir de faim. Je ne suis pas bien sûr, si Linux 2.6 augmente périodiquement la priorité des processus d'attente afin qu'ils soient éventuellement servis évitant ainsi la famine.

de façon réaliste cependant, vous ne devriez pas avoir à vous inquiéter de cela puisque vous serez soit l'activité active ou vous serez un service, qui ont tous deux des priorités relativement élevées comme la réponse précédente montre.