Hermes : distinguer régression mémoire et cycle de vie des vues

Une hausse de mémoire peut pousser une équipe à reporter un SDK entier. Pour reprendre la migration, il faut d’abord séparer le problème corrigé, la mesure qui le révèle et les symptômes qui restent. Les notes Expo et le travail sur les vues natives fournissent deux angles complémentaires.

Repartir d’un correctif identifié

Le changelog SDK 57 (nouvelle fenêtre) documente la régression Hermes V1 associée à Worklets ou Reanimated et une autre régression de démarrage en développement. Sa mise à jour du 27 août précise la résolution dans expo@57.0.17 avec RN 0.86.3. Cette référence, postérieure à l’édition, permet de distinguer les deux problèmes sans attribuer au même patch tous les symptômes.

Une reprise d’upgrade devrait garder un témoin : même build, mêmes données et mêmes parcours répétés avant/après. Observer la mémoire après plusieurs cycles de navigation, pas uniquement au lancement. Pour le démarrage, séparer développement et release ; une amélioration du serveur de développement ne garantit pas un gain en production.

Déplacer une vue sans perdre sa surface

Le billet Teleport 1.2 (nouvelle fenêtre) explique pourquoi déplacer une vue native peut provoquer une image vide sur Android. Une vidéo ou une carte dépend d’une surface ; détacher la vue de la fenêtre peut interrompre son rendu. Le nouveau chemin de reparenting conserve cette attache lorsque les conditions le permettent, avec repli sur le comportement précédent dans les autres cas.

C’est un bon exemple de régression que des assertions JavaScript seules ne capturent pas. Pour une vidéo passant d’une carte à un plein écran, vérifier continuité de l’image, position de lecture, focus et geste de retour. Un enregistrement image par image apporte ici une preuve plus pertinente qu’un simple test de montage.

Choisir une lecture de performance

Une consommation mémoire qui ne redescend pas, une initialisation lente et une surface vidéo vide appellent des diagnostics différents. Une correction du runtime peut résoudre le premier problème sans toucher au rattachement d’une vue Android.

Avant d’ajouter une bibliothèque de rendu ou de changer le mécanisme OTA, écrire le symptôme à corriger et la limite de la mesure. Cela évite de transformer un correctif ciblé en migration plus large que nécessaire.