Historique
Les capacités de réflexion de Swift ont été fondamentalement repensées lors de l'initiative de stabilité de l'ABI dans Swift 5.0. Avant cela, la réflexion reposait sur des éléments internes du compilateur instables qui changeaient à chaque mise à jour de la chaîne d'outils. L'API Mirror a été introduite pour fournir une interface publique stable pour l'inspection de types à l'exécution, permettant aux outils de débogage et à la journalisation générique de fonctionner sans connaissances de types à la compilation. Cela nécessitait un format de métadonnées capable de survivre à l'évolution de la bibliothèque, où les mises en page des structures pourraient changer entre les versions.
Problème
Lorsqu'une structure est marquée comme résiliente (par défaut pour les types publics en mode d'évolution de bibliothèque), le compilateur ne peut pas coder en dur des offsets de mémoire fixes pour ses propriétés stockées. Le codage en dur romprait la compatibilité binaire si l'auteur de la bibliothèque ajoute, supprime ou réorganise des champs dans une mise à jour future. De plus, le système de réflexion doit exposer suffisamment de métadonnées pour reconstruire les noms et types des champs du type à l'exécution, tout en respectant la frontière résiliente qui cache les détails d'implémentation de l'accès direct.
Solution
Le compilateur Swift émet des descripteurs de champs dans la section __swift5_fieldmd des métadonnées du binaire. Ces descripteurs ne contiennent pas d'offsets statiques ; au lieu de cela, ils stockent des accessoires d'offset relatif ou des calculs de mise en page au moment de l'instanciation qui résolvent la localisation réelle de la mémoire à l'exécution. Pour les types résilients, les métadonnées incluent un vecteur d'offset de champ qui est peuplé lorsque le type est instancié dans le processus en cours. Cette indirection permet à l'API Mirror de parcourir les propriétés en utilisant des offsets calculés qui s'adaptent à la version spécifique de la bibliothèque chargée à l'exécution, préservant à la fois la stabilité de l'ABI et les capacités de réflexion.
import Foundation struct ResilientConfig { let timeout: Double private let apiKey: String // Accessible via Mirror malgré 'private' } let config = ResilientConfig(timeout: 30.0, apiKey: "secret") let mirror = Mirror(reflecting: config) for child in mirror.children { print("Propriété: \(child.label ?? "sans nom"), Valeur: \(child.value)") }
Une architecture d'application iOS modulaire sépare le module Réseau (SDK propriétaire) du module Analyse (interne). Le module Réseau renvoie des structures de configuration complexes contenant des jetons d'authentification privés qui ne devraient pas être exposés via des accesseurs publics, mais l'équipe Analyse nécessite la journalisation de tous les paramètres de configuration pour déboguer des délais d'attente intermittents.
Solution 1 : Conversion en dictionnaire public
L'équipe Réseau pourrait exposer une méthode toDictionary() qui associe manuellement des champs à des chaînes.
Avantages : Sécurité de type à la compilation, contrôle explicite des données exposées, performance rapide.
Inconvénients : Nécessite une maintenance chaque fois que la structure change ; ne peut pas refléter les nouveaux champs ajoutés dans les mises à jour de l'SDK sans recompilation du client ; expose des champs sensibles si le développeur oublie de les filtrer.
Solution 2 : Introspection d'exécution Objective-C
Exploitation de valueForKey: via le pont NSObject.
Avantages : Familier pour les développeurs ayant des antécédents en Objective-C.
Inconvénients : Les structures Swift ne sont pas des sous-classes de NSObject ; forcer la conformité @objc change la sémantique de valeur en sémantique de référence et augmente considérablement la taille binaire ; ne fonctionne pas avec des types Swift natifs.
Solution 3 : Réflexion Swift via Mirror
Implémentation d'un logger générique utilisant Mirror(reflecting:) pour itérer sur toutes les propriétés stockées indépendamment du contrôle d'accès.
Avantages : S'adapte automatiquement aux nouvelles propriétés dans les mises à jour de l'SDK sans recompilation ; respecte les frontières de résilience ; fonctionne avec les types de valeur et le code générique.
Inconvénients : Mirror alloue de la mémoire sur le tas pour son stockage interne, ce qui le rend inadapté pour une journalisation à haute fréquence ; contourne le contrôle d'accès, potentiellement exposant des secrets privés s'ils ne sont pas filtrés via CustomReflectable ; ne peut pas refléter des champs de bits C ou des propriétés calculées.
Solution choisie
L'équipe a adopté la Solution 3 avec un wrapper qui vérifie la conformité à CustomReflectable pour permettre au SDK Réseau de fournir une vue assainie. Le module Réseau a implémenté customMirror pour exclure l'apiKey tout en exposant le timeout et d'autres champs sûrs.
Résultat
Le module Analyse a réussi à consigner les états de configuration à travers trois mises à jour majeures de l'SDK sans changements rompus. Cependant, lorsque l'équipe Réseau a ajouté un wrapper de structure C pour des options de socket de bas niveau contenant des champs de bits, ces champs spécifiques sont apparus comme vides dans les journaux. Cela a nécessité de la documentation pour expliquer la limitation de Mirror, tandis que le reste de la configuration continuait à se refléter automatiquement.
Comment Mirror empêche-t-il la récursion infinie lors de la réflexion sur des structures de données autoréférentielles, et quelle responsabilité incombe au développeur lors de l'implémentation de CustomReflectable ?
Mirror détecte les cycles de référence en suivant l'identité des instances de classe pendant la marche de réflexion. Lorsqu'il rencontre une instance de classe, il vérifie si cet objet est déjà présent dans la pile de récursions actuelle ; si c'est le cas, il arrête le parcours pour éviter un débordement de pile. Pour les types de valeur, la récursion se produit uniquement s'ils contiennent des références formant des cycles. Cependant, lorsque le développeur implémente CustomReflectable et construit manuellement un Mirror avec children, le runtime ne peut pas détecter les cycles dans cette construction personnalisée. Le développeur doit s'assurer que la séquence children ne crée pas de boucles infinies, par exemple en vérifiant une limite de profondeur de récursion ou en maintenant son propre ensemble de visités lors de la construction d'une réflexion personnalisée pour des structures en forme de graphe.
Pourquoi la réflexion sur une structure via Mirror rapporte-t-elle parfois différentes mises en page de mémoire par rapport à la mise en page compilée réelle, notamment avec des structures C contenant des champs de bits ou des unions ?
Les métadonnées de réflexion de Swift sont conçues pour les types Swift et utilisent des métadonnées d'importation Clang pour l'interopérabilité C. Les champs de bits C et les unions ne sont pas représentés comme des propriétés stockées distinctes avec des adresses stables ; ils sont représentés comme un stockage opaque ou un remplissage en ligne dans la traduction des types de l'importateur Clang. L'API Mirror nécessite des champs adressables pour construire sa collection children. Par conséquent, les champs de bits sont invisibles à la réflexion car ils manquent de descripteurs de champ dans la section __swift5_fieldmd, et les membres d'union peuvent apparaître comme superposés ou mal typés car les métadonnées décrivent le conteneur de l'union plutôt que les cas individuels. C'est une limitation fondamentale : Mirror reflète la vue Swift du type, pas la mise en page sous-jacente C.
Quel est le coût de performance d'accès aux propriétés via Mirror par rapport à un accès direct, et pourquoi le coût est asymétrique entre la lecture du nombre de propriétés et la lecture des valeurs des propriétés ?
Accéder aux propriétés via Mirror est plusieurs ordres de magnitude plus lent qu'un accès direct car cela implique des recherches de métadonnées à l'exécution, une allocation de tas pour l'instance de Mirror, et des appels indirects à travers des fonctions d'accessibilité de champ stockées dans les métadonnées de type. Lire le nombre de children nécessite d'analyser les métadonnées des descripteurs de champ pour déterminer le nombre de propriétés stockées, ce qui est un scan relativement rapide de la section __swift5_fieldmd. Cependant, accéder aux valeurs réelles nécessite d'appeler des témoins de valeur ou des fonctions d'accessibilité spécialisées pour chaque champ, ce qui peut impliquer de copier des données, de gérer des comptes de référence pour les types ARC, et de franchir des frontières de résilience. Pour les classes, ce coût inclut des vérifications d'exécution Objective-C. Par conséquent, itérer sur mirror.children pour extraire des valeurs a un coût supérieur à celui de simplement vérifier mirror.children.count, ce qui rend Mirror inadapté pour les chemins chauds malgré son utilité pour le débogage.