Lorsque Swift a introduit le support natif de la concurrence dans la version 5.5, le protocole Sequence existant avait déjà établi un modèle d'itération synchrone par le biais de IteratorProtocol. Le protocole Sequence nécessite une méthode makeIterator() qui renvoie une fonction mutante next() produisant immédiatement des éléments sans suspension. Ce design précédait le paradigme async/await de Swift, créant un décalage fondamental entre les attentes de consommation synchrone et les capacités de production asynchrone qui nécessitaient une hiérarchie parallèle.
Le conflit central survient parce que la signature de méthode next() de Sequence ne peut pas inclure le mot-clé async. Si AsyncSequence devait raffiner Sequence, il hériterait d'une exigence d'accès synchrone aux éléments qui est impossible à satisfaire lorsque les données arrivent de manière asynchrone via des E/S réseau ou des minuteries. De plus, permettre à du code synchrone de déclencher des opérations asynchrones violerait les garanties de concurrence structurée de Swift, permettant potentiellement à du code asynchrone de s'exécuter en dehors d'un contexte de Task et de rompre la propagation d'annulation hiérarchique à travers le runtime.
Les architectes de Swift ont créé une hiérarchie de protocole indépendante où AsyncSequence ne hérite pas de Sequence. Le AsyncIteratorProtocol définit mutating func next() async throws -> Element?, marquant explicitement le point de suspension dans la signature de type. Cette isolation garantit que l'itération ne peut se produire que dans un contexte asynchrone, permettant au runtime de Swift de gérer la continuité, de gérer l'annulation des tâches, et de préserver la pile d'appels correctement tout en empêchant le code synchrone d'invoquer accidentellement des opérations dépendantes de la suspension.
// Tentative de mélanger sync et async (échec illustratif) protocol BrokenAsyncSequence: Sequence { // Ne peut pas satisfaire à la fois les exigences sync IteratorProtocol.next() et async } // Conception async correcte struct TimedEvents: AsyncSequence { typealias Element = Date struct Iterator: AsyncIteratorProtocol { var count = 0 mutating func next() async -> Date? { guard count < 5 else { return nil } count += 1 await Task.sleep(1_000_000_000) // Point de suspension return Date() } } func makeAsyncIterator() -> Iterator { Iterator() } }
Scénario : Traitement des données de capteurs à haute fréquence dans une application de surveillance de la santé.
Description du problème : L'équipe de développement devait diffuser des données d'accélération à 60 Hz pour détecter les chutes à l'aide de CoreMotion. Ils ont initialement modélisé l'alimentation du capteur comme une Sequence, interrogeant le matériel dans une boucle while serrée sur le thread principal. Cette approche bloquait l'interface utilisateur pendant la collecte des données et risquait de provoquer la terminaison de l'application. Ils ont envisagé trois approches architecturales pour intégrer les rappels de capteur async avec les pipelines de traitement des données.
Solution 1 : Pont de blocage de thread.
Ils ont considéré d'envelopper l'API de capteur async dans un DispatchSemaphore pour forcer l'attente synchrone au sein d'un itérateur Sequence personnalisé.
Avantages : Permet d'utiliser des initialiseurs Array standard et des algorithmes map/filter.
Inconvénients : Bloque le thread appelant, risquant une terminaison par le watchdog sur iOS, gaspille des cycles CPU en attente, et empêche l'annulation pendant le sommeil.
Solution 2 : Délégation basée sur des rappels. Ils ont envisagé d'abandonner entièrement la conformité au Sequence, en utilisant des modèles de délégués avec des gestionnaires d'achèvement pour chaque mise à jour de capteur. Avantages : Non-bloquant, permet un accès matériel async sans geler le thread principal. Inconvénients : Perte de la composition des opérations Sequence, création d'une "ferme de rappels" profondément imbriquée lors de la mise en chaîne des transformations, et rend l'implémentation de la pression arrière presque impossible.
Solution 3 : AsyncSequence natif avec AsyncStream.
Ils envelopperaient les rappels de CoreMotion dans un AsyncStream utilisant des continuations, puis traiteraient avec for try await et le package AsyncAlgorithms.
Avantages : S'intègre à la concurrence de Swift, prend en charge l'annulation des tâches, permet l'utilisation des opérateurs throttle et debounce, et maintient une interface utilisateur réactive.
Inconvénients : Nécessite une cible de déploiement iOS 13+, et l'équipe doit apprendre les modèles de concurrence structurée.
Solution choisie : L'équipe a adopté la Solution 3, enveloppant les mises à jour de CMMotionManager dans un AsyncStream avec une politique .bufferingNewest(1). Cela garantissait que si le traitement des données était en retard par rapport à l'échantillonnage matériel de 60 Hz, seule la lecture la plus récente était conservée, empêchant l'engorgement de la mémoire.
Résultat : L'algorithme de détection des chutes maintenait une fréquence d'échantillonnage complète sans perdre de trames, l'utilisation du CPU a diminué de 70 % par rapport à l'approche de polling, et l'interface utilisateur est restée réactive. Le système a correctement libéré les ressources matérielles lorsque l'utilisateur a mis l'application en arrière-plan grâce à une annulation automatique de Task se propageant à l'itérateur de flux.
Question 1 : Puis-je utiliser break ou continue avec des labels dans une boucle for async, et que se passe-t-il avec l'itérateur ?
Réponse : Oui, le contrôle de flux avec des étiquettes fonctionne dans les boucles for try await. Cependant, les candidats comprennent souvent mal les implications du cycle de vie. Lorsque vous break sortez d'une boucle async, l'AsyncIterator sort immédiatement du scope. Si l'itérateur est un type valeur, son deinit s'exécute, libérant des ressources comme les descripteurs de fichiers. S'il s'agit d'un type référence, la référence est perdue. Crucialement, AsyncSequence n'a pas de méthode cancel() sur le protocole lui-même ; l'annulation est gérée par la hiérarchie Task. Le nettoyage de l'itérateur doit être implémenté dans son deinit, pas dans un gestionnaire d'annulation séparé, car le protocole ne peut garantir que tous les itérateurs sont des types de référence.
Question 2 : Pourquoi AsyncSequence ne prend-il pas en charge l'initialiseur Array(myAsyncSequence) comme les séquences régulières ?
Réponse : L'initialiseur de Array nécessite que son argument soit conforme à Sequence, pas à AsyncSequence. Puisque AsyncSequence ne raffine pas Sequence, vous ne pouvez pas le passer directement au constructeur Array. Les candidats oublient souvent que vous devez utiliser l'initialiseur Array spécifiquement conçu pour les séquences asynchrones : try await Array(myAsyncSequence). C'est une fonction async globale, pas un initialiseur par membres, car Swift ne prend pas en charge les initialiseurs async dans ce contexte. L'opération agrège tous les éléments en attendant chaque appel next() de manière séquentielle, et elle respecte l'annulation des tâches, lançant une CancellationError si la Task parente est annulée pendant la matérialisation.
Question 3 : Comment fonctionne la pression arrière dans AsyncStream par rapport à AsyncSequence de NotificationCenter ?
Réponse : Cela révèle un détail critique de l'implémentation. AsyncStream prend en charge la pression arrière : si le consommateur est lent, l'appel du producteur à yield se suspend jusqu'à ce que le consommateur appelle next(). Cela est implémenté via un sémaphore basé sur des continuations. Cependant, la séquence de NotificationCenter n'implémente pas la pression arrière ; elle utilise un tampon illimité, permettant aux notifications de s'accumuler indéfiniment si le consommateur ne peut pas suivre le rythme. Les candidats supposent souvent que toutes les implémentations AsyncSequence gèrent la pression arrière de manière uniforme. La réalité est que AsyncSequence est un protocole basé sur le tirage, mais le comportement du producteur est défini par l'implémentation. Comprendre que AsyncStream est l'outil principal pour faire le pont entre les API basées sur la poussée et les séquences async basées sur le tirage avec pression arrière est essentiel pour éviter l'épuisement de la mémoire dans des scénarios à fort débit.