Terminez les tâches d’arrière-plan

Bonjour, je m’appelle Ryan, ingénieur logiciel chez Apple. Je vais expliquer comment votre app peut tirer parti du runtime en arrière-plan.

L’App Store regroupe des millions d’apps, et chacune apporte quelque chose d’unique. Votre app resplendit lorsqu’elle est sur le devant de la scène. Chaque pixel étant à votre disposition, vous pouvez créer des expériences mémorables.

Et c’est ce que l’on veut : des apps rapides, utiles, bien conçues, par des développeurs comme vous. Mais que se passe-t-il quand l’app passe en arrière-plan ?

Je vais m’intéresser au runtime d’arrière-plan, et à la création d’une boîte à outils adaptée à votre app, efficace et performante. L’app ne doit pas juste rester active. Elle doit être utile, effectuer des tâches comme la pré-extraction, la synchronisation et le chargement, pour fonctionner au prochain lancement. Bien utilisé, le runtime en arrière-plan rend votre app rapide, fluide, voire même un peu magique.

Je vais d’abord définir rapidement le premier plan et l’arrière-plan, puis j’évoquerai des principes sur la manière dont le système décide quand et à quelle fréquence les apps s’exécutent en arrière-plan.

Puis, je présenterai les moyens pour ce faire, notamment une nouvelle API permettant de poursuivre les tâches lancées au premier plan.

Toutes les apps au premier plan suivent le même rythme.

L’app et tout ce dont elle a besoin ; frameworks, ressources, etc. ; sont chargés en mémoire. C’est dans cet état que l’interface de votre app est au centre de l’attention sur l’appareil, on dit qu’elle est au premier plan.

Lorsque l’on quitte une app, mais que le processus reste actif, celle-ci passe en arrière-plan. Par défaut, les apps en arrière-plan sont suspendues. Elles ne bénéficient d’aucun temps CPU. Cela économise de la batterie, préserve la confidentialité et libère des ressources pour les apps au premier plan.

Votre app peut parfois demander du temps en arrière-plan pour terminer des tâches en cours avant d’être suspendue. Lorsque l’on revient à l’app via le sélecteur d’apps, celle-ci est reprise par le système et passe au premier plan.

Avant d’utiliser le runtime en arrière-plan, il faut comprendre comment le système hiérarchise et gère les ressources, et comment offrir une expérience optimale dans votre app.

Les principaux objectifs du système sont simples : préserver l’autonomie et optimiser les performances, tout en offrant une expérience fluide et réactive. Cela signifie que l’exécution en arrière-plan n’est pas garantie. Elle est opportuniste, souvent discrétionnaire et rigoureusement gérée. Les charges de travail efficaces comprennent cela et fonctionnent avec le système, et non contre lui.

La plus grande contrainte est l’énergie.

Chaque opération, cycle CPU, rendu GPU, requête réseau, et même l’utilisation du Neural Engine a un coût en termes de batterie. L’autonomie de la batterie est une ressource limitée. Afin de la préserver, le système regroupe les tâches à la sortie de veille de l’appareil, afin de réduire les activités inutiles en arrière-plan. Le runtime en arrière-plan est limité, les tâches de l’app effectuées en arrière-plan doivent donc être distinctes et personnalisées. Chaque tâche effectue une seule opération efficacement, compte tenu des priorités et contraintes du système. Ce travail en arrière-plan est visible dans les réglages de la batterie, où l’on voit quelles apps ont un fort impact sur l’autonomie de la batterie. iOS 26 offre des infos précieuses sur les performances de la batterie, avec des détails spécifiques à chaque app.

La meilleure chose à faire ici est d’être efficace. Si une tâche ne doit pas être exécutée de suite, reportez-la jusqu’à ce que l’appareil soit en charge. Si elle doit être exécutée, veillez à ce qu’elle soit légère et ciblée.

En plus de la batterie, le système doit aussi gérer d’autres ressources partagées telles que la mémoire, le temps CPU et la bande passante réseau. Lorsqu’une personne utilise son appareil, l’app au premier plan est prioritaire. Une app en arrière-plan consommant trop de mémoire ou de CPU n’est pas seulement inefficace. Elle entre aussi en concurrence avec l’expérience de premier plan. C’est là que le système peut intervenir. Il peut ralentir, suspendre, voire arrêter les processus trop coûteux.

La conclusion est simple. Limitez au maximum le travail en arrière-plan. Évitez les tâches trop lourdes et privilégiez le traitement par lot pour réduire l’empreinte mémoire.

Même lorsque les charges de travail se comportent bien, rien ne garantit qu’elles s’exécutent longtemps. La file d’attente des tâches d’arrière-plan n’est jamais vide, le système peut prioriser d’autres charges de travail. Cela dit, nous travaillons tous en équipe ici, le système ayant pour rôle d’optimiser l’expérience au premier plan.

Les charges de travail doivent être résilientes. Enregistrez régulièrement vos progrès. Réagissez rapidement aux signaux d’expiration, le système reprendra rapidement la charge de travail. Il apprécie les processus coopératifs et utilise ces comportements pour la planification future. Mais en fin de compte, c’est l’utilisateur de l’appareil qui a le dernier mot. Il influence la planification en modifiant des réglages comme Économie d’énergie, Actualisation en arrière-plan et Faibles données. Le système offre une grande transparence, pour vous permettre de prendre vos propres décisions. Si votre app consomme trop de batterie en arrière-plan, des mesures peuvent être prises, et ne seront pas toujours en votre faveur.

Par conséquent, le travail en arrière-plan doit être courtois, léger et respecter les préférences, et votre impact doit être proportionnel à la valeur que vous apportez. Même lorsque tous les processus du système respectent ces principes, ils s’exécutent dans un environnement complexe et très dynamique.

La disponibilité du réseau, la charge CPU, l’activité de l’appareil, l’état thermique et le niveau de la batterie sont pris en compte dans les décisions de planification.

Toutefois, le système tient compte de ces conditions difficiles et offre à tout moment la meilleure expérience possible. Ainsi, même des tâches bien conçues peuvent être reportées si les conditions ne sont pas réunies, afin d’optimiser la situation générale. Il est essentiel de rester adaptable. Veillez à ce que le travail reste atomique et léger, tout en communiquant vos exigences. Des charges de travail reprenant là où elles se sont arrêtées permettent de progresser quand des opportunités de runtime se présentent. Plus vous comprenez et vous adaptez aux conditions et priorités du système, plus vos charges de travail seront efficaces.

Efficacité, minimalisme, résilience, courtoisie et adaptabilité. Telles sont les clés pour créer un travail en arrière-plan bien intégré à la plate-forme. Il peut être utile de se poser quelques questions pendant le développement.

Qui a lancé la tâche ? Le travail a-t-il été explicitement lancé ou est-ce une tâche qui peut être effectuée ultérieurement ?

Quelle est la durée de la tâche ? Classez vos tâches : courtes, moyennes et longues. Ce travail est-il essentiel à l’état et à la fraîcheur de l’app ? Les téléchargements en arrière-plan améliorent la vivacité de l’app, mais les chargements de télémétrie n’ont pas d’avantage immédiat pour l’utilisateur. Enfin, le travail requiert-il un consentement ou une contribution ?

Le runtime en arrière-plan n’est pas adapté à ce type de charge de travail. Je recommande d’adopter une autre approche dans ce cas. Une fois ces bases posées, voyons comment vous pouvez concevoir efficacement vos tâches. iOS fournit plusieurs API qui permettent de demander un runtime en arrière-plan, et chaque API suppose un type ou un profil distinct selon la prise en charge du travail. Cela permet au système d’ajuster le runtime de l’app selon les contraintes et conditions que j’ai évoquées. Par exemple, nous voulons que nos apps les plus utilisées aient toujours le contenu le plus récent et le plus pertinent. Le système doit comprendre les modèles d’utilisation des apps afin d’optimiser les tâches d’arrière-plan et la prise en charge.

C’est le cas de la première API, BGAppRefreshTask.

Les apps l’utilisent pour récupérer silencieusement du contenu depuis les serveurs avant leur utilisation, selon le principe de courtoisie. Ces tâches sont alignées sur l’historique d’utilisation des apps. Les apps souvent utilisées ont plus de chances d’être planifiées, ce qui garantit un contenu actualisé à chaque lancement.

Pour créer une tâche de rafraîchissement dans SwiftUI, ajoutez le modificateur BackgroundTask à une scène. Lorsque le système réactive l’app en arrière-plan, il invoque cette fermeture, et suspend l’app au retour de la fermeture.

Le rafraîchissement couvre les cas basés sur la récupération, mais vous souhaitez peut-être conserver des documents distants, mis à jour rarement ou de manière irrégulière. Les notifications push en arrière-plan sont une solution élégante. Lorsque le serveur envoie une notification à propos d’un nouveau contenu, le système réactive l’app au bon moment pour le récupérer. Cela diffère du rafraîchissement de l’app. Une mise à jour est envoyée à l’appareil au lieu d’être récupérée de manière opportuniste.

Les notifications push en arrière-plan signalent un nouveau contenu distant et sont toujours considérées comme facultatives.

Elles ont une faible priorité et sont regroupées pour réduire la surcharge et la consommation d’énergie.

Lorsque quelqu’un supprime votre app du sélecteur d’apps, le système respecte son intention. Les notifications ne sont pas transmises à l’app tant qu’elle n’est pas relancée.

Vous pouvez parfois souhaiter que votre app effectue d’autres types de tâches. Par exemple, exécuter un modèle ML sur des données générées, ou gérer la maintenance de la base de données.

L’API BGProcessingTask vous permet de faire cela.

L’enregistrement de cette tâche est très simple. Il faut un identifiant de tâche, une file d’attente de rappel et une fermeture invoquée au runtime.

Vous devez enregistrer BackgroundTasks immédiatement lors du lancement. Ainsi, le système est immédiatement informé de votre tâche si elle est lancée en arrière-plan, et invoque de suite son gestionnaire. Le traitement des tâches prend en charge des configurations supplémentaires selon les principes que j’ai évoqués. Par exemple, si le travail n’est pas sensible à la latence, une tâche importante peut choisir de s’exécuter lorsque l’appareil est en charge et connecté au réseau. Cela optimise l’autonomie, l’empreinte de l’app et les réglages de batterie. J’ai abordé les API qui permettent à l’app d’obtenir du runtime pour les tâches lancées en arrière-plan. Cependant, vous souhaitez parfois disposer d’un peu de temps pour continuer à fonctionner pendant la transition vers l’arrière-plan. Les API de début et de fin des tâches d’arrière-plan permettent à l’app de terminer ce qui peut être irrécupérable en cas d’interruption ou d’abandon.

Prenons l’exemple d’un enregistrement de l’état. Selon le travail, une interruption prématurée peut nuire à l’expérience utilisateur.

En encapsulant votre code dans ces appels d’API, le système est informé que l’app effectue une tâche cruciale qui ne doit pas être interrompue. Cette API est idéale si vous nettoyez des descripteurs de fichiers ou fermez des connexions à une base de données.

La prise en charge en arrière-plan sur iOS est vaste et conçue pour gérer de nombreuses tâches, y compris celles lancées par l’utilisateur. Il est essentiel de garantir la fiabilité des opérations lancées par l’utilisateur, pour une expérience optimale. Dans iPadOS et iOS 26, la tâche de traitement en arrière-plan permet à votre app de prendre en charge ces fonctionnalités. Cette tâche permet de poursuivre le travail même si l’app est en arrière-plan, grâce à un système dont l’UI communique la progression. Prenons l’exemple de l’app Journal. La tâche de traitement continu exécute les exportations en arrière-plan, avec des mises à jour de la progression renvoyées à l’initiateur. Une fois l’opération terminée, le système effectue une brève mise à jour, puis ferme l’UI. Les utilisateurs gardent le contrôle. Ils peuvent consulter la progression et annuler le travail à tout moment, ce qui permet de proposer des fonctionnalités complexes.

La poursuite des tâches commence par une action explicite de l’utilisateur dans votre app, comme un appui sur un bouton ou un geste. Chaque tâche représente un objectif clair et immédiat, comme exporter un fichier, publier du contenu sur les réseaux sociaux ou effectuer une mise à jour sur un accessoire connecté. Ces tâches permettent de mesurer les progrès réalisés et il est facile de comprendre ce que signifie la fin d’une tâche.

Les utilisateurs ne s’attendent pas au lancement automatique de tâches, même si une préférence est définie dans l’app. Évitez les charges de travail automatiques comme la maintenance, les sauvegardes ou la synchronisation de photos. Si une tâche démarre sans action explicite, les utilisateurs risquent de ne pas comprendre son objectif ou ce que signifie sa progression. Le lancement inattendu de cette tâche peut entraîner son annulation. Pour ces tâches, envisagez d’autres API plus adaptées.

Compte tenu de tout cela, l’adoption des tâches de traitement continu est un jeu d’enfant. D’abord, ajoutez un identifiant de tâche à votre Info.plist. Vous l’utiliserez pour enregistrer un gestionnaire de lancement qui gère l’état et signale la progression. Ensuite, soumettez une demande de tâche à l’invite. Commençons par l’identifiant. Vous le définissez en ajoutant une valeur au tableau des identifiants autorisés pour le planificateur de tâches d’arrière-plan dans Info.plist, avec l’ID de lot de l’app comme préfixe.

En plus des identifiants statiques, les tâches de traitement continu prennent en charge une nouvelle notation générique avec un suffixe dynamique.

Les identifiants génériques commencent toujours par votre ID de lot, suivi d’un contexte sémantique. Le nouvel élément ici est le point astérisque, qui indique qu’un suffixe dynamique sera ajouté à l’identifiant lors de l’enregistrement et de la soumission.

Un identifiant complet, pour l’enregistrement et la soumission, se présente comme suit.

Pour l’instant, restons-en à quelque chose de plus statique.

Une fois cela sélectionné, le planificateur doit savoir quel code exécuter lorsque votre tâche de traitement continu est appelée. Comme avant, une fermeture fournie au planificateur est invoquée après la soumission d’une demande de tâche. Il y a un changement important. Il n’est pas nécessaire d’enregistrer les gestionnaires de lancement avant la fin du lancement de l’app. À la place, vous enregistrez ces gestionnaires de manière dynamique lorsque l’intention de les utiliser est exprimée.

Comme dans Journal, il faut fournir des mises à jour régulières sur la progression de la charge de travail. Si cette progression est plus lente que prévu, le système demandera à l’initiateur s’il souhaite que le travail se poursuive. Le système s’appuie sur ces mises à jour pour gérer le travail en cours. Ainsi, les tâches qui ne signalent aucune progression expirent, ce qui permet au système de récupérer et de redistribuer les ressources. L’app communique activement ces mises à jour à l’aide du protocole ProgressReporting. Ce faisant, le système les surveille en permanence et affiche la progression dans l’UI. Cependant, le système peut être amené à interrompre une tâche prématurément si les conditions changent. Pour parer à cela, la tâche doit fournir un gestionnaire d’expiration qui sera appelé lorsqu’il faudra l’interrompre. Le gestionnaire permet de modifier rapidement une variable afin que la tâche puisse s’arrêter correctement et éviter tout travail supplémentaire.

Il est essentiel que vous appeliez setTaskCompleted lorsque votre tâche est terminée. Cela indique au système que vous avez terminé. J’ai expliqué comment gérer les mises à jour de progression et les interruptions potentielles, et comment signaler l’achèvement d’une tâche. Mettons cela en pratique en créant et en soumettant une demande de tâche valide, initiée par l’utilisateur.

D’abord, initialisez un objet de demande de tâche. Vous avez besoin de trois infos : un identifiant correspondant à celui de votre Info.plist, un titre localisé et un sous-titre localisé. Ces infos sont visibles dans l’UI du système.

Ensuite, fournissez une stratégie de soumission que le système devra respecter. Par défaut, si le système constate qu’il ne peut pas exécuter de suite la tâche de traitement continu, il l’ajoute à la fin de la file d’attente. Vous n’avez rien à spécifier de plus pour cela. La mise en file d’attente n’est pas toujours la meilleure solution. Que se passe-t-il si la tâche n’est utile que si elle est lancée de suite ? Au lieu de la mettre en file d’attente, vous pouvez indiquer au système de rejeter la soumission si elle ne peut pas démarrer immédiatement. Votre app reçoit ainsi un feedback instantané, ce qui permet de gérer la situation de manière appropriée.

Une fois votre stratégie définie et la requête configurée, il suffit de soumettre cela au planificateur et de laisser le système gérer la charge de travail. Ceci est le processus de base concernant les tâches de traitement continu. En fournissant le titre et le sous-titre et en tenant compte de la stratégie de soumission, l’intégration au système est transparente et respecte le principe de consentement. Cette API offre encore plus de capacités qu’il n’y paraît. Dans iPadOS et iOS 26, vos tâches de traitement continu peuvent utiliser le GPU en arrière-plan sur les appareils pris en charge.

Pour en profiter, assurez-vous d’ajouter la fonctionnalité GPU en arrière-plan dans les réglages de votre projet Xcode.

Avec cette fonctionnalité, vous pouvez et devez interroger dynamiquement la propriété des ressources prises en charge par le planificateur. Cela permet à l’app de comprendre ce que l’appareil actuel prend en charge au moment du runtime, afin d’adapter les exigences de votre tâche. Cette vérification est importante. Le système applique ces exigences. Une demande concernant des ressources indisponibles sera rejetée lors de sa soumission, pour maintenir le système et la tâche dans un état sain et connu.

Enfin, n’oubliez pas le contexte plus large des priorités du système. iOS priorise l’expérience au premier plan, ainsi votre tâche d’arrière-plan peut bénéficier d’une qualité de service inférieure à celle offerte lorsque l’app est active. Cependant, le système est intelligent à cet égard. Lorsque votre app revient au premier plan, il augmente intelligemment la priorité de votre tâche, pour garantir la fluidité et la réactivité du système. Ces API offrent les fonctionnalités d’exécution en arrière-plan les plus puissantes et les plus fluides à ce jour, en ajoutant BGContinuedProcessingTask à vos outils. Maintenant que vous comprenez parfaitement ces tâches et leur place dans le système global, vous êtes prêt à les adopter. Nous avons hâte de découvrir comment vous utiliserez ces outils pour créer des expériences d’arrière-plan intelligentes et efficaces. Merci de votre attention.