creez-des-applications-pour-android

5.1 Le travail en arrière-plan
Ici, j’ai un receiver qui va s’enclencher dès que la batterie devient faible. Configuré de cette manière,
mon receiver ne pourra démarrer que si l’application est lancée (comme j’ai rajouté « : »,
seule mon application pourra le lancer) ; cependant, si l’utilisateur ferme l’application alors que
le receiver est en route, le receiver ne s’éteindra pas puisqu’il se trouvera dans un autre processus
que le restant des composants.
Quand le système doit décider quel processus il doit tuer, pour libérer de la mémoire principalement,
il mesure quelle est l’importance relative de chaque processus pour l’utilisateur. Par
exemple, il sera plus enclin à fermer un processus qui ne contient aucune activité visible pour
l’utilisateur, alors que d’autres ont des composants qui fonctionnent encore — une activité visible
ou un receiver qui gère un évènement. On dit qu’une activité visible a une plus grande priorité
qu’une activité non visible.
5.1.1.2 Threads
Quand une activité est lancée, le système crée un thread principal dans lequel s’exécutera l’application.
C’est ce thread qui est en charge d’écouter les évènements déclenchés par l’utilisateur
quand il interagit avec l’interface graphique. C’est pourquoi le second nom du thread principal
est thread UI (UI pour User Interface, « interface utilisateur » en français).
Mais il est possible d’avoir plusieurs threads. Android utilise un pool de threads (comprendre une
réserve de threads, pas une piscine de threads :p ) pour gérer le multitâche. Un pool de threads
comprend un certain nombre n de threads afin d’exécuter un certain nombre m de tâches (n et m
n’étant pas forcément identiques) qui se trouvent dans un autre pool en attendant qu’un thread
s’occupe d’elles. Logiquement, un pool est organisé comme une file, ce qui signifie qu’on empile
les éléments les uns sur les autres et que nous n’avons accès qu’au sommet de cet empilement.
Les résultats de chaque thread sont aussi placés dans un pool de manière à pouvoir les récupérer
dans un ordre cohérent. Dès qu’un thread complète sa tâche, il va demander la prochaine tâche
qui se trouve dans le pool jusqu’à ce qu’il n’y ait plus de tâches.
Avant de continuer, laissez-moi vous expliquer le fonctionnement interne de l’interface graphique.
Dès que vous effectuez une modification sur une vue, que ce soit un widget ou un layout,
cette modification ne se fait pas instantanément. À la place, un évènement est créé. Il génère un
message, qui sera envoyé dans une pile de messages. L’objectif du thread UI est d’accéder à la pile
des messages, de dépiler le premier message à traiter, de le traiter, puis de passer au suivant. De
plus, ce thread s’occupe de toutes les méthodes de callback du système, par exemple onCreate()
ou onKeyDown(). Si le système est occupé à un travail intensif, il ne pourra pas traiter les
méthodes de callback ou les interactions avec l’utilisateur. De ce fait, un ARN est déclenché pour
signaler à l’utilisateur qu’Android n’est pas d’accord avec ce comportement.
De la sorte, il faut respecter deux règles dès qu’on manipule des threads :
1. Ne jamais bloquer le thread UI.
2. Ne pas manipuler les vues standards en dehors du thread UI.
Enfin, on évite certaines opérations dans le thread UI, en particulier :
329