Android Process Scheduling
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. Je voudrais comprendre comment la priorité du processus est déterminée. Les différences en priorité entre les services et les activités et si l'ordonnanceur traite leur priorité différemment. Essentiellement, j'essaie de bien comprendre la probabilité qu'une activité ou un service soit affamé par des processus malveillants d'une application différente (ou même de Linux) noyau.)
Quelqu'un at-il de bons liens que vous pourriez recommander ... Mes recherches n'ont pas encore beaucoup tourné.
Merci!
Edit: Ma préoccupation concerne le découpage/la planification du temps processeur, pas les ressources mémoire (les ressources mémoire sont bien décrites dans la documentation Android.) Merci encore!
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):
- Processus de premier plan
- Processus visible
- Processus de service
- Processus d'arrière-plan
- Processus vide
Remarque: Android classe un processus au plus haut niveau possible, en fonction de l'importance des composants actuellement actifs dans Par exemple, si un processus héberge un service et une activité visible, le processus est classé en tant que processus visible et non en tant que processus de service.
Ceci est référencé à partir d'ici Processus et Threads
ÉDITER:
Comprendre la priorité des applications et les états du processus
L'ordre dans lequel les processus sont supprimé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 de priorité la plus élevée.
Lorsque deux applications ont la même priorité, le processus dont la priorité est la plus basse est interrompu en premier. La priorité des processus est également affectée par les dépendances interprocessus; si une application dépend d'un fournisseur de services ou de contenu fourni par une deuxième application, l'application secondaire aura au moins une priorité aussi élevée que l'application qu'elle prend en charge.
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 vous assurer que sa priorité est adaptée au travail qu'elle effectue. Si vous ne le faites pas, votre application pourrait être supprimée alors qu'elle se trouve au milieu de quelque chose d'important. La liste suivante détaille chacun des états d'application illustrés dans la figure, expliquant comment l'état est déterminé par les composants d'application qui le composent:
Processus actifs Les processus actifs (de premier plan) sont ceux qui hébergent des applications dont les composants interagissent actuellement avec l'utilisateur. Ce sont les processus Android essaie de rester réactif en récupérant des ressources. Il y a généralement très peu de ces processus, et ils ne seront tués qu'en dernier recours.
Les processus actifs comprennent:
1. activités dans un état "actif"; c'est-à-dire qu'ils sont au premier plan et répondent aux événements des utilisateurs. Vous explorerez les états d'activité plus en détail plus loin dans ce chapitre.
2.Activités, services ou récepteurs de diffusion qui exécutent actuellement un gestionnaire d'événements onReceive.
3.Services qui exécutent un gestionnaire d'événements 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 ni ne répondent aux événements des utilisateurs. Cela se produit lorsqu'une activité n'est que partiellement masquée (par une activité non 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.
Processus de service démarrés Processus d'hébergement des services qui ont été démarrés. Les services prennent en charge le traitement en cours qui devrait se poursuivre sans interface visible. Étant donné que les services n'interagissent pas directement avec l'utilisateur, ils reçoivent une priorité légèrement inférieure aux activités visibles. Ils sont toujours considérés comme des processus de premier plan et ne seront pas détruits à moins que des ressources ne soient nécessaires pour les processus actifs ou visibles.
Processus d'arrière-plan Les processus hébergeant des activités qui ne sont pas visibles et qui n'ont aucun service démarré 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 qui Android tuera en utilisant un modèle de dernier vu-premier-tué pour obtenir des ressources pour les processus de premier plan.
Processus vides Pour améliorer les performances globales du système, Android conserve souvent les applications en mémoire après avoir 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 régulièrement tués si nécessaire.
Pour plus d'informations, regardez ici (j'ai trouvé sur ce blog) Gestion de la mémoire dans Android
MODIFIER:
I think Android is basic Linux so, whatever scheduler works for Linux is same in Android.
La différence entre Android et planificateur Linux
Planificateur - 5 fichiers - Le noyau Android contient également de légères modifications au planificateur de processus CPU et aux algorithmes de chronométrage. Nous ne connaissons pas l'historique de ces changements, et l'impact n'était pas évident en fonction sur un examen superficiel.
Préemption de processus:
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 à la priorité du processus en cours d'exécution. Si c'est le cas, le planificateur est appelé pour choisir un nouveau processus à exécuter (probablement le processus qui vient de devenir exécutable). De plus, lorsque la tranche de temps d'un processus atteint zéro, elle est préemptée et le planificateur est appelé pour sélectionner un nouveau processus.
La politique de planification en action
Prenons un système avec deux tâches exécutables: un éditeur de texte et un encodeur vidéo. L'éditeur de texte est lié aux E/S car il passe presque tout son temps à attendre que l'utilisateur appuie sur les touches (quelle que soit la vitesse à laquelle l'utilisateur tape, ce n'est pas si rapide). Malgré cela, lorsqu'il reçoit une pression sur une touche, l'utilisateur attend de l'éditeur qu'il réponde immédiatement. Inversement, l'encodeur vidéo est lié au processeur. Outre la lecture du flux de données brutes à partir du 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 de temps importantes sur son exécution - s'il a commencé à s'exécuter maintenant ou en une demi-seconde, l'utilisateur ne pourrait pas le savoir. Bien sûr, plus tôt il se termine, mieux c'est.
Dans ce système, le planificateur donne à l'éditeur de texte une priorité plus élevée et une tranche de temps plus grande que l'encodeur vidéo, car l'éditeur de texte est interactif. L'éditeur de texte dispose de nombreuses 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 en cas de besoin. Cela garantit que l'éditeur de texte est capable de répondre immédiatement aux pressions des touches de l'utilisateur. 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 optimise les performances des deux applications.
Android à cet égard est un peu différent d'un système Linux normal. Il y a deux choses Android utilise pour influencer la planification: processus/thread "Nice" level et cgroups.
Le niveau "Nice" du processus a un impact sur la politique d'ordonnancement "équitable" normale de Linux; les threads ayant une plus grande gentillesse seront exécutés moins souvent que les threads avec une gentillesse plus faible. Dans le cas où vous avez un thread avec une priorité "par défaut" (comme défini dans Process.THREAD_PRIORITY_DEFAULT ) s'exécutera beaucoup plus souvent que ceux ayant une priorité en arrière-plan (ou Process.THREAD_PRIORITY_BACKGROUND ).
En théorie, cela peut garantir que les threads de premier plan/d'interface utilisateur ne sont pas affectés de manière significative par le travail en arrière-plan ... cependant, dans la pratique, ce n'est pas suffisant. Considérez si vous avez 10 threads d'arrière-plan qui veulent tous s'exécuter, mais un thread de premier plan pilotant l'interface utilisateur. Cela peut toujours entraîner un impact notable sur le comportement du thread de premier plan.
Pour résoudre ce problème, Android utilise également les cgroups Linux de manière simple pour créer une planification d'avant-plan et d'arrière-plan plus stricte. Le cgroup d'avant-plan/par défaut permet la planification des threads normalement. Le cgroup d'arrière-plan applique cependant une limite de seulement un petit pourcentage du temps CPU total étant disponible pour tous les threads de ce groupe de contrôle. Ainsi, si ce pourcentage est de 5% et que vous avez 10 threads d'arrière-plan tous voulant s'exécuter et un thread de premier plan, les 10 threads d'arrière-plan ne peuvent prendre au maximum que 5% des cycles de processeur disponibles du premier plan (bien sûr, si aucun thread de premier plan ne veut s'exécuter, les threads d'arrière-plan peuvent utiliser tous les Cycles CPU.)
Android déplace implicitement les threads entre les groupes de contrôle 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 sur Process.THREAD_PRIORITY_BACKGROUND ou supérieur, vous placerez également le fil dans le groupe de contrôle d'arrière-plan. Réglez-le sur Process.THREAD_PRIORITY_DEFAULT et il sera dans le groupe de contrôle par défaut.
Pour cette raison, en suivant la convention normale de placer vos threads de travail d'arrière-plan dans la priorité d'arrière-plan, vous pouvez vous assurer qu'ils ne perturbent pas votre thread d'interface utilisateur de premier plan.
De plus, Android déplacera également tous les threads d'un processus vers le groupe de contrôle en arrière-plan pour les processus dont il sait qu'ils ne sont pas critiques pour l'utilisateur. Tout processus en arrière-plan ou processus de service a ses threads placés en arrière-plan. cgroup, que les threads individuels aient ou non demandé une priorité de planification au premier plan.
Oui, il est possible que votre processus soit affamé.
Android utilise Linux 2.6 pour sa gestion de bas niveau des ressources. Linux 2.6 arrive à utiliser files d'attente de rétroaction à plusieurs niveaux comme algorithme de planification. Cela favorise les processus liés aux E/S et les processus de rafale de processeur courts (idéal pour les téléphones pour la réactivité/l'interaction). Cela signifie cependant que les processus gourmands en ressources processeur et les processus de faible priorité risquent de mourir de faim. Je ne sais pas si Linux 2.6 augmente périodiquement la priorité des processus en attente afin qu'ils finissent par être servis, évitant ainsi la famine.
En réalité, cependant, vous ne devriez pas avoir à vous en préoccuper car 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.