Guide complet des coroutines Kotlin : maîtriser launch, async et await

Si votre application Android s'est déjà figée ou n'a plus répondu pendant un téléchargement, vous rencontrez probablement des problèmes avec le thread principal. Dans le monde du développement mobile, assurer une fluidité optimale lors de l'exécution de tâches exigeantes est un véritable défi, et c'est là que les coroutines Kotlin entrent en jeu . Elles nous permettent d'écrire du code asynchrone sans nous enliser dans des rappels interminables.

Imaginez les coroutines comme des threads légers ; elles ne créent pas un nouveau thread système à chaque exécution, mais exploitent des groupes de threads existants et un système d'ordonnancement très ingénieux. Cela les rend incroyablement efficaces, et le code se lit de manière quasi séquentielle, même si une multitude de pauses et de reprises se déroulent en arrière-plan , de sorte que l'utilisateur ne perçoit aucun décalage à l'écran.

Le secret de la suspension : suspendre et reprendre

Contrairement aux fonctions classiques, les coroutines introduisent deux concepts clés. Premièrement, `suspend` permet de suspendre l'exécution d'une tâche tout en sauvegardant son état. Deuxièmement, `resume` reprend l'exécution exactement là où elle s'était arrêtée. Il est important de noter qu'une fonction suspendue ne bloque pas le thread sur lequel elle s'exécute ; elle se met simplement en pause pour permettre à d'autres tâches de se poursuivre pendant qu'elle attend une réponse, par exemple d'une base de données.

Il est essentiel de comprendre que l'utilisation du mot-clé `suspend` ne déplace pas automatiquement le code vers un thread secondaire. Pour garantir la sécurité du programme principal , il est nécessaire d'associer ces fonctions à des dispatchers appropriés, afin d'éviter que les opérations gourmandes en ressources ne saturent l'interface utilisateur.

Coroutines Kotlin : maîtriser launch, async et await

Répartiteurs : Où la magie opère-t-elle ?

Pour indiquer à Kotlin quel thread utiliser pour exécuter chaque portion de code, on utilise des Dispatchers . Tous les Dispatchers n'ont pas la même fonction ; il est donc important de savoir choisir le bon.

Répartiteurs.PrincipalCet outil permet d'interagir avec l'interface utilisateur. Il ne doit être utilisé que pour des modifications visuelles rapides ou pour interagir avec LiveData, car toute opération complexe entraînera une erreur. Application ne répondant pas (ANR).
Dispatchers.IOIl est optimisé pour les tâches d'entrée/sortie. C'est le site idéal pour appels API, lire des fichiers sur le disque ou gérer la base de données Room.
Dispatchers.DefaultConçu pour les tâches gourmandes en ressources processeur, par exemple lorsque vous avez besoin de traiter un JSON géant ou trier une très longue liste d'éléments.

Une technique courante et recommandée consiste à utiliser `withContext` . Cette fonction permet de modifier le dispatcher au sein d'une fonction suspendue sans avoir recours à des callbacks. Ainsi, le développeur appelant la fonction n'a pas à se soucier du thread d'exécution, car la fonction elle-même assure sa propre sécurité en basculant en interne vers le thread d'E/S ou le thread par défaut.

Lancement ou asynchrone : lequel choisir ?

Lorsque nous voulons démarrer une coroutine, nous avons deux voies principales selon que la tâche doit renvoyer une valeur ou non.

L' opérateur `launch` est ce que l'on appelle une exécution « sans retour ». Il est utilisé pour les tâches qui ne renvoient pas de résultat, comme la mise à jour d'une couleur à l'écran ou l'enregistrement de données dans le cache. Il renvoie un objet `Job` , qui est en quelque sorte une télécommande permettant d'annuler la coroutine si nécessaire.

En revanche, `async` est utilisé lorsqu'une valeur de retour est nécessaire. Cet opérateur renvoie un `Deferred<T>` , qui est une sorte de promesse d'un résultat ultérieur. Pour obtenir cette valeur, il faut appeler la fonction `await()` , qui suspend l'exécution jusqu'à ce que le résultat soit disponible. L'un des atouts de `async` est qu'il permet les appels parallèles ; si trois requêtes `async` sont effectuées, elles seront toutes trois envoyées au serveur simultanément, optimisant ainsi le temps d'attente total.

Gestion structurée de la concurrence et du cycle de vie

Pour éviter que les coroutines ne continuent de s'exécuter après la fermeture de l'écran par l'utilisateur (ce qui provoquerait des fuites de mémoire), Kotlin utilise la concurrence structurée . Celle-ci est gérée par le biais de CoroutineScope , qui recense toutes les coroutines lancées en son sein.

Sous Android, il est courant d'utiliser des portées prédéfinies comme `viewModelScope` ou `lifecycleScope` . Celles-ci sont très pratiques car elles annulent automatiquement toutes les tâches en cours lorsque le `ViewModel` est détruit ou que l'`Activity` se termine. Si vous devez créer votre propre portée, vous pouvez combiner un `Job` et un `Dispatcher`, mais n'oubliez jamais d'appeler ` scope.cancel()` dans la méthode de nettoyage de votre classe.

Gestion des erreurs et des cas particuliers

La gestion des exceptions varie selon le constructeur utilisé. Avec `launch` , si une erreur survient et n'est pas interceptée, l'application se ferme immédiatement. En revanche, avec `async` , l'exception est stockée dans l'objet `Deferred` et ne sera levée que lors de l'appel à ` await()` , ce qui peut parfois entraîner des erreurs non détectées si l'on n'y prend pas garde.

Pour gérer cela naturellement, il est préférable d'encapsuler les appels dans des blocs try-catch , ce qui rend le code asynchrone aussi simple à écrire que le code synchrone. De plus, si l'on souhaite qu'une coroutine soit insensible à l'annulation par son parent, on peut utiliser `NonCancellable` avec `withContext`, mais il faut procéder avec une extrême prudence afin de ne pas rompre la hiérarchie de concurrence.

L'intégration de tout cela avec des bibliothèques comme Retrofit est un jeu d'enfant, car les versions modernes prennent en charge nativement les fonctions suspendues. En définitive, le flux de travail idéal consiste à ce que le ViewModel lance la coroutine, le Repository gère la logique métier et la source de données effectue la requête auprès de Dispatchers.IO , tout en conservant une interface fluide et un code propre.