Réflexions après avoir résolu un problème de clavier récurrent de manière aléatoire (ReactNative)

Cet article partage avec vous mes réflexions sur la résolution d'un problème de clavier récurrent de manière aléatoire. Il est très significatif. Les amis intéressés peuvent y jeter un œil

Il a fallu près d'une semaine pour le résoudre récemment. J'ai trouvé un bug sur le terminal mobile. C'est un bug très intéressant, quelque chose comme ça. C'est une histoire relativement longue, si vous êtes intéressé, vous pouvez continuer à lire.

De quel type de bug s'agit-il ? Tout d'abord, après avoir saisi du contenu dans la zone de saisie, cliquez sur Terminé/Rechercher. Deuxièmement, cliquez sur certaines

zones vides<.> sur la page, le clavier contextuel apparaîtra et le curseur se concentre sur La zone de saisie la plus récemment saisie. À l'heure actuelle, la réponse de l'application au comportement des utilisateurs rendra les utilisateurs confus et confus. En résumé, il présente les caractéristiques suivantesL'application est normale au début, mais elle ne peut pas être reproduite à chaque fois

Une fois Ce bug se produit sur chaque page avec une zone de saisie.

• Le scénario récurrent est inconnu. On sait actuellement que plus l'application est utilisée longtemps, plus il est probable qu'il se produise. Une fois l'application fermée en arrière-plan, la maladie redémarrera et disparaîtra à nouveau.

• Comment corriger ce bug
• La première étape est d'essayer de le stabiliser à nouveau
  Nous avons d'abord essayé de trouver un parcours utilisateur minimal pour reproduire ce bug, j'ai eu relativement de la chance à ce moment-là, et il m'a fallu environ une demi-journée pour trouver le plus petit chemin de réapparition.

Sans parler du contexte business, présentons brièvement la logique de page de l'application.

Notre application dispose d'une page d'accueil après la connexion. Il y a trois onglets sur la page d'accueil qui peuvent être glissés ou cliqués pour basculer. Il y a également certains menus de fonctions sur la page à onglets. L'un des menus de fonctions peut être cliqué. pour passer à une autre nouvelle page avec une zone de saisie.

La page est à peu près la suivante. Si vous n'êtes pas un UX professionnel, ne soyez pas surpris si elle est moche.

Un chemin que nous avons trouvé et qui peut être reproduit rapidement est

Après vous être connecté à la page d'accueil, changez trois fois à plusieurs reprises, tabulez plusieurs fois (plus de 20 fois)

Cliquez sur menuA pour accéder à une page avec une zone de saisie

• Saisissez les données dans la saisie et cliquez sur Terminé du clavier logiciel

• Cliquez sur la zone vide de la page

• et le clavier logiciel sortira.
• La deuxième étape consiste à essayer de découvrir à partir de la partie code pourquoi le problème se produit dans le scénario minimum
  Après avoir trouvé un chemin de reproduction minimum, nous pouvons découvrir à partir du code pourquoi le problème se produit.
Comme ce bug ne disparaît pas après le redémarrage de l'application, nos soupçons se portent vers le problème de rendu, qui est très probablement causé par le composant.

Il y a quelques suppositions parmi nous

Il y a un problème avec le composant d'entrée encapsulé par nous-mêmes

Il y a un problème avec le composant coulissant des trois onglets, coulissant La vue défilante dans le composant affecte le système de réponse gestuelle de RN

• Enfin, il semble que ce ne soit pas le cas à ce moment-là, j'étais jumelé. avec une autre collègue du groupe et elle a découvert qu'il est facile d'avoir des problèmes lorsqu'il y a de nombreuses requêtes. Le problème était également soupçonné d'être causé par le traitement des requêtes réseau. Ce soupçon n’est en fait pas tout à fait fondé, mais il trouve une solution pour nous.
• Nous avons finalement constaté que toutes nos requêtes réseau ont une couche de masque et un symbole d'invite de chargement similaire au spinner du Web (ActivityIndicator en RN) sur la page avant que le résultat de la requête ne soit renvoyé. Cette partie affectera. rendu des pages.

  Si cette partie est supprimée (le masque n'apparaîtra pas avant l'arrivée de la demande), le bug disparaîtra. Cette découverte était encore choquante et déroutante à l'époque, car il semble qu'une partie de la raison ait été trouvée mais nous avons quand même. Je n'ai pas compris pourquoi.

La troisième étape consiste à essayer de réparer (sans clarifier la cause profonde)

Avec cette idée en tête, nous essayons de le réparer. Selon les besoins de l'entreprise, nous ne pouvons pas annuler l'utilisation d'ActivityIndicator, car il est vraiment nécessaire de donner aux utilisateurs des invites appropriées.

Nous avons essayé de modifier l'implémentation de mask. Dans l'ancien, nous avons utilisé un composant RN tiers react-native-root-siblings pour nous aider à insérer un élément frère au niveau racine pour afficher notre chargement. symbole d'invite.

Généralement, après l'envoi de la requête mais avant que le résultat de la requête n'arrive, nous insérons un nouvel élément frère et le supprimons une fois la requête terminée. À cette époque, on soupçonnait que, parce que cette partie modifiait à plusieurs reprises la structure des éléments de la page, la logique de nouvelle destruction était remplacée par une logique de nouvelle mise à jour, ce qui réduisait la modification des éléments. Lors de la mise à jour, le simple fait d'essayer d'empêcher l'apparition de l'ActivityIndicator semble être masqué.

Étape 4 : Testez si le bug peut être reproduit

Nous espérons corriger ce bug en réduisant les suppressions et créations répétées d'éléments de page. Quel est le résultat ?
C’est tellement magique que c’est difficile à reproduire. Nous sommes très heureux, même si nous n’en comprenons toujours pas la raison.
Plus tard, QA a déclaré qu'il l'avait rencontré à plusieurs reprises sur des appareils réels, ce qui nous a rendu encore plus perplexes, c'est que la probabilité d'apparition a effectivement diminué, mais pourquoi apparaît-elle encore ?

Étape 5 : Analyser la cause première du bug

À ce stade, nous devons comprendre la véritable cause du bug.
Revenons sur les performances de ce bug. Pourquoi cliquer sur une zone vide déclenche-t-il la méthode focus de TextInput ? Nous avons essayé quelques choses comme celle-ci.

• Découvrez où le focus de TextInput sera déclenché

En plus d'une petite quantité de référence de liaison dans la logique du code, puis du déclenchement la méthode .focus (Comme elle n'apparaît qu'en petit nombre, elle ne répond pas à notre scénario selon lequel toutes les entrées seraient affectées lorsque ce bug apparaît. L'élimination rapide n'est pas en partie la raison.) Nous avons constaté qu'il existe également de nombreux endroits dans TextInput composant fourni par RN où la méthode focus est appelée.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!